Brownout behavior - alternative design goals

[Bryan Herbst]

Originally Posted by Joe Johnson

Our first competition match on Carson, something disabled us during auton, then re-enabled us. Shame on us but our code just restarted our auton and ran it again - which broke the robot.

We discovered this behavior with some teams at 10,000 lakes this year as well- when a robot is disabled and subsequently re-enabled during autonomous, autonomous is restarted.

In this scenario, you really only have two options code-wise: either restart auto or continue running the disabled loop until teleop starts. Picking up where the code left off in auto isn't a viable option unless your team explicitly programs a recovery mechanism.

Whether or not restarting or staying disabled is the right choice is a fair point for discussion, though my guess is that since recovery is a relatively viable option, the decision to restart auto was intentional. Perhaps this behavior could also be better publicized.

I'm also not sure why a brownout triggers disabled mode (I would think it could continue attempting to run during a brownout).

[Greg McKaskle]

Your intuition is correct. There is no need to disable for comms loss or brownout and once that is corrected, the double auto should be a thing of the past.

Greg McKaskle

[Alan Anderson]

Originally Posted by Tanis

I'm also not sure why a brownout triggers disabled mode (I would think it could continue attempting to run during a brownout).

The whole point of a brownout is to disable things so the load on the battery is reduced.

[Pault]

Originally Posted by Alan Anderson

The whole point of a brownout is to disable things so the load on the battery is reduced.

The issue that 246 and other teams experienced was not that the brownouts were disabling "things," but that in reaction to the brownout the FMS would command the robot to disable. This is much different, because the robot does not see it as just a standard brownout, but as if someone manually disabled and then re-enabled autonomous (or tele-op), and will therefore restart autonomous (or tele-op).

If teams have any fear of this happening at their offseason events, I would recommend putting a flag into your code that will only allow autonomous to initialize once. That is what we did, and it prevented this bug from breaking our robot a second time.

[jhersh]

Originally Posted by Alan Anderson

The whole point of a brownout is to disable things so the load on the battery is reduced.

Disabling motors is a totally different thing than being commanded to disable by the field. The FMS is wrong and its behavior will be changed.

[Alan Anderson]

Originally Posted by Pault

The issue that 246 and other teams experienced was not that the brownouts were disabling "things," but that in reaction to the brownout the FMS would command the robot to disable.

Originally Posted by jhersh

Disabling motors is a totally different thing than being commanded to disable by the field. The FMS is wrong and its behavior will be changed.

Whoops. I missed the fact that Tanis was talking about a software-commanded "disabled mode" instead of the local disabling of actuator outputs. I was not aware that the FMS was even in the loop for brownout behavior.

Originally Posted by Tanis

I'm also not sure why a brownout triggers disabled mode (I would think it could continue attempting to run during a brownout).

I'm still not fully understanding the reference to "continue attempting to run", though.

[Greg McKaskle]

The FMS is aware of brownout in order to display to the field display. I took Tanis's statement to mean, don't run disabled code, run the code based on the match transitions. And the ability for the robots to actuate is ANDed with the brownout and coms status.

Greg McKaskle

[Bryan Herbst]

Originally Posted by Greg McKaskle

The FMS is aware of brownout in order to display to the field display. I took Tanis's statement to mean, don't run disabled code, run the code based on the match transitions. And the ability for the robots to actuate is ANDed with the brownout and coms status.

Greg McKaskle

Bingo. If the control system is in a brownout condition, the code should continue running as though nothing had ever happened. Some of the commands sent to certain devices might not actually cause anything to happen (e.g. if the speed controllers have been disabled), but the code should continue to run.

As for comms loss causing the robots to be disabled- I am in favor of that. Without comms, you can't e-stop your robot. That means that if you lose comms and your robot becomes a danger to itself or to people, you can't stop it. Disabling the robot when it can no longer communicate with the driver station sounds like an appropriate action to take.

[jhersh]

Originally Posted by Tanis

As for comms loss causing the robots to be disabled- I am in favor of that. Without comms, you can't e-stop your robot. That means that if you lose comms and your robot becomes a danger to itself or to people, you can't stop it. Disabling the robot when it can no longer communicate with the driver station sounds like an appropriate action to take.

That's contradictory and not how it will work. And anyway, if you have no comms how does FMS disabling do any good. You have no comms.

No, we will continue to have the designed behavior that the robot will override (locally) the enable signal when a situation deems it (no comms and brown out) and the DS and FMS should only use that as status for humans (if they even have comms to receive that status).

The FMS broke this year and it will be fixed.