paper: New Control Functions - Drive System Testing

[MrForbes]

pretty easy to shrink an image, if you have Windows and Office on your computer...just open it in Paint and Resize, and Save As...



If you're using a phone, it's more challenging. If you don't have Office, but have windows, you might try downloading a program such as IrFanView, which is good for stuff like this. If you have another type of operating system, you will need to find another consultant.

[Thad House]

Originally Posted by MrForbes

pretty easy to shrink an image, if you have Windows and Office on your computer...just open it in Paint and Resize, and Save As...


If you're using a phone, it's more challenging. If you don't have Office, but have windows, you might try downloading a program such as IrFanView, which is good for stuff like this. If you have another type of operating system, you will need to find another consultant.

I meant try and do it in forum code. Ill resize it in a bit when I have time.

[MrForbes]

More modern forum software automatically sizes externally hosted images to fit the window...but not this neat old software!

[Ether]

Originally Posted by MrForbes

you might try downloading a program such as IrFanView, which is good for stuff like this

+1 for IrfanView. Been using it for years. Freeware. Works great for resampling.

[Knufire]

Originally Posted by Chris Fultz

The full paper has data on 2, 4, 6 and 4+2 configurations for basic acceleration and for pushing another robot (130 pounds). We are still a few days away from publishing that.

Do you guys have an ETA of when you plan on releasing the full paper?

[Chris Fultz]

Originally Posted by Knufire

Do you guys have an ETA of when you plan on releasing the full paper?

We are doing a final review at the team meeting tonight, and the full report should be posted later tonight or early Wednesday AM.

[Joe Johnson]

I'm not your typical beat up on FIRST type guy but this seems like a really poorly designed system feature.

In the first place it seems to me that a small amount of money together with some clever EE thinking could have allowed all critical brain functions of the FRC control system to remain alive well down to battery voltages as low as we'd like (e.g. 1-2 volts).

In the second place, once you've decided to go down the path of load shedding, this seems like a not very clean implementation. By going with "all off" rather than scaling you pretty much guarrantee crazy and unwanted behavior. A simple scaling reduction scheme would make these brown out events almost unnoticeable for the vast majority of teams.

In the third place, a prioritzed and scaled load shedding seems like the obvious right thing to do. Teams should be given a way to let the system shed load in ways that make sense for that robot at that time (e.g. run this function that provides a list of motors to turn off, motors to scale, and motors to leave at full power or to scale as a last resort...).

From the outside looking in, it seems like FIRST missed an opportunity to do the right thing here.

Dr. Joe J.

[Jared Russell]

Originally Posted by Joe Johnson

...snip...

I think that some teams may go ahead and implement their own version of prioritized load shedding or scaling on top of the built-in all-or-nothing implementation. With the built-in current monitoring of the new control system, it is certainly doable (although not as quick to react or as simple as it could have been if implemented deeper down the stack).

[Jared]

Originally Posted by Joe Johnson

I'm not your typical beat up on FIRST type guy but this seems like a really poorly designed system feature.

In the first place it seems to me that a small amount of money together with some clever EE thinking could have allowed all critical brain functions of the FRC control system to remain alive well down to battery voltages as low as we'd like (e.g. 1-2 volts).

In the second place, once you've decided to go down the path of load shedding, this seems like a not very clean implementation. By going with "all off" rather than scaling you pretty much guarrantee crazy and unwanted behavior. A simple scaling reduction scheme would make these brown out events almost unnoticeable for the vast majority of teams.

In the third place, a prioritzed and scaled load shedding seems like the obvious right thing to do. Teams should be given a way to let the system shed load in ways that make sense for that robot at that time (e.g. run this function that provides a list of motors to turn off, motors to scale, and motors to leave at full power or to scale as a last resort...).

From the outside looking in, it seems like FIRST missed an opportunity to do the right thing here.

Dr. Joe J.

I see where FIRST is coming from with this decision. Last year at the championships, I saw tons of robots trip their main breaker, reset their main breaker, or suffer from having a very low battery voltage. The load shedding is likely an attempt to fix some of these problems.

That said, I've review our teams logs from the championship and one district event. We had matches where we would have been affected by this 7 volt limit. Toward the end of our matches, after running around in high gear, with the compressor running constantly, we saw the battery voltage hit 6v and below, and we definitely below 7 volts for a decent amount of time. This match was played with an older battery, which we had to use because of the number of replays/elimination rounds that went to three.

My solution would be to have the load shedding functionality be optional/adjustable. Teams who don't want to deal with running the system on the very edge of breaker tripping/resets can leave it on, but teams are welcome to (at their own risk) disable the brownout protection and deal with it themselves.

This is speculation, but the 7v limit may be set to prevent transients below 7v that the system is not fast enough to capture. I don't know how fast they're sampling for the protection or how fast the protection can react, but it may not be fast enough to react to the really sudden voltage drops that can occur when a motor suddenly starts. The cRIO could stay alive during fast spikes, but I have yet to see tests of the roborio with transients.

[Joe Johnson]

As is often the case, upon reflection, I find I may have been a bit harsher than I should have.

The problem is a little more complex than I painted it. The speed controllers that have internal PID loops make for strange power shedding situations. How do you tell a control loop not to exceed certain current outputs? Of course, you can, but it isn't simple and it adds to the complexity of the already complicated interplay between the RoboRio and the Talon SRX (or ... shutter... Jaguar).

Dr. Joe J.

[Chris Fultz]

There is no reason capable teams cannot implement their own logic to manage this beyond "off/on", but this will really save a lot of teams without that capability. I could also see many teams turning off the protection instead of determing why it was tripping and how to manage it.

For 2014, we knew if our compressor was on, our winch was really slow to retract our launcher. In software, we switched off the compressor when the winch motors were turned on. Using the new control capability, we could make that decision based on battery voltage and possibly make better decisions.