Brownout behavior - alternative design goals

[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.

[Joe Johnson]

Originally Posted by tkeil

Hello. Power electronics engineer here. Somebody directed me to this thread and I thought I'd step in for a minute.

Several of the mentors as well as NI folks have already done a great job explaining this limitation and linking to helpful documentation for diagnosis and solutions. I don't have much to add on this front, but I would like to talk about what goes into selecting an appropriate input voltage from a technical perspective.

It's very easy for someone to be critical and say 'why doesn't it just work perfectly down to <X> volts?!' where <X> is some arbitrarily low voltage that some individual expects to never hit in their particular system implementation. The reason why is that this is a complex embedded controller and there are many trade-offs. In this case the main trade-off is thermal dissipation.

The roboRIO regulates 45W of power maximum. This is a lot for a small, plastic, convection cooled device with no open vents. The power supplies were a major concern for this design since with 45W input they account for a large percentage of the internally dissipated power.

Some of the best power supplies in the world can get >95% efficiency but these are nearly all power supplies with a fixed input voltage and a fixed output voltage. As soon as the power supply has to work over a wide input range, that efficiency falls because the power supply can no longer work at its most efficient operating point all the time. The roboRIO supports >2x input voltage variation. We can get better than 90% efficiency with this wide input range but the wider it is, the worse the losses get.

roboRIO is designed specifically for the FIRST competition, but it leverages many sections of circuits from other embedded controllers. It's designed by the same team that makes our professional cSeries controllers. You should think of roboRIO as a professional embedded controller with a protective cushion around it.

Fully around 1/3 of the circuity in the roboRIO is to protect the device from accidental damage and make it easy for the users to diagnose problems. Our highest priorities of course were preventing failures that permanently damage the device. I bring this up because some of these protections (for example reverse voltage protection) have a required minimum voltage and lie in the power path. These circuits are often leveraged from other designs and while they could be changed, it's costly to design and verify.

Some of these protection devices need to be in the direct current paths inside the device. This becomes a huge problem when your currents get large.

Let's look at a quick hypothetical where the input voltage minimum would be 4.5V:

The roboRIO needs to regulate 45W. If the input voltage drops, the current gets higher. Resistive losses are calculated as P=i^2*R. Consider that the current into the input connector of the roboRIO @ 7Vin is ~6.42A. If the minimum input voltage had been 4.5V that current would be ~10A. When you square those terms thats about a 2.5x increase in resistive losses through the whole input section of the power distribution path and switches in the power supplies.

Before you even get to the first power supply in the design, the power has to go through the input connector, the fuses, the common-mode choke, more noise filtering, reverse voltage and reverse current protection, and finally an input current sense shunt. The losses in all these devices would be 2.5x greater in this fictional example of allowing full power down to 4.5V.

Many (most?) of these devices would also have to be larger to support the current and thermal dissipation. For instance, 10A is far over the rating of the input voltage connectors. [For a laugh you can consider the device operating down to 1V in which case the current would be 45A and the input connector terminals would be around the size of an AA battery each.]

Anyway, when you combine the extra losses in the main input supplies with the extra losses in the resistive elements (and the increased component sizes) you will quickly lose your form factor and ability to use a plastic housing. If we had to go to a metal housing and possibly one with heat spreaders, you're talking about increasing the total device COGs by roughly 30% - 50% and increasing the form factor and weight.

Input power and voltage range is a big deal. Myself and others at NI think about it a lot and then over and over again for each new design. As you guys all know as good engineers and scientifically minded folks, everything's a trade off.

Thanks for your time volunteering with the students.

Tim

Tim,
I appreciate that there are a lot of constraints and trade offs in every design but at the end of the day it has to be suitable for the intended use.

I have circled back with a number of very experienced FIRST folks from teams with many years of FIRST experience. I'm confirmed in my view that given the FRC battery and the motors that FIRST allows that a 4.5V reboot of the CPU was a poor design choice that was made worse by allowing the 5V and 3.3V rails to away at above 6V making sensors and coprocessors go dark.

On the other hand, a lot of people are making claims that the system basically works based on the 2015 experience. I predict that when we go back to a more traditional FIRST FRC season, there will be a ton of folks who are unhappy with these design decisions. In the mean time, I don't need to argue about it. The system is what it is.

Dr. Joe J.

[Andrew Schreiber]

Originally Posted by Joe Johnson

On the other hand, a lot of people are making claims that the system basically works based on the 2015 experience. I predict that when we go back to a more traditional FIRST FRC season, there will be a ton of folks who are unhappy with these design decisions. In the mean time, I don't need to argue about it. The system is what it is.

Dr. Joe J.

254 probably has more data than I do because they run closer to the edge, but I can tell you that in a season like 2014, when we DIDN'T have a short in our wiring, 125 rarely went below 6V despite some very aggressive gearing in both our drivetrain and our launching system. The only times (I recall) we had serious current draw* issues were when a vastly over-inflated ball jammed in our intake, the choo-choo was loading, and we were driving aggressively.

That being said, wasn't it you who coined the term "drivetrain wars" all those years back when we first started getting CIMs? I just view this as a good way to end those. EDIT: My memory DIDN'T fail me. http://www.chiefdelphi.com/forums/sh...79&postcount=1



* This ignores that we spent the first half of the season with a short that was causing us to die on the field regularly.

[MrRoboSteve]

Originally Posted by Joe Johnson

On the other hand, a lot of people are making claims that the system basically works based on the 2015 experience. I predict that when we go back to a more traditional FIRST FRC season, there will be a ton of folks who are unhappy with these design decisions. In the mean time, I don't need to argue about it. The system is what it is.

We're in agreement that the verdict won't be in until we have a game that demands higher current. This year wasn't that game.

[Tom Line]

Ok. So like good engineers, let's solve the potential problem. is it possible to design a circuit such that it can be put in line with the crio power wiring, plug into a battery pack, and protect the crio voltage supply?

[Jared Russell]

Originally Posted by Andrew Schreiber

254 probably has more data than I do because they run closer to the edge, but I can tell you that in a season like 2014, when we DIDN'T have a short in our wiring, 125 rarely went below 6V despite some very aggressive gearing in both our drivetrain and our launching system. The only times (I recall) we had serious current draw* issues were when a vastly over-inflated ball jammed in our intake, the choo-choo was loading, and we were driving aggressively.

That being said, wasn't it you who coined the term "drivetrain wars" all those years back when we first started getting CIMs? I just view this as a good way to end those. EDIT: My memory DIDN'T fail me. http://www.chiefdelphi.com/forums/sh...79&postcount=1



* This ignores that we spent the first half of the season with a short that was causing us to die on the field regularly.

I'd much rather see the drivetrain wars moderated by game design (one of the only things I liked about Recycle Rush, though 2012 and 2013 did a great job of this as well).

Failing that, I favor limiting the number of drive motors, a speed limit, wheel restriction, etc., rather than brownouts. Brownouts can be insidious to deal with (if you have any control loops), and be next to impossible to completely avoid (the dynamics of any FRC robot frame mean that instantaneously, your wheels may be loaded really unfavorably when driving around the field). An FRC robot that is designed (mechanically) to be incapable of dropping below 6.8V would be a fairly uninspiring robot to watch.

Forgive my ignorance on such things, but is there any way to default the motor brownout to 6.8V, but allow teams to do something else "if they (think) they know what they are doing"? For example, I could see doing prioritized load shedding (ex. first drive, then intake, but position-controlled elevator last) as a viable way to deal with this, but there isn't really any headroom above 6.8V with which to implement such a scheme.

[Greg McKaskle]

Forgive my ignorance on such things, but is there any way to ...

Not yet, but it has been discussed and is technically feasible. It would be a way for teams to prioritize current supply, but also a way to bypass the protection and to blackout some portion of the robot. So, it is not a magic bullet.

Greg McKaskle

[Joe Johnson]

Originally Posted by Jared Russell

I'd much rather see the drivetrain wars moderated by game design (one of the only things I liked about Recycle Rush, though 2012 and 2013 did a great job of this as well).

I am with you as long as by game design you are not talking about making the refs enforce more and more critical pinning rules. It makes me cringe whenever I hear the announcer saying things like, "Ok. Good match. Now let's see if penalties will change the outcome..."