Brownout behavior - alternative design goals

[jhersh]

Originally Posted by Thad House

And the virtual brownouts should be changeable by the fpga. I'd be surprised id they were not.

The level is actually set by a hardware comparator. However it is likely that a work around could be implemented in the FPGA if needed.

[Thad House]

Originally Posted by jhersh

The level is actually set by a hardware comparator. However it is likely that a work around could be implemented in the FPGA if needed.

Really? So the next question is who made the decision to put the PWM shutoff so high? With things we saw in 2013 and 2014, 7V is a number pretty easily hit by a 6 CIM drive, even if it is just for a few ms. Also why ever drop the 5v and 3.3v rails? It seems like disabling those causes more problems for teams, and troubleshooting sensor drops are harder then pwm drops.

[Andrew Schreiber]

Originally Posted by Thad House

Really? So the next question is who made the decision to put the PWM shutoff so high? With things we saw in 2013 and 2014, 7V is a number pretty easily hit by a 6 CIM drive, even if it is just for a few ms. Also why ever drop the 5v and 3.3v rails? It seems like disabling those causes more problems for teams, and troubleshooting sensor drops are harder then pwm drops.

The PWM cutout, I'm actually happy about and hoping it will help end the stupid drivetrain wars we've been engaged in since 2005. The idea of "throw more power at it", while valid, gets annoying very quickly when 6CIM shifting drives smack into you from across the field.

[MrRoboSteve]

Updated:

1. It will always be possible for the roboRIO to have less power than it needs to run, so load shedding features will continue to be useful for the great majority of teams.

2. Might be possible for the roboRIO to tolerate longer periods of low voltage. That said, robots operating for extended periods at 7 volts are visibly sick.

3. As FTAA, the only way I knew a robot was in brownout was to go stand behind the drivers and watch the display. We need to make brownout on the robot more visible, to avoid situations like the one Joe describes. Ideas:
a. FMS field monitor should show "brownout count" statistic, separately showing stage 1 and 2
b. DS software should have a brownout indicator that stays lit if there's been a brownout
c. DS stack light should change state for a second or so when there's a brownout

4. It's difficult to change the voltage of the stage 2 brownout, because it's a function of the power supply architecture.

5. It would be interesting to collect DS logs of machines in brownout, to see if at the point of outage the voltage has a steep slope. This would help assess the utility of changes to how stage 1/2 brownouts work.

[jhersh]

Originally Posted by Thad House

Really? So the next question is who made the decision to put the PWM shutoff so high? With things we saw in 2013 and 2014, 7V is a number pretty easily hit by a 6 CIM drive, even if it is just for a few ms.

The point of having it "high" at 6.8 V is to have some breathing room to get those loads turned off in time for the battery to recover before the controller blacks out. Since we don't have control over the PD channels we can't simply turn off the high loads. We have to ask that the controller stop. That takes time. This transition happens relatively quickly in human-perceivable time, so if your load is very high but your battery is not dead, you will likely not even notice that the brown-out happened. That is the goal and others have reported this. If as you say it dips for a few milliseconds, then your motor controller will only be disabled for a single cycle (5 ms on most PWM motor controllers). If it is near the end of a match and your battery has been abused most of that time, it will not recover as quickly, but the goal is to avoid the controller rebooting even in that case. I think the level is appropriate.

Originally Posted by Thad House

Also why ever drop the 5v and 3.3v rails? It seems like disabling those causes more problems for teams, and troubleshooting sensor drops are harder then pwm drops.

The three user supplies were originally considered a potentially "high load", around 22 W, (though practically that is not the case). As such those two were on the chopping block for brown out to help save the boost supply running the processor from faulting. During the design it was determined the 5 V and 3.3V supplies could not handle the upper end of the input voltage and still use the controller parts we selected, so it was decided that a fix for that would be to power them down-stream of the 6V supply to limit the input they see. All three supplies were also designed as buck supplies only. Since at that time they were all set to be disabled at 6.8V anyway, this was an appropriate solution.

Later (alpha 2) when we decided that 5 V and 3.3 V supplies should not disable until black out, they were still down stream of the 6 V supply. At this point the hardware was already being manufactured and the power supply topology could not be changed with acceptable risk and schedule impact. Being down stream of the 6 V supply meant that the input they see goes away completely when the 6 V supply controller enters a fault state due to insufficient input voltage. This happens at about 6.25 V. This means that if the motor controllers respond (starting at 6.8 V) before the input drops to 6.25 V, the sensor supplies will not black out.

[Thad House]

Originally Posted by jhersh

The point of having it "high" at 6.8 V is to have some breathing room to get those loads turned off in time for the battery to recover before the controller blacks out. Since we don't have control over the PD channels we can't simply turn off the high loads. We have to ask that the controller stop. That takes time. This transition happens relatively quickly in human-perceivable time, so if your load is very high but your battery is not dead, you will likely not even notice that the brown-out happened. That is the goal and others have reported this. If as you say it dips for a few milliseconds, then your motor controller will only be disabled for a single cycle (5 ms on most PWM motor controllers). If it is near the end of a match and your battery has been abused most of that time, it will not recover as quickly, but the goal is to avoid the controller rebooting even in that case. I think the level is appropriate.



The three user supplies were originally considered a potentially "high load", around 22 W, (though practically that is not the case). As such those two were on the chopping block for brown out to help save the boost supply running the processor from faulting. During the design it was determined the 5 V and 3.3V supplies could not handle the upper end of the input voltage and still use the controller parts we selected, so it was decided that a fix for that would be to power them down-stream of the 6V supply to limit the input they see. All three supplies were also designed as buck supplies only. Since at that time they were all set to be disabled at 6.8V anyway, this was an appropriate solution.

Later (alpha 2) when we decided that 5 V and 3.3 V supplies should not disable until black out, they were still down stream of the 6 V supply. At this point the hardware was already being manufactured and the power supply topology could not be changed with acceptable risk and schedule impact. Being down stream of the 6 V supply meant that the input they see goes away completely when the 6 V supply controller enters a fault state due to insufficient input voltage. This happens at about 6.25 V. This means that if the motor controllers respond (starting at 6.8 V) before the input drops to 6.25 V, the sensor supplies will not black out.

If these drop happens, do the internal pullups still drop? Or are they ran off a seperate voltage regulator?

[jhersh]

Originally Posted by Thad House

If these drop happens, do the internal pullups still drop? Or are they ran off a seperate voltage regulator?

They do not drop. Separate regulator. The internal pulls on all DIO / I2C / SPI lines are connected to the internal 3.3 V supply that is fed by the boost supply in roboRIO.