My team just gave programming the robot to begin testing code on. After testing the code we had written we noticed that driving is a bit of a harder task than we thought. We are using a 6 wheel 8 in pneumatic wheel drive system with 4 falcon 500s. It is also driven by chain. We are currently using Xbox controllers and the wpilib arcade drive. In previous years we have used 2 joysticks and done tank drive but we really don’t want to go back to that unless absolutely necessary.
The most difficult thing is speed and turning right now. We have some deadband and on the controller and we have tried brake and coast modes to see if that help with the extreme jerkiness. We are multiplying our input by .6 so that’s what it’s capped at but the ramp up is not all that helpful right now. One major downfall is that the drop center for the drain train is not near generous enough (1/8 in I believe) so turning is doable but not great.
Does anyone have any suggestions on how to make driving a bit easier from a programming stand point? Thanks so much for your help!
Based on my experience with our 2019 bot, driving is gonna be a little jerky, but also I believe something most teams do is squaring their inputs? I’m not a programmer so I’m not really sure, but yeah. Pneumatic tires aren’t great to drive with imo
Inflate the middle tires on each side several psi higher than the ones on the corners. This will enhance the effective drop center and make driving/turning more reasonable. It definitely improved handling of 3946’s nanotube chassis air cannon in fall 2017. I don’t recall exactly what pressures we used, so a bit of experimentation is in order.
If you do this remember to invert inputs that were originally negative, or you will only be able to drive forward (or spin, depending on how your motors and code are set up).
Try some omni wheels in the back or front.
RoyD
Something I like to do for that is cube the input instead of square it. It keeps the original sign, but obviously it changes the function a bit.
output = input * abs(input) gives a square response curve while maintaining sign.
For wheels with a lot of “turning deadband” due to scrub, this is going to make things much worse.
Using a higher-order polynomial allocates a greater portion of the joystick throw to low outputs. If those outputs are being “swallowed” by wheel scrub and friction effects, what you’re actually doing is shrinking the range of joystick values that are useful for controlling the robot.
If you’re in Java,
output = copySign(pow(input, 2), input);
Works too
I can confirm tire pressure difference will let you turn much easier.
As for the omnis being added to the corners, the difference in behavior is significant:
With no omnis but using 8 6" pneumatic wheels, this robot can turn fine but if you do a zero turn you get this nasty hopping with 1/8" drop that can be mitigated with tire pressure changes:
With corner omnis you can dead spin all day with 4 pneumatics center and 4 outer omnis like so:
In my experience you can get away with .125 drop on six 6" pneumatics but one you get to 8" you need to go at least .1875".
The longer your chassis is the worse the steering will be too.
While drive inputs may or may not be the solution to your problem here (I’m guessing that they’re not), drive inputs being adjusted by a function other than y=x is still something that can help immensely, if tuned to your driver’s preferences. I’ll try and help to explain as best as I can with only an Algebra background.
Below is a graph I whipped up in Desmos, showing 5 example functions that you can multiply your input (x), by to get your output (y). This can quickly and easily change the characteristics of how your mechanism responds to inputs, especially when paired with a clamp() or “deadband.”
The important things to note on the graph are how the y changes in regards to x (output in regards to input, slope). For my go-to drive function,
y=x^2, the output at 0.5 (50%) input ends up being 0.25 (25%). This is my happy medium for less sensitive control, but YMMV. The only use in my experience for an exponent <1 is to make a prototype shooter wheel spin up faster, but I’m sure there are others.
+1. Be very careful of over-sensitizing your robot’s drivetrain past what makes sense for and helps you given your scrub and drivebase power.
Anyway, hope this helps!! Functions can be your best friend when tuning mechanism or drivebase motion, (PID, anyone?) but make sure you test, test, test, and find what works best for your situation.
It is worth noting that the WPILib drive classes square the robot control inputs by default, so if you are using that you do not need to square them yourself.
Has this been the case in past years as well? Or is it a new feature? Either way, I had no idea that this was something that was built in.
Another good one is (1-a)x³ + ax. It lets you select your slope at zero (a), but gets you to full throttle at full joystick. See @Ether’s classic white paper for more details.
Omni wheels are the answer. Last year we had similar driving problems with pneumatic wheels. No coding fixed our problem. This year we are running four pneumatic wheels and two omni wheels, with F500s and all of the issues we encountered last year are gone.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.