programming for brownout avoidance

[bowmanb]

Our team is using a 6 cim drive for the first time and we are of course finding it quite easy to brown out when approaching full throttle from a stop and in turns in high gear.

I don't want to discuss the relative merits of 6 cim vs. 4 cim. The team wanted to do this and I lost the argument.

Ive looked in all my usual places for this and have come up empty.

The question is: In LabView how do we:

1. access the PDB data on current and voltage
2. implement a "governor" routine using this data to compute a scaler to limit our motor power to keep the current draw under the brownout threshold.

[rich2202]

Does this help?

In LabVIEW, you can read the current on a PDP channel using the PDP Channel Current VI found on the Power pallete.

https://wpilib.screenstepslive.com/s...24166/l/289498

Regarding implementing a governor, how about this:
1) Process that reads the voltage, and adjusts a "Power Factor" variable. For example, when voltage is > 9 volts, Power Factor = 1. When it drops below that, the value declines.

2) In your process that sets the speed of the motors (let's say the value is Speed), multiply that number by the Power Factor variable (Speed * Power Factor).

[MrForbes]

Originally Posted by bowmanb

I don't want to discuss the relative merits of 6 cim vs. 4 cim. The team wanted to do this and I lost the argument.
...
how do we:
.....
implement a "governor" routine using this data to compute a scaler to limit our motor power to keep the current draw under the brownout threshold.

I guess you could tell the students that removing a CIM from each side will implement a governor to keep the current under the brownout threshold.

But then the programmers wouldn't get to have so much fun

Good luck!

[Greg McKaskle]

We just finished putting joystick ramping on the drive to help with the rocking -- in case the drivers want it. It will also help with surge current and is perhaps simpler than the previously described algorithm. You could even decide to keep a running average of voltage or use the voltage faults to increase the ramp each time you get one. Of course this SW stuff is just doing the same thing as teaching the drivers to be a bit smoother on the stick. Also, SW can't fix loss due to long wires, weak crimps, or excessive loss due to friction, and those mods are of course way better than simply avoiding deep voltage dips.

If you want to do a ramp, the PID palette has an output limiter or you can build your own.

Greg McKaskle

[bowmanb]

Originally Posted by rich2202

Does this help?



Regarding implementing a governor, how about this:
1) Process that reads the voltage, and adjusts a "Power Factor" variable. For example, when voltage is > 9 volts, Power Factor = 1. When it drops below that, the value declines.

2) In your process that sets the speed of the motors (let's say the value is Speed), multiply that number by the Power Factor variable (Speed * Power Factor).

Thanks! Can't believe I missed the Power Palette.

Do you think this process would work best in Periodic Tasks or Teleop?

[rich2202]

Originally Posted by bowmanb

Do you think this process would work best in Periodic Tasks or Teleop?

I have no idea of the differences between Periodic Tasks and Teleop. Our team uses C++, and everything is done in TeleopPeriodic.

[Greg McKaskle]

If you want to check it each time you update the motors, then doing it in the same place might make sense.

If you are using Command and Control, that is likely in the Drive Controller Code. Otherwise it is likely in the TeleOp code. Unless you are doing it at a slower rate, I wouldn't Periodic Tasks.

Greg McKaskle

[Caleb Sykes]

Originally Posted by Greg McKaskle

We just finished putting joystick ramping on the drive to help with the rocking -- in case the drivers want it. It will also help with surge current and is perhaps simpler than the previously described algorithm.

I'll second this. Joystick ramping is a really simple way to avoid voltage dips that can cause brownout. We always use this code for each of our motors. If you make the rate large enough (we usually allow dead stop to full speed in .1 seconds) the drivers won't even notice.

[Ether]

Originally Posted by Caleb Sykes

If you make the rate small enough...

If you make the rate large enough...

[HolyLandBrand]

How do you program this in java? Do you just use the getVoltage() method from the PDP class.. does that method give you the information you need use joystick rampinG?

[Ether]

Originally Posted by HolyLandBrand

How do you program this in java? Do you just use the getVoltage() method from the PDP class.. does that method give you the information you need use joystick rampinG?

If you are using CAN TalonSRX they have built-in adjustable ramping.

If not, just use something like this:

http://www.chiefdelphi.com/forums/sh...19&postcount=5

[Caleb Sykes]

Originally Posted by Ether

If you make the rate large enough...

You are correct. I have edited my previous post. I got it backwards because in our code we don't refer to the rate itself, but rather the time it takes to go from 0 to full, like how I described above. So our full speed time (as we call it) must be made small enough so that the drivers do not notice.