# Driving speed consistency

How consistent is driving given the battery voltage? As in, if your controller motions were the exact same during two separate robot runs, and your using high-performance motor controllers like spark-maxes, how separate would the runs be if the first one had your battery fully charged and the second run had your battery at lets say 80%?

As stated, your problem is a bit under-specified - the threshold for â€śconsistentâ€ť varies depending on application. But, Iâ€™ll make some assumptionsâ€¦

On most of our botsâ€™ drivetrains, with that battery voltage variation, assuming a control strategy of â€śapply full battery power for duration, then zero battery power thereafterâ€ť, Iâ€™d expect at least three inches of error over every foot of travel. That number is a total guess, but just trying to put some scale to the level of inconsistency Iâ€™d expect.

As you add more variation like rolling resistance against carpet, friction from chains and gearboxes (and whether you greased them right or not), electrical lossesâ€¦ that error will definitely get worse.

You can make some assumptions and run some math, but itâ€™s probably better to experiment on the physical bot itself. The assumptions are hard to get right.

For any application where less than 25% error is required (which is the vast majority of my teamâ€™s applications), weâ€™d want some form of feedback. Sometimes this is closed-loop control, sometimes this is a driver looking at the thing and manipulating joystick controls.

The takeaway: Generally, solid & low-error control systems will need to account for battery voltage variation, in some way.

2 Likes

Thank you. Is there anyway to try and keep the variation to a minimum? Sorry if everything is under defined again.

Sure!

The absolute easiest way (from a lines-of-code perspective) is to build the mechanism in such a way that itâ€™s easy for a driver to see it and adjust it to the right position. â€śHuman in the loopâ€ť is a totally valid strategy.

However, sometimes itâ€™s not practical or possible to put a human in the loop. If this is the caseâ€¦

For motors: The easiest way is to use a motor controller which has a â€śconstant output voltageâ€ť control mode (Spark Maxâ€™s, Talon SRXâ€™s, and others). Command the motor controller to output something between 0 and 8-ish volts. Youâ€™ll be fairly well guaranteed that the motor controller can maintain this output, as long as the battery voltage stays above 8 volts. This will definitely help with consistency.

This works because, without any external force, motor speed (in steady state) is proportional to applied voltage. However, the transient behavior of the motor (while it gets to that speed) or behavior while varying forces are applied isnâ€™t quite as straightforward.

In cases where your goal is actually â€śget the motor to spin at a certain RPMâ€ť or â€śget the motor to move to a certain positionâ€ť, youâ€™ll generally need some form of feedback control.

This means you add a sensor to the mechanism to measure itâ€™s actual behavior, and do some math on the actual & desired behavior to command the motor. If you are careful with how you design the math, the actual behavior will match the desired behavior.

How that math is designed is a whole topic unto itself. Bang-Bang, PID, State-Space are some of the buzzwords in this area. Thereâ€™s a range of options from â€śvery simpleâ€ť to â€śvery complexâ€ť, and which one you choose really just depends on the requirements of the application.

Generally, my strategy is â€śstart simpleâ€ť then â€śadd complexity as neededâ€ť.

What are you looking to do overall? Is this related to some form of autonomous routine where youâ€™re moving the robot to a fixed position on the field? Or is this about getting a shooter wheel to a certain RPM before taking a shot? Or perhaps moving an arm to a certain position?

2 Likes

As said earlier you always want to add in feedback. I was curious about how consistent it is even if you get a constant voltage so I ran some calculations in MATLAB right now given data we had already collected. The standard deviation in distance traveled (not displacement in any direction, just total distance. Sadly you canâ€™t do the math as easily if you want displacement in a direction since the equations get messy with a sine and cosine term because theyâ€™re not linear functions) was about 0.04meter^2 and for change in yaw 0.006 radians^2 after 5 seconds of movement. So 68% of the time, youâ€™ll get a consistency of 7.8 inches and 4.4 degrees. And thatâ€™s just for 5 seconds of motion! (I tried 15 for a full auto but rounding errors made the calculation too numerically unstable to give any useful answer) So definitely use feedback, obviously the numbers will be different for your teamâ€™s robot but if its anywhere near ourâ€™s then itâ€™s probably too inconsistent in open loop

1 Like

Alright, thank you. The reason I asked about this is since Iâ€™m not a very good programmer, I wanted to try and shortcut autonomous. I wanted to try and make an â€śautonomous recorderâ€ť so you could control the robot for 15 seconds and simulate an auto routine, and then through recording something like voltage or encoder ticks during this time play it back as an autonomous program. Iâ€™m pretty sure this has been done before, but again since Iâ€™m a bad programmer Iâ€™m not sure how to go about accomplishing this. Any help is appreciated!

Oh thatâ€™s a pretty cool idea! Maybe try looking at code releases from teams that have done that before? What comes to mind would be writing encoder ticks and ticks/100ms on both sides to a file on the RoboRIO and then in auto reading the file during init and executing it. If you have TalonSRX/FXs, they have some functions to let you drive them through specified waypoint ticks and tick velocities, so you could load in those trajectory points, idk about the Sparks though. Even then thatâ€™s pretty complicated code wise. Your best bet might be to use the new WPILib RAMSETE controller: https://docs.wpilib.org/en/latest/docs/software/advanced-control/trajectories/ramsete.html . Itâ€™s not a simple plug and chug since you have to characterize the robot first but that isnâ€™t too bad either, and once thatâ€™s done you can just specify coordinates and itâ€™ll do all the math and trajectory tracking for you. Hope this helps!

Ok, Thank You!

a simple way my team used to our ensure distance is consistent every time is by using an encoder,

encoders give a value based on a set distance per revolution, in our case, we set our distance to 12 inches per revolution of a shaft, so if the encoder rotates 3 times, we traveled 3 feet. you can also use this to sync 2 sides of a drive train together.
even if battery power was low it will work( just might be a bit slower)

this even works for shooters, if you set your hooded shooting wheel to 10000 RPM, the encoder will increase its speed until that goal is reached and maintained (this is good for shooting different distances)

1 Like

Yup, this is not a bad idea at all! Iâ€™ve heard a few teams try it out (though Iâ€™ll be darned if I can find any code to do itâ€¦ other than that other thread).

With all solutions, the main thing I like to keep in mind is, â€śhow can this fail?â€ť. If you record and play back motor commands, youâ€™ll have variation based on battery charge (as you properly identified). If you record and â€śplay backâ€ť encoder ticks, your wheels may still slip.

No system is perfect, so youâ€™ll have to pick something that acts â€śgood enoughâ€ť to score the points you want on the field.

IMO, especially with the experimentation time we have available, try a record/playback mechanism around motor voltage (SRX/MAX constant output voltage), and see where it takes you. I suspect, if implemented properly, and not driving too fast, itâ€™ll get ya pretty far.

Iâ€™m trying to limit the inconsistencies, and if we record encoder ticks, my reasoning is even though there will be variations, they will be the same as if you used pathplanning and a ramsete controller, or any other method for local during autonomous

Possibly. â€śSame asâ€ť can be a very loaded phrase.

Thereâ€™s two main parts to getting any sort of path-planning implementation to work:

1. Define the path you want the robot to travel down
2. Write logic to command motors, such that the path gets traversed.

Recording encoder ticks accomplishes 1, but doesnâ€™t directly address 2. From what I understand, Ramaste actually attacks 2. â€śpathplanningâ€ť, tends to focus on 1, but may tread into 2 as well.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.