Hello, I’ve noticed a few miscellaneous bugs in V5. First, in the practice match selection on the controller. The time shown for Autonomous is thirty seconds, but it actually only runs for 15 seconds. The second one is a bit more complicated. When running autonomous, a competition switch does not seem to be working well. When running autonomous from the remote, everything works fine. However, when running autonomous from the physical competition switch, my usercontrol fails to run after I’ve run my autonomous. I believe the first is a general bug with V5, but the competition switch issue seems like it’s on my end. Any ideas?
Do you have the new update? 1.0.4
update, I think these were fixed in the November update or perhaps before. Anyway, update to V1.0.4, it was released today.
I’m currently on V1.0.3, but I’ll update tomorrow. The Autonomous thirty seconds was also shown in several other V5 controllers at my school
did you tether the controller after updating to 1.0.3 ? if not the controller did not receive its update. We improved this in 1.0.4 to warn you to tether the controller if it needs an update.
That’s probably it, I don’t think we’ve done that. Thanks!
Any new visual signals we should know about for debugging at events?
What would be very useful is to have a V5 Inspection Guide - currently this is a black hole for EPs. We are left guessing on what to check for and how to help teams.
This morning we downloaded and installed V1.0.4 and connected the remote as well. The 30-second bug is gone, so thank you.
However, the competition switch bug persists. Additionally, we tried it on another robot (also up to date) and we ran into the same problem. After running autonomous, usercontrol fails to start. For reference, we are both using rmbuild with Visual Studio Code, so that may be related. I can post my code if need be.
I have an issue where when we run a Skills run from the controller, it doesn’t disable the robot at the end of the timer.
@1320D_Programmer can you list the step you are using for running with the comp switch?
- comp switch is auton and disabled
- brain off, controller off
- plug in controller to comp switch
- turn on controller and brain
- select program
- select auton
- comp switch enable
- wait 15 sec, comp switch disable
- comp switch driver
- comp switch enable
Since we use the LCD to select auton, we must the comp switch to test it. I’ve seen the team run auton and then drive it back to the perimeter. I have not noticed how they are using the comp switch to do that.
I believe it messes up in a few different ways. The one I’ve tested mostly is this.
I turn the brain and controller on
I start the program (everything works)
I set the comp switch to enable driver
I plug in the competition switch (everything works)
I switch it to enable auto on the switch
My autonomous runs as normal
I switch it to enable driver
My lcd screen goes blank and driver control does not run
brain lcd or controller lcd ?
perhaps you should send me the program and I will test. RobotMesh comp control does run a little differently from the VCS comp control and primary testing of vexos is done with VCS. But RobotMesh also tests pretty comprehensibly before we release and this area we though was stable.
Did you fix the problem that vision is often disconnected?
I find the updates quite satisfying, and I kind of like plugging in every battery in to be updated and seeing the flashy green lights LOL. After the 1.0.4 update I found the controller no longer having the bug of flashing red when the haptics are used, as well as I have found consistency with the batteries and vexnet connections. Thank you for all you and your staff does! @DRow
@1320D_Programmer @jpearman I’d also be interested in seeing the program. I usually test our competition template with a competition switch, so this seems rather unusual. A quick test on my test bench bot doesn’t show anything out of the ordinary, either.
Here’s a google drive link to my program. Also, when I said LCD I was referring to the V5 Brain screen.
so I ran the code in VCS (more or less). driver always runs but I do see an issue with Brain.Screen.render() when used in a thread that can be started and stopped several times, I will run in rmbuild later but that’s certainly one issue.
Thanks for helping. So what exactly is the issue with that? I’m not totally clear on what Brain.Screen.render does, but I was under the impression that I was supposed to include it in my loop to prevent artifacts or things like that.
The problem seems to be an interaction with some constants we’ve set for threading, and that you are creating four threads every time you enter driver control that are not destroyed when you leave driver control (which would create logic errors even if it did run). Basically, we’re giving each of your threads a lot of memory, and we run out of reserved memory to give to you after you start several of them and we start a couple in the background. You can actually get your driver control to run twice if you comment out any two of those four threads.
As for how to fix it today, I would change your
statements in your driver control’s child threads to
while(Competition.isDriverControl() && Competition.isEnabled())
so that they will exit when you leave driver control. You can also remove the
from main, as RMS does not require that you keep the main thread alive after registering competition control handlers. We will be looking at slimming down our threads and making out of memory errors a little more obvious.
In your case, including Brain.Screen.render() was appropriate as you are clearing the screen and redrawing everything to obtain the animation. render() switches over the graphics system to use what we call a back buffer, all drawing is done in the back buffer until you call render, then the V5 synchronizes with the LCD refresh and quickly copies it so it is visible. There are pros and cons to using this technique, to synchronize with the LCD we may wait up to 16mS, so loops containing render will run slower than without. The benefit is reduced or no flicker when redrawing large areas of the screen.
There is a small bug in the implementation that I will need to fix in 1.0.5, it probably impacts VCS more than RobotMesh C++ but I need to test in both. The bug relates to stopping (or restarting) a thread was in the middle of a render operation.