On two separate occasions today in our matches our RoboRio rebooted mid-match ( ) . We believe the rebooting was due to a fault in the PDP. What is strange is that when the Rio would reboot, all of the pneumatics would actuate. One mentor, and some others in FRC discord, brought up the possibility that we were using pistons that revert to a default state when power is lost, but this is not the case, as the pistons normally remain in place when we flip off the main breaker (double solenoid) Code is not telling solenoids to do anything to do anything until auto. Any thoughts?
Edit: the Pistons actuate when the Rio first stops working, not after the reboot is completed.
How many electrical wires each one of your solenoids have?
If it has one pair of wires it retracts when powered is not applied and extends when it is applied.
If it has two pairs of wires (also known as double solenoid) it wont change state if the power of the robot turns off.
Do the pistons retract in the end of the match?
Sorry, forgot to mention: double solenoid
I think you are toggling the solenoids in the the robotInit / autonomousInit / teleopInit functions
Do you set an initial position in code?
Are the solenoid Sets coded to only occur on a button press or do they also occur on the lack of a button press?
I am not sure if this is related to something we discovered/confirmed this weekend at MVR, but perhaps it is.
After seeing some quirky behavior through out our more-than-chaotic build season this year, we finally had a chance to clearly observe the symptom of what I believe is a huge problem with the Scheduler.
The symptom was that at the beginning of Sandstorm our elevator went straight to the top position. We have a button command that tells the elevator to do just that for loading cargo at the top of the rocket. Our drive team operator insisted it is a code issue because he never touched the button.
My lead developer reminded me that we had seen things like this during build and posited a theory: maybe someone pushed the button while the bot was disabled and the command was already running when we were enabled. We verified the theory in the pits. So, we put a Robot.enabled() check in the execute() method of the command and returned immediately if !Robot.enabled() and the symptom went away.
I have spent some time looking into the wpilib source, https://github.com/wpilibsuite/allwpilib/blob/master/wpilibj/src/main/java/edu/wpi/first/wpilibj/command/Scheduler.java and found a few things. Scheduler has a private m_disabled class attribute. Scheduled.run() has an if (m_disabled) check and returns immediately if true (safe behavior). It is initialized to false (not so safe). Scheduler also has enable() and disable() methods. I have done pure text searches and VS code searches for an invocation Scheduler.getInstance().disable() and found none.
My conclusion is that there is a missing piece in the Robot base classes, https://github.com/wpilibsuite/allwpilib/blob/master/wpilibj/src/main/java/edu/wpi/first/wpilibj/IterativeRobotBase.java that used to - or at least should - be calling Scheduler.getInstance().enable()/disable() at the appropriate xyzInit() calls and that the m_disabled attribute should be true as a safe default. It can be argued that teams should be doing the Scheduler.enable()/disable() in the overrides. However having the m_disabled default to be false and requiring the teams to manage the Scheduler is a dangerous!
Anyway, i thought I’d share those findings as they may relate to your solenoid problem. If your bot code was not actually restarted, but instead you just got disabled (perhaps by an Exception of some sort), the when you would have enabled the bot, that command will continue to get executed.
The default CommandBased template explicitly does the opposite of this. It has a Scheduler run call in Disabled Periodic.
It seems like your expectations of how the system should work don’t match the developers. As you’ve noted, you can easily fix this in your code by removing that Scheduler run call or even explicitly disabling the scheduler
I can’t agree with your assumption that my expectations don’t match developers when there is no documentation of expected behavior. With some kind of guidance on API usage specifically around enable/disable, I would easily accept the specifications. However, what I will not concede is that having the default value of the m_disabled = false is logically correct. It is extremely dangerous default behavior. It would also be a much better and safer design to have the RobotBase classes manage the Scheduler. In thinking about this a bit more, the template code should probably be calling Scheduler.getInstance().disable() instead, or perhaps even better, Scheduler.getInstance().run(); Scheduler.getInstance().disable();
There is zero docs or examples that tell me or even imply that Scheduler my code needs to synchronize robot state and scheduler state is my explicit responsibility and very dangerous.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.