3 Wheel Odometry turning issues

Programming Support
,
1

Hello!

I am a new coder for a 2nd-year vex v5 team located in a rural area. I have been trying to code an odometry system for the Override season after our autonomous code for pushback was incredibly inacurrate. No one at my school has done anything like this before so I don’t have any resources aside from what I can find online. This is also my first major project in python/text. My system has two horizontal dead wheels w/ encoders (left and right) and one perpendicular dead wheel w/ encoder (back). It is set up like the examples in Odometry | Purdue SIGBots Wiki .

When using only the left and right encoders, the code works fine, and the position updates normally; however, when I try to add the back encoder to account for the arc, the x and y start gaining when the robot turns and after a little under 180 degress they start decreasing. The offset for the back encoder is about 7.5".

I am not sure how to fix this and I would appreciate all the help I can get!

Here is my current formula for the back encoder (I code in VexCode Python):

if deltatheta == 0:

    deltaB = (currentBposition - prevBposition)

else:

    deltaB = 2 \* math.sin(deltatheta/2)\*((currentBposition - prevBposition)/deltatheta+TB)

I got this from the arc length formula by looking at the Odometry | Purdue SIGBots Wiki

article but I might have used it incorrectly.

I then subtract math.cos(theta + deltatheta/2) * deltaB from the x and add math.sin(theta + deltatheta/2) * deltaB to the y.

When I move the robot manually back and forth on the x-axis, the B value works fine, but if I try turning at all, it gets messed up.

Also, if I take out the B value completely from my x and y equations, they work perfectly fine, so I think it must be the B value equations that I have wrong.

Again, I am super new to both coding and Vex robotics, so I apologise if this is not something that I should be asking about on here, but I ran out of other options so I figured I could give it a try.

Thank you to anyone who takes the time to help me with this!

2

I only partially understand this as well, what is deltatheta? Also, shouldn’t the offset from the point of turning be part of your code?

3

deltatheta is the change in the heading of the robot since the last run through of the code (the code runs every 10 msec). What do you mean by the offset from the point of turning? The TB value is the offset of the back encoder to the center point of the robot if that is what you mean.

4

Though this is not coding, I would recommend you consider using an inertial sensor and 2 odom pods. You could save a lot of room and a rotation sensor for your lift. However, I do realize 3 pods is a bit more accurate, though 2 and inertial works fairly well for most teams.

5

Yes, that is what I meant.

Honestly, I feel that I’m not much help, as I don’t entirely understand the math. Why is it necessary to use sine? Can’t you calculate how much the back wheel should move (divide deltatheta by 360, then multiply by 2 times pi times TB) and then use how much more it moved than expected to figure out translation?

I read the article but am confused by the math, as a lot of it seems overcomplicated.

6

Oh, so @nautilus_coder is not using the inertial! That makes a lot more sense.

7

If I used two encoder pods what configuration would they be in? I am very new to odometry so I am more than happy to explore all angles. Do most teams find more success using an inertial sensor or does it lead to more slop?

8

Yes you are correct; however, the back encoder and deltatheta are already in radians so I just have to take deltatheta times TB and subtract deltaB from it and then add that difference to the x. I just tested it and that seems to make it work, thank you!

I was making it way more complicated then it needed to be.

9

In a 2 pod setup, you basically use the Purdue setup except the pods on the left and right become one pod in the middle. The back wheel basically stays the same.

An inertial sensor simply saves more room. In a three odom setup, you use 2 pods on either side to measure the angle of the robot, and the center pod is for drift. In a 2 pod setup, one pod is for tracking distance and the other for drift. The inertial sensor is for heading. You’d probably want to do a bit of research on this. However, I do believe that the inertial sensor has a tiny bit more slop.

10

Alright, thank you. I will look into that.