1. 4 weeks ago

    1320D_Programmer

    Dec 18 Atlanta 1320D

    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?

    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 while(true) 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 while(true) 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.

  2. Cam

    Dec 19 Ga Us ?

    Do you have the new update? 1.0.4

  3. jpearman

    Dec 19 Moderator, ROBOTC Tech Support, V5 Beta Moderator Los Angeles 8888

    @1320D_Programmer Any ideas?

    update, I think these were fixed in the November update or perhaps before. Anyway, update to V1.0.4, it was released today.

  4. 1320D_Programmer

    Dec 19 Atlanta 1320D

    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

  5. jpearman

    Dec 19 Moderator, ROBOTC Tech Support, V5 Beta Moderator Los Angeles 8888

    @1320D_Programmer 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.

  6. 1320D_Programmer

    Dec 19 Atlanta 1320D

    That's probably it, I don't think we've done that. Thanks!

  7. lacsap

    Dec 19 Event Partner, V5 Beta Tester Massachusetts 9791[a-z]

    @jpearman 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.

    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.

  8. 1320D_Programmer

    Dec 19 Atlanta 1320D

    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.

  9. austinrobinson

    Dec 19 Greenfield, Indiana 1115B

    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.

  10. @1320D_Programmer can you list the step you are using for running with the comp switch?
    For instance:

    1. comp switch is auton and disabled
    2. brain off, controller off
    3. plug in controller to comp switch
    4. turn on controller and brain
    5. select program
    6. select auton
    7. comp switch enable
    8. wait 15 sec, comp switch disable
    9. comp switch driver
    10. 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.

  11. 1320D_Programmer

    Dec 19 Atlanta 1320D
    Edited 4 weeks ago by 1320D_Programmer

    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

  12. jpearman

    Dec 19 Moderator, ROBOTC Tech Support, V5 Beta Moderator Los Angeles 8888

    @1320D_Programmer 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.

  13. 3038922

    Dec 19 china ares

    @jpearman 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?

  14. [TVA]Connor

    Dec 19 South Texas 1814D

    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

  15. @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.

  16. 1320D_Programmer

    Dec 19 Atlanta 1320D

    @jpearman @John TYler

    https://drive.google.com/drive/folders/1HTJACaSZKKIXQ9ix1vq2AB2FK964lqZ9?usp=sharing

    Here's a google drive link to my program. Also, when I said LCD I was referring to the V5 Brain screen.

  17. jpearman

    Dec 19 Moderator, ROBOTC Tech Support, V5 Beta Moderator Los Angeles 8888

    @1320D_Programmer I believe it messes up in a few different ways.

    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.

  18. 1320D_Programmer

    Dec 19 Atlanta 1320D
    Edited 4 weeks ago by 1320D_Programmer

    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.

  19. John TYler

    Dec 19 Answer WA

    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 while(true) 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 while(true) 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.

  20. jpearman

    Dec 19 Moderator, ROBOTC Tech Support, V5 Beta Moderator Los Angeles 8888

    @1320D_Programmer 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.

    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.

  21. Newer ›
 

or Sign Up to reply!