paper: New Control Functions - Drive System Testing

[Chris Fultz]

Thread created automatically to discuss a document in CD-Media.

New Control Functions - Drive System Testing by Chris Fultz

[Chris Fultz]

As part of our beta testing, we used the roboRIO for some drive system evaluation testing, capturing data not available through the 2014 control. We were testing 2, 4 and 6 CIM and 4 CIM+2mini-CIM drives and capturing data, including amperage and voltage.

Through this testing, we identified an operational effect of one of the control features that we felt would be good to share.

The new control disables output to the PWMs when the system voltage drops below 7V. This is a good feature as it helps keep the control and radio on-line.

However, operationally, this can cause the PWMs to cycle off and on as voltage recovers and then reduces if no change is made by the operator. Depending on the situation - pushing, lifting, etc. - the effect on the robot may be a non-event or may create a response that needs to be managed with software or by operator actions.

The attached paper describes the specific testing we were doing, and the results. It includes 2 charts that show graphically what was occurring.

As teams prepare to use the new control for 2015, we thought this was an interesting and different control response that would be worth sharing.

[notmattlythgoe]

Good information to know. Thanks.

[mrnoble]

Thank you for sharing this. I noticed that the paper only refers to the two CIM configuration. What were your results when testing the various other combinations you mentioned above?

[Michael Hill]

Thanks a lot for sharing this. This is pretty interesting, and could potentially cause a lot of headaches for teams that run 6-cim drivetrains in high gear. I only have theoretical calculations, but it appears that if you have a fully loaded robot (weight-wise), and run in high (fast) gear, you could potentially not even start. I'm using my drivetrain calculator (available as a white paper), and looking at a gear ratio of 4.63:1, 4 inch wheels, and a battery voltage of 12.8V (typical of a mid-match voltage) (Note: this is the default setting for my drivetrain simulator). From a stop, it looks like the battery voltage could drop down to 6.67V if the robot were commanded to go full forward. Again, this is all just a simulation that has absolutely no guarantee of correctness, but if possible, I'd love to see if this causes problems in reality.

[Chris Fultz]

We only did this specific test with the 4 CIM configuration because with 6 CIMs or 4+2 we just spun the wheels.

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.

[Arpan]

Originally Posted by Chris Fultz

We only did this specific test with the 4 CIM configuration because with 6 CIMs or 4+2 we just spun the wheels.

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.

Out of curiosity, does this affect CAN controlled controllers? Or just PWM?

[MrRoboSteve]

My understanding from last night's GameSense is that the load shedding that occurs at 7v impacts all speed controllers, no matter how interfaced.

[Ether]

Originally Posted by MrRoboSteve

My understanding from last night's GameSense is that the load shedding that occurs at 7v impacts all speed controllers, no matter how interfaced.

How would that be implemented with a CAN connection without affecting other non-motor CAN devices?

(I could guess, but if anyone knows where this is documented would you please post a link)

[cgmv123]

Originally Posted by Ether

How would that be implemented with a CAN connection without affecting other non-motor CAN devices?

(I could guess, but if anyone knows where this is documented would you please post a link)

CAN Speed Controllers need an enable 'flag' to be sent out over CAN before they output anything. That enable 'flag' (or lack thereof) presumably wouldn't affect devices that it doesn't need to.

Originally Posted by Arpan

As a related question (I was never electrically closely involved) - could you regulate the 12V power being fed to the roborio?

The VRM does have enough capacity to run the RoboRIO, but that configuration will most likely not be legal for competition.

[Ether]

Originally Posted by cgmv123

CAN Speed Controllers need an enable 'flag' to be sent out over CAN before they output anything.

so connect the dots. how does that relate to the original question.

and where is it documented.

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