Holonomic Programming

Hey everyone, I’m currently engaged with a holonomic x-drive machine. I’m wondering how you all go about programming for autonomous. Does anyone have any tips/tricks to programming holonomic drive trains for autonomous in easyC? Thanks.

PID’s your friend in autonomous.

To elaborate on that, I wouldn’t use time-based movements for the autonomous, because such movements using time are very vulnerable to being thrown off by battery voltage if not accounted for properly.

I’d put encoders on the wheels to help keep track of distance. Although due to the nature of the X-drive, you’d be using the omni-wheels and the “knobby” rollers might cause some jittering side movement, potentially throwing off the encoders. I don’t see that being big enough of an effect in autonomous though. I’d also use the optical encoders as opposed to the IMEs since those are more reliable.

I’ve done a lot of work programming autonomous routines with an x drive in an independent study this past semester with @Lorenzo Melendez. To compensate for drifting and other tolerances we ended up having 4 different PID loops running at the same time (yay). Running 4 encoders definitely helped a lot here. We had one for side to side drift, diagonal movement, and turning all at once which we called “stabilization code” and another loop for general distance tracking. The way this worked was comparing and averaging different encoder values. It’s a real pain, so half way through we decided to rotate 45 degrees and call it a plus drive. However, it worked well enough that we could kick the robot out of its path and it would recover.

Thanks, all. I appreciate the input and I will begin working on a PID for all our autonomous motors. Wish me luck!

I’m working this issue and am planning on doing something kind of like what @mwang17 is talking about.

It’s still in the works, but the idea is this:

First, create a mode that maps the wheels. It’s simple really, for a given input, watch the encoders and figure out what the wheels actually do, then adjust. Ideally you’d end up with a 2D graph for each wheel that remaps a requested output to an actual output. That table becomes a lookup table for all future motor calls, and of course gives us a scaffolding to do other neat motor things like what James did with his code that stops the PTC’s from blowing in code by approximating current draws.

So you have wheels that go the speed you want them to now. Great!

So the next task will be to track the robot numerically. Ideally you’d go batsh crazy and bust out a Kalman filter and throw every sensor you have at the problem, but for now let’s just do it with four encoders.

Encoders are interrupt driven devices, so we should be able to poll them much faster than the typical 20ms, @jpearman I’d love to confirm that.

So every (let’s say) 1ms we take a peek at the encoder values and essentually try to figure out how the robot moved. We can do some approximation here, but there are a few numerical methods that can do even better, so we do that and now we have a pretty good guess as to where the robot traveled in the short amount of time.

We keep track of these translations and just as @mwang17 mentioned, we run big control loops that watch the big picture, make sure the robot isn’t drifting in each plane, make sure it isn’t rotating, etc.

These loops all command various motor values and we put them all together to form a new heading.

Now you’re also going to need a good exit condition, this can be done with control loops and sampling.

That’s my plan of attack at least. Right now I’m learning AD Fusion 360.


Sure, quad encoders (the red ones) will update at the speed of the interrupts caused by rotation. If the encoder is driven directly by the motor, and the motor is running at 80rpm then there will be approximately 480 counts/second or put another way the encoder count will change about every 2mS.

IMEs work a little differently, update rate is determined by the number of IMEs installed so with 4 IMEs they will each update about every 4mS.

Be careful using the D in PID at high rates. If you sample too fast you will have very low resolution in the D (derivative) because you didn’t give it time to change.

PID is great to keep the robot traveling straight. TriDragon has a point. You can use the real time clock to meter the main loop to something like 20 mS per loop.
Anyway, back in 2015 I mentored the a sky rise competition team at Grand Blanc Middle School in Michigan. Go Gear Mashers!
We developed a navigation system for use with autonomous mode. This uses an encoder on each of the four omni-wheels. We track the robot’s position and angle on the floor. This attached derives the math and has links to KhanAcadamy videos. Let me know if there are questions. Good Luck!
GearMashersNavigation4b.pdf (621 KB)