98881A Odometry Devlog


Yeah, implicit conversion overloading is your friend, so this:

Angle theta = 3.14159

Is valid. Also, you can do things like:




You might want to look into Okapi’s Units API that comes with PROS. It does all this, plus dimentional analisys and other cool stuff.
I find it really useful to use when writing code, I can have an abstract length object which I can convert to any unit. You can do things like

QLength length = 2_m;
length += 2 * cm;
double lengthmm = length.convert(millimeter);


Oh that looks pretty cool, I’ll have to look into it later.

1 Like


Devlog #2 is out, check it out here. It shows neat mecanum maneuvers. Ever want to turn while driving straight? Well now you can!:

Also, here is a playlist that will be updated as more devlogs come out: https://www.youtube.com/playlist?list=PL28w3_L_ZO1XlVowKmFPisOxE4VCZXkm8



Wow! That looks really cool. Great job.

The largest issue I had last year with odometry and motion was the momentum of the robot.
When it would decelerate to the point, I needed a PID to stop the robot when it got to the point. It needed to settle for a tiny bit, as if there was a sudden stop the tracking wheels would lift off the ground.
You obviously don’t have that issue with your light base right now, but just a heads up for later.
One thing you can try next is to figure out a way to settle on a point and hold the position.
Then you can create settling logic for autonomous that lets you control how precise/fast the movement is.



That’s a good point, the maneuvers I have programmed so far are mainly for getting to a place as soon as possible, and as the video showed they don’t really give time to settle.

Right now, the maneuver methods exit when the distance from the point is less than a certain tolerance (and/or angle if that is taken into account). I’m going to make other maneuvers that require that the robot be in that tolerance for an interval of time instead of just one odometry tick.

I should also strap some weights to the robot and see how it reacts.

On a separate note, I should also program a “return” button that interrupts the current maneuver and makes the robot come to 0,0 with angle set to 0. Then I don’t have to get up constantly to retrieve it.

I also want to test something I call “absolute drive”. Instead of regular mecanum drives, where everything is relative to the robot, basically hitting right on the joystick moves the robot right relative to the driver. More on that later probably.



I’ve seen something like the ‘absolute drive’ done with a gyro to find the angle, and then some trig to figure out how to move, but tracking wheels instead of the gyro would probably be a lot more accurate, with less sensor drift.



do you recommend the quad encoders than the builtin encoders?



Absolutely. Although the IMEs in the smart motors are much better than what we had for the cortex, they still have a few disadvantages for accurately tracking position. One issue is that you are tracking the motor’s position, not the position of the wheel’s axel, introducing a bit of slop. The other is that even in the best case scenario the IMEs are tracking the positions of your robot’s wheels, not the position of the robot itself. When your robot accelerates, the wheels will slip, causing your sensor values to no longer represent the actual location of your robot. That’s why we use the quadrature encoders on unpowered tracking wheels. Because there is very little resistance on these tensioned tracking wheels they track the movement of the robot in a way IMEs could never accomplish even under ideal circumstances.

That said, if you don’t need near-perfect accuracy for your autonomous and would rather keep the 6 sensor ports tracking wheels would occupy, that’s understandable. If you want to take our rode, it’s a fantastic learning opportunity, but it’s far from a necessity to have a good robot. Even without tracking wheels we had great success in autonomous this past season.

If you’re on cortex PLEASE save your sanity and forget that IMEs even exist. The IMEs for 393 motors are essentially satan given material form and will not only do a subpar job tracking position but will also accumulate static and cause unwanted side effects on the cortex itself.



Ok thanks for the quick response!
So, is it weird if my robot angle calculated through the v5 motor IMEs off by a lot of degrees?
Could it be my calculations? <-- I think so.
And how did other people calculate the encoder ticks into inches? I personally calculated the degree the wheels turned and used an arc distance formula to make it into inches. Are there other methods?
Thank you.

1 Like


For your first question, do you mean it is offset as soon as you run the code, or do you mean after a while? And how much is a lot?

As for turning degrees into inches, I’d use circumference * (deg / 360). I literally woke up 2 minutes ago though, so take that with a grain of salt. :​P



This is sorta redundant, but mathematically circumference * (deg/360) is identical to the arc distance formula @kickthepokehi asked about.

The full formula, including circumference calculations, of your solution is 2πr*(deg/360). The arc distance formula is r*rad. the conversion factor between radians and degrees is π/180, which is equivalent to 2π/360. Therefore, the arc distance formula can be rewritten as r*(deg*2π/360), which is equivalent to the circumference equation via the commutative property.

The rest of this is a response to @kickthepokehi

Getting back on topic of this off topic discussion, it is reasonable that the IMEs’ angle calculation incurs error over time; there is a lot more wheel slippage than you realize. We used IMEs for angle calculations for a while in TP and by the end of autonomous it could be up to 15 degrees off. Obviously that was an extreme case and error to that magnitude didn’t happen especially often, but I needed to mess with a lot of acceleration control to keep the angle tracking accurate. When we switched to tracking wheels our angle measurements were perfectly accurate and consistent no matter what we did to the bot.

That being said, the code could be an issue too. Make sure you are calculating the angle with some variation of (right distance - left distance) / distance between wheels, which should return the orientation of the bot in radians.



Yep. I knew I’d say something stupid. :​P

I’m sure @kickthepokehi knows this, but just in case I’ll mention that absolute position tracking is not possible for a tank/mecanum drive using just IMEs because you need to track more than one axis. (The IMEs would only track one axis in these drive configurations because the wheels are parallel.) You can still track relative movements fairly accurately, but keeping track of the robot’s absolute position is out the window unless you add a perpendicular tracking wheel.



Actually, it might be possible on mecanum since the wheels go opposite of each other when the robot moves sideways.

If you observe mecanum wheels, they look like an x-drive since the part of the wheel that touches the ground is tilted as such.



Hmm. I suppose the 2 IMEs on each side of the drive wouldn’t actually function as 1 on a mecanum drive. I wonder what the math for that would actually look like. Probably similar to an x-drive, though I’m not sure how you would accurately convert the degree values to distances in each axis. That would be an interesting project to try out.



I would start with the math for finding speed values for mecanum and work backwards. Maybe represent a set of speed values as a matrix, then find the inverse? I’m gonna play around with that right now



The smart motors should already be able to output velocity, right? I know they have a velocity value being processed internally.



yeah they do.

also I figured out how to get directional speed from mecanum IME values (though i havent tested it):

Leftward velocity = (back left wheel - front left wheel) / 2
Turning velocity (to the left) = (front right wheel - back left wheel) / 2
Forward velocity = Front left wheel + Leftward velocity + turning velocity



Is the angle consistently around 10 deg off no matter how you turn it? If so make sure you rotate all of your wheels all the way in one direction until they meet resistance. Even without external gearing there is enough slop on your axles to cause some inaccuracies if you aren’t careful. If that’s not the issue, I’ll have to think a bit harder.

If the angle error grows as you turn the robot, then it is something in the code. Sadly I don’t have the time to look over your code at the moment, but I will take a look as soon as time permits.



I think your math for mecanums is slightly incorrect, because if you use values from just two wheels you are going to miss movement when it both translates and rotates. For example, forward speed should be an average of all values.

 Forward  = ( FL+FR+
              BL+BR )/4
 TurningL = (-FL+FR+
             -BL+BR )/4
 Leftward = (-FL+FR
             +BL-BR )/4
1 Like