Voltage Compensation

Technical Java
1

We just tried voltage compensation on the Talon SRX controllers on our tank drive to try to improve repeatability in autonomous runs. We set the saturation at 12v. There seemed to be an improvement in auto runs, but our drivers immediately noticed much higher responsiveness than normal operating with joysticks and the robot is very difficult to control.

An example of this is pushing one stick full forward and one full backward to rotate the bot in place. With compensation off this results in a rotation in place at a speed that is consistent with our experience and expectation. When sticks are returned to neutral the robot slows and stops pretty quickly, less than one rotation.

With compensation turned on, the rotation accelerates to a noticeably higher rotational velocity, almost to the point of violence and when the sticks are returned to neutral, the robot continues to spin and will spin all the way around several times before coming to a stop.

This is not what we expecting from compensation…thoughts?

2

Need more information about your robot and code to give any real advice.

Compensation generally won’t affect responsiveness much at all; it only adjusts on the order of 1-2 volts in most situations.

If your robot is behaving too violently, consider applying a slew-rate limit to your joystick inputs.

3

We don’t have to use slew rate limiters (we use squared inputs) with no voltage comp. Robot drives just fine. That does not seem the best way to approach this problem. We expected the robot behavior should not be much different because the compensation should be small as you say. But the difference in robot motion is very large.

What other information would be helpful?

4

Also, I don’t think limiters would address the continued rotation after sticks to neural. Observing the rotation after sticks neutral suggests that the voltage is being ramped down on set(0) instead no power to the motors.

5

Can we see code? Is that the only thing you changed?

Have you seen this thread?

6

Code and physical specifications of the drive.

7

Turning voltage compensation on and off is the only change made when the observations were made. I am not sure how to apply the information in that post to the situation we have. We doing joystick driving (open loop control I believe) and there are no feed forwards involved. See next reply for the code.

8

The drive base is 6 wheel tank, center WC gearboxes with two CIMs each. Wheels are 6 inches in diameter. Gear ratio is 18:1, motors to wheel. Encoders are on the wheel shafts.

The code is here.

In the DriveBase subsystem class we have a function to enable/disable voltage comp and then after that it is just joystick driving.

9

12v is too high for saturation voltage. This could be the problem if your drivetrain has a lot of scrub friction when turning, like if it normally drops you to 8V. 12V compensation would drive you far faster. Your saturation voltage should be in the 10Vish range to be safe.

I recommend adding open loop ramp rate (slew limiter) to combat this phenomenon as well, as it probably won’t disappear easily. Also consider increasing the center drop on your drivetrain.

Closed-loop speed control drive will also make the drivetrain more predictable and give you more to constrain, as you can constrain rotation velocity more directly.

10

What type of wheels are you using? How much scrubbing friction is there, typically? Can you verify what the commanded motor output is when you see the symptoms?

Voltage compensation has no effect when the motor controller is commanded to zero or to max output, so the situation you describe should not really be affected by voltage compensation unless the full throw of your stick is commanding less than full output.

Edit: As an aside, squaring the control inputs and applying a slew rate limiter to them solve different problems entirely. It’s not “one or the other” - they’re orthogonal, and you should probably be doing both.

11

I will look a slew limiter again based on your suggestion. You bring up a point about commanded output. I checked and forgot that we reduce the stick value by .75 to make the bot less difficult to drive. But even so, it seems to me that voltage comp comes into play when battery voltage is less than the saturation voltage and would just scale up our .75 power level to an equivalent value for 75% of the available voltage. I would expect the robot might be quicker to respond and reach a higher velocity but not at the difference we are observing. I will test removing the .75 scale down and see if that is affecting the results.

I don’t remember the name of the wheels but they are hard rims with little tread selected to make turning easy and there is plenty of center drop.

12

I am confused by this. From the reading I have done on CD and the CTRE doc, the saturation voltage should be the highest voltage you can run at. So there is no compensation with a fresh battery and then comp as the battery declines.

I see your point that the gap between saturation and actually battery can get large and might cause an unexpected difference in behavior. But wouldn’t 10v limit robot operation to a max of 10v? That would not be desirable.

Or are you saying the saturation voltage is the level where compensation starts happening and at battery voltages above that no comp takes place?

13

Disclaimer: I am not an FRC programmer, but I have dealt with these kinds of issues before…

As for the “jerkiness” of the robot, first, are the speed controllers in brake mode? That may be your problem right there. Beyond that, it’s probably, at least partially, because with voltage compensation, rather than scaling your control between 0% and 100% of available voltage, you’re scaling between 0% and 100% of maximum possible voltage, regardless of what the actual available voltage is, meaning if your available voltage is less than max, your controls become truncated beyond that point. This means that whereas before you would always have 0%-100% control range on your joysticks regardless of voltage, now if your battery is at 80% capacity, you only have 0-80% control range on your joystick, and the other 20% is just dead-band.

Technically speaking, with some practice, this would allow your drivers to have more consistent control at a given voltage, but it can be tricky to control, especially depending on the type of controllers you’re using. A proper PC Joystick, for instance, is going to have more mechanical resolution than an Xbox controller (simply because of the difference in size), so reducing that resolution on an Xbox controller even further by truncating the top-end of your control range can cause issues. To that end, running Windows joystick calibration might not be a bad idea.

In addition to what others have talked about, another option that might help would be to create a “minimum” voltage limit that your controller outputs (before skipping to “0v” at idle), since most drive systems don’t operate below a certain voltage, having that voltage as part of your control range is effectively a waste of your controllers resolution, since you’re not actually moving. So for example instead of 0-1 input giving 0v-12v of range, it would give you 0v, 3.5v-12v of range (the 0v being the idle position).

Just a thought, the actual programmers here can tell you if I’m totally off-base. It has been a while since I’ve dealt with this, so it might be totally different now.

1 Like
14

The voltage compensation on the Talon SRX occurs at the software level, not the hardware level. It does this by setting what 100% is no matter what the battery voltage is. So if you set it to 10V, as long as the battery is above 10V, the robot will behave the same. The Talon SRX example shows setting it to 11V.

Yes it is undesirable to limit the voltage. But it is a tradeoff. You limit peak performance slightly and increase predictability of controls and reliability of autonomous.

EDIT: It looks like @cbale2000 sniped me with a much more detailed answer that even taught me some things I didn’t know.

3 Likes
15

This makes a good deal more sense, and what you’re seeing is just the robot moving closer to its actual top speed - an output of .75 with voltage compensation set to 12V will result in the motor controller attempting to output 9V. This is probably closer to 90% duty cycle than to the 75% duty cycle that you’d see without voltage compensation.

If you can’t control your robot at top speed, you can reduce the speed further in code or, better, change the gearing of the drive. Often, I’ve found it useful to have a lower speed cap for turning in-place than for other movement - but this is only really easy to implement in an arcade-style control system.

16

A side question, is a slew rate limiter different than setting a voltage ramp on the TalonSRX controller? We use a ramp rate of 1 second currently.

17

Thanks to all for the information posted here. I still not sure I fully understand voltage compensation but I will do testing based on all this and see where it takes us.

18

No it does the same thing. Do you use ramping for open loop, closed loop or both?

19

Just to be sure I understand, open loop would be joystick driving and closed loop would be autonomous driving under control of a PID loop?

We use the ramp rate on both.

20

Open loop means that you are not using any feedback from sensors such as encoders while closed loop means that you are using feedback from sensors to adjust what you are doing. A PID is a form of closed loop control, but it isn’t limited to autonomous.

If you are just sending your joystick values directly to the speed controllers and do not have any PID or Feedforward (on the RoboRio or speed controllers), then you are running an open loop. You can use closed loop control in teleoperation to get better driving characteristics.

You can also run autonomous with either open and closed loop. An example of open loop control would be “Drive forward for 3 seconds.” For closed loop, you could use your encoders and a PID loop to control for position, allowing to you to tell the robot to “Drive forward 3 meters.”

2 Likes