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.
Thank you. Is there anyway to try and keep the variation to a minimum? Sorry if everything is under defined again.
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?
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
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)
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:
- Define the path you want the robot to travel down
- 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.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.