Weird occurrence today during class. Multiple Clawbot groups reported that their R1 button would not raise the arm on their clawbot. All student were using built-in Drive program because they are just starting out. After syncing a second controller on one and getting the same result. I went in and set the port 8 setting from normal to reverse. This allowed R2 button to raise the arm but R1 did not cause arm to lower. Also moved the cable to port 5 and use the up and down arrow and the arm responded normally. To have this happen on multiple robots at the same time seems to be a firm ware issue. I have not gotten further on troubleshooting, but any guidance would be appreciated.
Can they go into the brain in a sensors screen and see the state of the button? If so, press the button and troubleshoot just the button. They should also be able to run the lift motor manually (be careful about end stops there). This is good practice for debugging. Check each portion individually. Same idea for drive bases. Have them pick the wheels up off the ground and test each side or even motor (for a 4 motor base) individually. Start testing in the devices screen one at a time, then add the controller. It saves a bunch of time from testing the whole thing at once. I end up teaching this lesson to young new-grad engineers, as well – your roboteers will be far ahead of the game.
Also try using a program that lifts the arm up and down (to check if it is an issue with the motors)
Thanks! Will try some of that. We did try the manual on the brain first and it works that way as well. Seems to be to program is not responding to the R1 button.
The drive program hasn’t been revised since 2018, so nothing should have changed there.
The arm motor on port 8 will be stopped if it detects limit switches being closed on 3-wire ports C and D, make sure nothing is plugged into those ports.
Wow!! jpearman, thanks so much. I just had the student add the RangeFinder sensor to port C and D. Did not even occur to me that they had anything to do with each other!! Thanks so much I would not have been about to troubleshoot that away I am sure.
That’s our fault for not having sufficient documentation for the drive program, I though we had a kb article for that but it seems not. The V5 drive program loosely resembles the version we had for cortex and the legacy clawbot, that also used limit switches in a similar way. If you plan to use the ultrasonic sensor and want to start with something close to the internal drive program, I have VEXcode projects that have similar functionality posted here. VEXcode also has a template project for the V5 clawbot if that’s what you are using.
Thanks again!! The students will be developing their own code to use the sensor, but this year’s groups must have decided to test their robot condition using the default program, first. This situation did not happen in the past, so I either had them use different ports in the past or students only used their own program after adding the sensor. Regardless, I know more now than at the beginning of the week and so will the student now. I will take a look at the GitHub you shared. I like having my students develop their code but will “steal” anything that will help as all good teachers do.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.