Hey guys,
I had been doing a small study in PID because our x-drive is resulting to be a little inaccurate when driving into one single direction due to motors not giving the same RPM. We’re trying out 4" wheels going at 300 RPM. Our objective is to make sure all wheels are going at the same RPM when going forward, sideways, diagonal and rotation movement.
-In driving mode and not in autonomous, how will the PID react with dynamic/variable input from an analog joystick?
-How does a PID reacts when a second analog joystick input is presented?
-How will it distribute the current to the motors knowing that I’m driving forward and left, causing a diagonal movement?
I need some lead here to understand how it’s all gonna work before programming it in ROBOTC and I believe it’s gonna be an ugly yet beautiful if it works.
Thoughts:
Maybe 300 RPM is too fast? It’s multiplied by sin(45) to achieve the equivalent RPM at the front direction which is around 255 RPM. It’s a bit faster than Turbos in tank drive.
PID control doesn’t really make sense for most driver control setups. The joystick changes to often. PID is all about reaching a goal value (in most VEX cases this means goal locations) and with something dynamic ID wouldn’t make any sense.
Some of your RPM math is confusing me. Can you clarify what the mode the motors are in and what the external gear ratio is?
Firstly, with the RPM, I just finished doing tests with RPM at each motor value. I had one test that gave me 310 RPM with direct turbo on 3.75in omni. Once I averaged my 8 tests I got around 280, so if you externally gear it, you would be getting a lot more than that.
For the autonomous, you can have a gyro that keeps the robot going straight. If it starts to drift right, the robot will correct itself. If it starts to go left, it will correct itself.
For the PID with user control, exactly what @tabor473 said. You don’t need PID for driving, it is unneeded.
Aaah makes sense what you guys said. Then what’s the trick to assure you’re going forward with minimal direction error at high speeds in user control? Maybe I need to tone down the RPM.
@tabor473 We’re trying out a 4-Torque motor holonomic base with each wheel pointing at 45 degrees. The external gearing is the 36t gear as driver gear and 12t as driven gear which is the wheel’s shaft. Knowing that the torque motors goes at 100 RPM, the wheel will go at 300 RPM. When you convert it into the linear velocity of the robot, it’ll be nearly equivalent to a robot with direct turbo tank drive. At least that’s what I understand.
On the vex website, the RPM’s are all smaller than they actually are. Meaning torquqe goes over 100. I got 310 out of turbos, so this could easily be 350 RPM
@Unionjackjz1 Well in summary, the configuration I have will barely be controllable if I keep the external gearing.
@tabor473 It’s for competition but I’m testing out simple bases for the sake of testing PID at specific velocities. I do have in mind that 4 motors at that velocity will struggle with any load as you said.
This clears a lot of things, guys. I appreciate the help!
Running velocity control doesn’t necessarily mean that they all achieve the same velocity at the same time, just that eventually they would have the same velocity.
To expand on the original topic of this thread, how would one get autonomous PID/position tracking working in autonomous on an X-Drive? And to repeat what Yerayrobotics said, how would you make it drive as straight as possible during driver control (when you want to go straight of course)?
Literally everyone wants to do position tracking with X drives lately O-o
The X-Drive code I texted you works just fine for driving, but it wouldn’t track position very well (assuming you are using turbos). There is slack in the wheel, and sets yourself up for errors.
Tracking wheels. You just need 3, but 4 might be better for holo. Passive, unpowered wheels on each side of the chassis. IME’s aren’t worth using because of the motor slack. This would make all of your positioning a lot more accurate.
And because you are using 4 shaft encoders, you might be able to get away with calculating angle based on encoder values… Play around with that, because gyro’s aren’t to fun to get working. 100% worth it once you get it working though.
Text me if ya need helpz, or just call me and scream at me, both work great (I prefer being yelled at)
Setting one drive encoder as the “master”
Having all the other encoders be the “slaves” and follow the master
That would be tedious to set up on an X-Drive, but totally possible. Every time it turns, clear the encoders, run a masterToSlave function, and there you go
EDIT: The only problem I see with this if the robot is off balanced. It might make it curve… I would honestly just use a gyro
@Poseyhead You can do position tracking on the holonomic base quite well. Just shift your coordinate system to match the wheel directions and control X Y with independent PID loops. It works especially well for longer distances. Shorter distances in PID can be problematic in getting your robot started moving.
Throw in a gyro for keeping the heading too and add the rotation on to the X and Y directions. But if you do that I would have the X Y and rotation calculations all in one task versus separate tasks since the rotation wants to play with the X and Y motor signals.
To program it, figure out the X Y distances needed for the wheels and program them in as your X and Y targets independently. I recommend having the gyro keep a heading versus changing a heading during this time to simplify your code. The shorter distance coordinate will track first, so your robot moves in a curve and then you get straight movement on the second coordinate as it tracks to its value. Just keep the coordinates relative to the robot wheels versus worrying about the field X Y coordinates.
