Robot Position Tracking

Once again, Aftershock is working hard to make videos and explanations of what we are doing, especially early in the year. We hope to share as much as possible with as many teams as possible (mainly on our YouTube channel), so don’t forget to subscribe if you haven’t already!

Here is a video that gives a brief explanation and demonstration of our robot position tracking code:

When we have developed the code more, we may release it. Depends on the level of interest and engagement on this video and others.

Thanks for reading!
Luke Rohler
Team Coach
323Z Aftershock

1 Like

I sent you a PM

Awesome! Yeah I have been working on some similar code, but I find it drifts WAY to much. Despite my various attempts at compensating for this drift I have yet to find a solution that works really well. Anyway, are you using any GYROs or Accelerometers? How are you compensating for drift? Will your measurements be thrown way off if your hit by another robot? :stuck_out_tongue:

P.S. would love to see that code, even if its not finished…

do you use basic trig with straight lines, or do you some how integrate the robots movement along an arc, I messed around with this, but couldn’t get it to work

I don’t think that tote bag is legal for competition;)

Is there any reason you chose to use 3.25" wheels?
I don’t think I’ll be using position tracking on my robot.

Currently it assumes that all movement is made up of many tiny straight lines. We will be using several gyros on our final robot (design hint). As of now, only 1.

Our mechanical sensor setup is based off of actual movement rather than intended movement, so it will track as we are shoved.

We have an accelerometer (not on the robot), but from what we have been told, the vex accelerometer is not nearly accurate enough to track precise movement across the field.

It should be legal as a nonfunctional decoration :wink:

We chose 3.25" wheels because they gave us the motor rotation to inches of movement ratio that we wanted.

What do you mean by actual movement? say you are shoved in the side where none of your motors are moving (unless your using an H drive?). Your measurement will then be off because your motors couldn’t move and you will be in a different position when resuming your measurements. Therefore your measurements will be off, right?

I too have heard this, a few days ago I found an accelerometer in the deep dark depths of my teams supplies and I am interested to see just how inaccurate it really is. I also want to look at implementing a kalman filter as well as some high and low pass filters to see if that will help in any significant way. :stuck_out_tongue:


Our sensor setup is independent of our drive setup, which allows for mechanical errors such as slippage, getting shoved, etc. I am fascinated by the concept of a kalman filter, but I have no idea how to implement one as of now. Guess that’s what Google and Wikipedia are for :smiley:

The main idea of kalman filtering is really just a weighted average. The trick is that you change the weighting of each sensor(how much you trust each one) based off of how accurate the sensor was during the last cycle. This means that inherently the sum of the sensors is always better than either individually. If one sensor is just utter trash and the other is really good the filter will naturally trust the good sensor a lot more but still use the trash data to get something better than just the good sensor alone.

Several Gyros with a lot of drift each could be interesting to apply a Kalman filter on.

If you want to see examples of applying this concept in ROBOTC you can take a peak at BNS lib.

That helps to understand it a bit better. I found a graduate thesis on Kalman filters that is quite good, so I am working my way through that as well.

We have not had any experiences with gyro drift (at least when they properly clear before auton). Is there still an application for a Kalman filter if there aren’t drift issues?

I Toyed with the using multiple gyros for position tracking last year, the problem is when you have 1 gyro at 359 degrees and on at 1 degrees, then you average to somewhere near 180, when you want it to be at 360, and I never thought of a way around it

I have never programmed multiple gyros but I think that you could have an if statement that says “if gyro1>350 && gyro2<10 then gyro2 += 360” so that 360 and 1 would average out at 360.5. Then you can say “if angle>360 then angle -= 360” to get 0.5.

also how do you handle swing turns, for example, how does the code handle if one side of the drive is moving while the other is not

Have a look at the old gyro library I released a few years back. One feature was tracking the absolute value of the gyro, it would continue to accumulate an angle once you passed 360 deg. So in your example one gyro may be at 359 degrees while the other would be at 361 degrees, the average would be 360.

Oh, that makes a lot of sense :smiley: So your using an independent sensor setup. Thats actually a really good idea :rolleyes:… Finally you have spilt your secrets :stuck_out_tongue: