My team and I have been working on autonomous and haven’t been able to get it to work properly.
At the start of the match, our robot has its loading arm in a position to keep it in the frame. The first thing the robot is supposed to do in autonomous is to push the arm out with pistons and immediately bring it back in and then uses the loader motor to pin the ball in the right spot. Then it is supposed to drive forward to the shooting position. Then it is supposed to turn on the shooter motors, wait, then fire the ball once the shooter motors are up to speed and shut off all motors.
The piston code for whatever reason wasn’t working unless it was in a loop even though the loop only executes once. That code works fine.
It drives fine, but we haven’t tested the timing so odds are 3 seconds is too long.
The loader motor and shooter motor are the ones that are giving us trouble.
We will start up the robot, run autonomous and it will work. Shut down the robot, deploy a second time. The robot will drive forward, put the ball in the right position, but when it goes to turn on the shooting motors they twitch. Then it goes to fire and those motors twitch, and again doesn’t actually move the motors more than a single twitch.
It doesn’t happen consistently. One second it will work fine, with no problems, the next it won’t work at all.
My first assumption was there is something in periodic tasks that was the problem so I added a global variable that is set to false when autonomous is run and true when in teleop to start up the periodic task stuff.
That did not fix the problem.
I put numeric displays that change value as the program goes through the flat sequence and all of them display correctly, so I don’t think it is getting hung up but I have not been able to fix this.
I was wondering if anyone else had had a similar problem and how you fixed it. Below is a picture of my autonomous.
We are having a similar problem, at least in that we step through our sequence, but our drive does not turn off when we give it a zero value at the end. This is a huge problem.
One thing that is different with our code, is that we use periodic tasks to drive, so we only set global variables in our sequence. We are planning to just disable our drive motors at the end of the sequence, and re-enable them at the start of teleop. We may have a bug somewhere in our periodic task code, so that is going to get a lot of looks.
[Update] - found our problem in our periodic tasks. Had an errant write (overwrite) of the global that we set in autonomous.
Of course there are other caveats. We use CAN and get some odd errors from the WPI library for CAN when we read the state of limit switches. We were dropping some packets and maxing out the CPU for no apparent reason in autonomous, which may have been contributing. We addressed the CPU with optimizing some code that is called often. We will be eating the errors to address some latency issues, as the WPI code gives the correct output in spite of the errors. If none of this fixes the problem, who knows.
even though the loop only executes once
The attached image requests that the loop runs three times. (0>1 -> False, 1>1 -> False, and 2>1 -> True, so it will not schedule another execution.
I don’t see anything that would explain the other symptoms you describe. My suggestion is to review it carefully and potentially even to isolate it by subsystem and identify what causes it to start failing.
MrRehder - Why don’t you pass the refnum for the loader motor through the sequence, like you did for the drive and shooter?
Did you enable the loader motor in begin.vi, before passing the reference to the refnum? If not, you may want to pass the refnum to a Motor Enable vi, and then just use that reference through the sequence.
I had actually thought that might be the problem, and changed how the loader motor was called. However, that did not solve the problem.
I also removed the while loop and just extended the wait time for the pistons and now that works fine. I think the 250 ms wasn’t enough time for the pistons to be pushed out and then called back.
Everything works in teleop, and works at once. The tech teacher was telling me that the students had had the robot moving, firing and using the pistons all at once with no problems. Only Autonomous doesn’t work for whatever reason.
Also the thing we have noticed is if one of the sequences doesn’t work the others do. I’m thinking we may need to combine them all into one sequence to see any change.
I don’t know if this is the issue or not, but I see that you use the drive vi’s for the shooter and drive, with the safety config disabled. The safety config, when enabled, will disable the motors if there isn’t an update sent within 100ms.
The non-drive motor controllers may still have the 100ms update requirement from the older watchdog system. You may want to put a 50ms timer with the motor set in a for loop, instead of using the timing frame. In this way, you can tailor the wait in 0.05 second increments, and you won’t go beyond 100ms between updates.
The LabVIEW version of WPILib still has the user watchdog option, but it is not on by default. The RobotDrive has safety enabled by default and other motors and actuators do not.
I agree that there are ways to write the code with far fewer icons. I don’t believe that would cause the symptoms. Are any of the same resources being updated in Periodic Tasks? Are there any error messages on the DS Messages tab, possibly about refnum not being opened?
Thanks for the clarification Greg!
I offered the timed loop, because I hadn’t seen how they are controlling their motors. It is my understanding that the FIRST-specific firmware in the Jaguars, still expects updates within 100 ms, by default, if using CAN. PWM is a different story.
If they are using PWM (which is most-likely), then I’m at a loss as to why that motor wouldn’t be responding.
I am pretty sure I figured out the problem and fixed it. I did not realize when you disable the robot after teleop, periodic tasks does not stop running. I changed my periodic tasks to stop the individual loops after teleop and then it restarts the main loop that checks if teleop starts again and everything seems like it is working better.