As you can probably tell from my post history, I’m not nearly as active here as I should be. For those of you that don’t know me, my name is Nick Mertin, and I was the head programmer for Team 5225A, The E-Bots PiLons during the 2017-2018, In The Zone season. I have since graduated, but still remain a mentor for the team.
Over the past couple of months, myself and the other programming team members and alumni, by popular demand, have been working on a document describing our Absolute Positioning System, including both the theory behind the odometry, and instructions on how to implement it from scratch on a robot. This system has been instrumental to our success over the past two seasons. Though we initially aimed to release it by the end of August, we ran behind schedule (as usual), and so it was not ready to release until this weekend. It is now posted on our team website here:
We hope that this is a useful resource to everyone. If anyone has any questions, myself and other programming members/alumni from the team will be checking this thread, the unofficial Discord chat, and our team email ([email protected]).
Thank you so much for this. You have no idea how vital this document is to me. Yes, I mean vital as in I need it to live. Position tracking is not a choice.
Hey, quick update, as the Pilons website is currently down (we’re trying to fix issues with our hosting provider), I’ve rehosted the document temporarily at https://nickmertin.ca/Tracking.pdf.
I am working on an implementation of your tracking algorithm myself and your document saved me dozens of hours of work, if not more. Thank you so much for releasing it, and also thank you for not releasing your source code. It has been a huge learning experience
Truly very impressive. Thank you for sharing! 5225 has been a pleasure to watch over the years and has clearly proven to have world-champion worthy controls software (literally)
While the arcs are very interesting, I’m curious as to how necessary they are given the resolution of VEX encoders and the refresh rate of the cortex.
Have you ever compared the accuracy of this to a simpler form of odometery estimation? For example, one might simply average the left and right encoder travel for the distance and multiply that by the cosine and sine of the gryo heading respectively to get <x,y>. While its true that the real motion of the robot is an arc, the curvature is likely negligible at 60+ hZ. in other words, is chord across this curve a sufficient approximation?
When you average the left and right encoder, you are essentially calculating the chord under the arc that the robot traveled. You don’t actually need to know the length of the arc.
Sorry I misunderstood your original question. Coupling it with gyro would definitely work, although I wouldn’t recommend it due to significant gyro drift with V5. We got much more consistent performance when we switched to all encoder based movements.
We used it in the beginning with our turning point robot, but we ran into a variety of time-wasting problems while using it so we decided to completely ditch it once we switched to position tracking.
Also, the way the encoders are used to calculate the angle of the robot is essentially the same as using a gyro, but it’ll be more consistent.
No, 5225 never used a gyro in ITZ. If you have two encoder wheels that are parallel, that will give you robot orientation; you don’t need a gyro.
Regarding the type of approximation used, the two simplest ways to approximate robot movement over a single cycle are an arc and a line. Either should be identical for infinitely small cycles and infinitely precise encoders, but in our experience, modeling it as an arc seems to be more accurate.
On equation 6, I don’t know if that symbol is cross multiplication, or just scalar multiplication. either way, I also don’t know the order of operations in which i have to use. please help, and thank you for this amazing document.
