I’ve tried optimizing speed and running the position tracking task faster but it doesn’t seem to be making it more accurate.
I’m generating a pretty big error(around 10%) mainly when travelling in arcs/ turning while moving and I’m wondering what is going wrong, or if it’s just the low accuracy of the vex encoders.
How precise is your measurement of the distance between the forward encoders?
very, I spent a long time tuning it to about 4 decimal places
Old encoders shouldn’t be off that much if tuned correctly. There are 3 reasons why it might be broken-
Your trackers may not be tuned well enough. You should be able to spin the robot several times with the rotation accurate after each revolution. You should also be able to drive the robot in a straight line with the distance accurate over several feet.
Your trackers may not be straight. Ensure that the tracking wheels are perfectly parallel both to the chassis and to each other.
what’s your loop delay time?
I changed my loop time from 5 ms to 2 ms
That may be the issue then. Encoder returns an integer as it is a digital sensor, meaning that the value is discrete and any decimal will be wiped. At some point the loop delay time will be too small that the decimals wiped becomes significant. For example, if you travel around 1.5 ticks every loop, it will get wiped into 1 ticks, meaning you have instantly lost 33% of distance u travelled. If the error continues 500 times per second, error will become very significant.
Even though lowering a loop time increases the accuracy due to having a better approximation, if it is too low, error from discretization will become too significant. Try playing around with loop delay time and see what works. Better yet, change your encoder to the new rotation sensor, which has 4096 ticks instead of 360. This means that even if you are losing accuracy due to low loop delay, you’ll only lose at most 0.088 degrees instead of 1 degrees, which is probably insignificant enough to cause any issues (0.088 deg on 2.75” tracking wheel is 0.002”)
I think that would make my program think the position is further than it actually is, but I have the opposite problem and im undershooting the distance. However, I did not know that the new rotation sensors has such a high accuracy. I should probably put a priority on getting it.
programs always round decimals down, meaning the read values will always be lower than the actual value, causing an undershoot
this shouldnt be a huge issue if you arent calling reset() on every loop
Either way having only a 2ms or 5ms wait is way too low for vex sensors. I don’t have the actual rate off the top of my head, but I don’t think any sensors are able to send new values less than every 10ms. Im not sure why this would cause you to have such a large error, but you are in the very least wasting processing power if not making your odometry less effective by having such a small refresh time.
we are also trying to tune the odometry for accuracy - how do you measure the distance between the tracking wheels - is it
the distance between the outside edges or
the distance between the wheel centers?
the distance between the inside edges or
|---------------1-------------|
| -----------2----------|
|---------3-------|
# # # #
# # # #Distance between wheel centers and then tune from there.
One tuning technique I have heard is the box method
Drive slowly in a square making 90 degree turns and driving as straight as possible.
This is straightforward test that you can use to tune your odom. Following the circumference of a circle is also another option, but more complicated.
I believe you should look into motion profiling as the large amount of competitive teams use it, as its goal is for the sake of reducing drift when applied to drivetrains.
He’s talking about odometry being off which unless he’s using only 2 tracking wheels then drifting doesnt matter.
I completely disagree. Looking back at team 365X during Turning point season, they used motion profiling to get extreme precision without the need for tracking wheels (they used internal encoders of the motors). From motion profiling they were able to win Worlds Skills during Turning Point. They were able to accomplish it with motion profiling which allows the motors to naturally flow from point A to B. Even with 3, 4, 5 tracking wheels I highly doubt you can get good precision as there will be drift from the wheel’s momentum. Secondly, there is a reason why PROS pathfinding includes odometry and motion profiling. Odometry itself is relatively robust in an ideal world but it will fail in the real world if it does not consider momentum one way or another, regardless of how many tracking wheels. If the robot keeps whipping the wheels from 0 to 100 the odometry’s accuracy will surely decrease, due to wheel skid, regardless of the external sensors you add. There is a reason why team 5225A not only uses odometry with 3 encoders, but also motion profiling as well. That is also why 5225’s autonomous’s are extremely consistent every year.
PID would do the same thing as motion profiling right? Looking at some other forums it’s looks like motion profiling and PID are pretty similar. Also either way if your making the drive move movement smoother one way or the other it should be fine.
If the issue is only when you accelerate quickly then this would be the issue but either way you want to slow down as you get to your target so you don’t have overshoot.
In addition to this, iirc last year 7k used motion profiling for their paths and then handed control to a PID controller for slowing down. This massively reduced drift in the odometry while also allowing them to have incredibly precise positioning.