When we run our tracking program it makes the robot brown out. Then all inputs from the controllers are delayed by a couple seconds.
The blue vertical line is where the tracking starts.
Could this, or another co processor help this?
What is your current hardware setup for tracking? Are you just using the roboRIO? If so, I would definitely get a coprocessor for vision. (See here for more information on those)
As for the brownout problem, how does it perform when driving manually? If there’s still an issue, there’s probably a mechanical or wiring problem with your drivetrain. If not, I recommend taking a posting your code here so others can take a look at it.
We are using the roborio and the limelight 2 for tracking. Driving and moving the arm manually does not result in any brown out problems. The only problems with brownout arises when we run the command to track. We currently only have a raspberrypi and Arduino for potential co processers. We were looking at getting the coral, would that be of any help?
The coral would not help the roboRIO CPU when it’s plugged into the limelight. Similary, since the limelight is already a coprocessor, I suspect you won’t see any benefit.
I suspect you have something inefficient in your command to track, for example, a tight while loop waiting for something to be returned from the limelight. But as Bobby said, we really need to see your code to identify why it’s pausing the roborio processing (as seen in the broken blue line in the log picture)
1 Like
We do have a while loop to move our arm and we are grabbing a lot of values from the smart dashboard.
Github Go to the ArmSubsystem and Tracking command
This is probably your issue. It’s a bit tough to wrap your head around, but WPILib essentially expects your robot code to run all the way through in 1/50 of a second. That means you’ll want to avoid writing loops that are going to take longer than that time like you did here. What I would do would be to move this logic into a command that effectively does the same thing, but instead of a while loop, the target encoder value check is handled by its IsFinished() method.
Thank you. This helped, but it stills browns out every now and then. We tried it with a new battery as well.
After every brown out, if we hold inputs on the controller during the brown out, all controller inputs are delayed.
This is critical. We have had while loops like that cause the robot to ignore disable commands while still running whatever outputs were set last.
Thank you for this information. We removed all while loops in our code but it still browns out.
Did you put amp limits on your motors?
No. How would you do that exactly in java.
1 Like
As you can see the cpu usage doesn’t move.
But the voltage drops to about 8 volts and we lose robot code and comms. This is odd.
Sorry for all the confusion with the different posts.
I will give a history of our problem.
We had an issue with our code using and topping out our roborio, but we adjusted our code, so now the usage barely goes up. We also had an issue with it browning out.
But now when we use our tracking command the voltage only drops to at most 8 volts and then we loose comms and robot code for about 2 seconds.
So we called it “brownout”, but we are not for sure if this is the correct term.
Look at the picture in the previous reply.
It’s not technically a brownout until you hit 6 volts and the roboRio refuses to drive motors in Oder to keep itself alive. Your voltage drop is most likely caused by your tracking command trying to accelerate more aggressively than manual driving. However, you need your radio to be able to tolerate 8 V. How is your radio powered?
Okay, we kind of figured it wasn’t a “brownout” anymore.
Our radio is powered with the REV radio power module.
Should we also try powering it with a barrel jack?
We have not had issues with it in the past.
Our manual shooting and tracking shooting speed the motors up the exact same and use the relative same voltage.
We have fixed the loosing coms and robot code issue. It was caused by a loose wago connection that was causing the wire to spark.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.