Hi all! I’m building a robot with my money to finalize my arduino-wifi control system. Before I spend my own money on a lemon I want to know what drive system I want going to go with. I was wondering if any one had experience with 4 wheel X shaped omni drive. like this http://i.ytimg.com/vi/Z0lUTMBbu9A/maxresdefault.jpg
I don’t want to spend money on encoders. I programmed encoders on my teams bot this year for mecanum, I just don’t want that headache for this
So basically, can I even drive in straight line with this, or is it just as bad as encoder-less mecanum?!
It should be fairly simple to add a gyro to that bot.
The gyro can easily be used to stabilize rotation without the use of encoders.
Encoders would still be needed for certain functions, like controlling distance, but they would no longer be needed for maintaining a heading.
From a scout’s perspective, robots with that drive tend to be …iffy… like, unstable and not that mobile. now 1425 on the other hand, was super elegant and mobile in 2014 on Kiwi drive, so maybe it’s just a matter of building it well
Hate to burst your bubble Dunngeon, but the gyro stabilized Kiwi drive in the video has no PID control at all.
I’m not saying that all omni drives would not need it, I’m just saying that this one didn’t. I have a suspicion that it is entirely dependent on the drive train and how the control code is implemented.
Interesting, I didn’t realize that teslalab2 was referring to your video.
The reason I said yes to the PID loop is that if the end goal is to have something be held by the bot, or for the bot to be heavy, our team has had very good success using P-control in those scenarios (very little oscillation, if at all).
In your heading control are you just adding a rotation value to make it rotate in the opposite direction whenever the heading changes to something other than 0 when translating?
I’ve seen a lot of PID and that oscillation is DEFINITELY characteristic a PID loop with just a little bit of tuning left to do. I havent seen the code obviously but thats what it seems like.
While I don’t have any experience with this configuration per se, the kinematics on the four-wheel killough drive are the same as mecanum, which we used for Aerial Assist. This means that you can use the canned “holonomic drive” class/block. For AA, we did not use encoders. We added a gyro so we could use “field coordinates”, but we did not get it working for competition (it turned out to be a bad gyro). The drivers never expressed any problems getting it to drive in a straight line, in any direction. As with mecanum, you will want to balance the load across the wheels as much as possible, and I’d also recommend a flexible frame or a suspension to keep all wheels on the floor. If you are planning to take it over humps and dips and don’t have some sort of suspension, expect lousy performance, including unintended rotation.
You are correct, I had made the assumption he was referring to my video based on the sequencing of the posts. So, if my tone was a bit offensive, I apologize.
The basic code I used for Kiwi drive is:
Wheel1 = -1/2 X - sqrt(3)/2 Y + R
Wheel2 = -1/2 X + sqrt(3)/2 Y + R
Wheel3 = X + R
Where X is the x-axis input, Y is the y-axis input, and R is the Rotation input.
When I added the gyro, the code was modified as follows:
Wheel1 = -1/2 X - sqrt(3)/2 Y + (R + gyro)
Wheel2 = -1/2 X + sqrt(3)/2 Y + (R + gyro)
Wheel3 = X + (R + gyro)
Fortunately the scale of the gyro input matched the original values in the control that I really didn’t need to change it’s scale at all. Later experimentation’s determined that a P gain of 1.2 yeilded the best overall performance, but leaving the P gain off was sufficient for prototyping and education purposes.
As seen in the code blocks above, the loop is closed by adding the heading value from the gyro. A “P” gain can be implied to be 1, but for the video, no gain was actually applied. It was simply adding the heading to the rotation input.
that makes sense of how a plain p controller would work well for a gyro. Also, you shouldn’t be getting any oscillations in a PID, that is partially the point of a PID. If it is tuned correctly. You can get oscillations however if you use too much Ki., that constant needs to be very low. Our robot this year with mecanum had encoders with PID’s. I spent days tuning it, but when everything was said and done, the PID could account for 6 totes and a container on our robot, and it would strafe with very little deviation.
Anyways I am still torn on which Drive train to go with, I could not find a video of an FRC robot with omni on youtube. Does anyone know of a video of one?
I would like to make the observation that an ‘X’ shaped omni-wheel drivetrain cannot rotate.
If the center of gravity is along the line of action of all 4 wheels (ie: in the intersection of the ‘X’ [ie: in the middle]) no wheel can exert a moment on the robot generating rotation.
An ‘O’ or diamond shaped configuration can turn by moving all wheels clockwise or CCW
The picture you show is a diamond shaped Omni drive, and it drives very well.
It has the same motion profile as a mechanum drive (direction of forces and slippage) and the same drawbacks (low resistance to being pushed, less thrust in direction of travel).
PID is not needed for this drivetrain but it can help if the motors (or frictional drag) are not closely matched. A gyro will allow you to do some field-centric control (however it also introduces gyro drift), otherwise the control will be robot-centric which gives some drivers issues.
I had to do a bit of googling to learn this, but the term X drive is used in the Vex community for the 4-wheel Omni drive FRC usually calls Killough. If you pay attention to the **axles **instead of the wheels, you can see the X.
Here’s a clip of 2077’s first effort with a three wheel omni, back in 2010.
There’s no footage of it driving straight, but it did that just fine, with a very simple proportional feedback from the gyro in the main drive loop, applied only when the rotation control input was zero. The gyro was also used for field-relative driving, what was really being demonstrated in the video.
A couple of amusing robot behaviors we saw in this machine:
If you walked up to the robot while it was enabled and sitting still, and rotated it by hand, it would return to its original heading by itself.
Occasionally we would put the robot down for a test and it would slowly rotate for no apparent reason. We eventually figured out that we’d been powering up the robot while people were positioning it for the test. If the robot was moving during gyro calibration it had a different notion of “no rotation”.
Of more practical significance we learned:
Simple gyro feedback is fine for solving the “drive straight” problem, either with omnis or, as we later learned, mecanums. We later learned to use encoders, but they’re not essential.
The small omni wheel roller radius adds a lot of friction to sideways motion on carpet, and with this configuration at least two wheels always have a sideways component at any time. This robot was unacceptably sluggish in competition.
Three wheels are a perfect solution to uniform wheel loading, but with only three CIMs that could never all be fully applied to linear motion at once, it was way underpowered.
On the balance, I like mecanums better, because the friction losses seem smaller (larger roller diameter) and more importantly, not so uniform in different directions. The less the rollers are turning, the less power they waste, so forward/back motion is much more efficient with mecanums. You lose it back when moving sideways of course, but you normally do that less.
I want to know what drive system I want going to go with. I was wondering if any one had experience with 4 wheel X shaped omni drive. like this http://i.ytimg.com/vi/Z0lUTMBbu9A/maxresdefault.jpg
