Plotting Location w/ Accellerometer Project

[Aaron.Graeve]

Originally Posted by Invictus3593

Haha, he gave the ac = (Vt2)/r equation to use in the case that we were turning, which would throw off our real location; I guarantee you I don't drive in circles! If we updated the rotational acceleration every 10ms and took the average acceleration for that period, do you think would this be a short enough interval to be able to plot location semi-accurately? ...

I suspect 10ms will be a short enough time, but that depends on a few hardware specific circumstances (gyro float and accelerometer responsiveness come to mind). Your team's driving style may also play a role in customizing the algorithm. I am interested to see how this will turn out. Also, have you considered encoders on your drivetrain? I hazard a guess that 2 encoders and a gyro can produce a position close enough for your needs.

[Invictus3593]

Originally Posted by Aaron.Graeve

I suspect 10ms will be a short enough time, but that depends on a few hardware specific circumstances (gyro float and accelerometer responsiveness come to mind). Your team's driving style may also play a role in customizing the algorithm. I am interested to see how this will turn out. Also, have you considered encoders on your drivetrain? I hazard a guess that 2 encoders and a gyro can produce a position close enough for your needs.

I was thinking the same thing, if the accelerometer proves to be unreliable (which is what it's looking to be), encoders + a definition of how wide the wheels are can give an accurate representation of how far the robot has moved, theoretically, and the gyro can give orientation.

[Greg McKaskle]

I was looking for a decent app on the iPhone that would work to experiment with. The closest I can come to is one called Vibration. I was using it to measure how the cell phone buzzed and compare that to an external accelerometer reading.

Anyway, the app will show the three axes and it calibrates to subtract out gravity at the initial orientation. If you leave the phone sitting still and run a five second recording, you should get relatively flat lines and that's expected. The integrated area should be zero.

If you run the app and move the phone to the left and right, you'll see similar cancellation. But it probably won't quite zero. Next, during a sample recording, walk from your chair to the front door. Each step looks like a heartbeat, on each axis. And yeah, they sort of cancel out, but where is my predictor of my acceleration that tells me how far I walked. It is a tiny bump at the beginning of that heartbeat signal.

Then run a sample and simply tilt the device a bit. You'll see that a five or ten degree tilt offsets the line quite a bit. And worse, it stays there for the entire sample. The integration of the tilt is huge.

Anyway, if you can find the app, or something similar, it is helpful in understanding why IMUs are hard. After all, if it was easy, the phone or Garmin would do this instead of or in addition to GPS.

Greg McKaskle

[Invictus3593]

Originally Posted by Greg McKaskle

I was looking for a decent app on the iPhone that would work to experiment with. The closest I can come to is one called Vibration. I was using it to measure how the cell phone buzzed and compare that to an external accelerometer reading.

Anyway, the app will show the three axes and it calibrates to subtract out gravity at the initial orientation. If you leave the phone sitting still and run a five second recording, you should get relatively flat lines and that's expected. The integrated area should be zero.

If you run the app and move the phone to the left and right, you'll see similar cancellation. But it probably won't quite zero. Next, during a sample recording, walk from your chair to the front door. Each step looks like a heartbeat, on each axis. And yeah, they sort of cancel out, but where is my predictor of my acceleration that tells me how far I walked. It is a tiny bump at the beginning of that heartbeat signal.

Then run a sample and simply tilt the device a bit. You'll see that a five or ten degree tilt offsets the line quite a bit. And worse, it stays there for the entire sample. The integration of the tilt is huge.

Anyway, if you can find the app, or something similar, it is helpful in understanding why IMUs are hard. After all, if it was easy, the phone or Garmin would do this instead of or in addition to GPS.

Greg McKaskle

Dang, I just tried it out. So i guess the accelerometer route is a dead end.

What do you think of the encoder idea? I mean, you don't have to worry about gravity or forces or anything with them, just rotations of the wheels.

[Ether]

Originally Posted by Invictus3593

Dang, I just tried it out. So i guess the accelerometer route is a dead end.

What do you think of the encoder idea? I mean, you don't have to worry about gravity or forces or anything with them, just rotations of the wheels.

If you're using a properly-programmed true swerve drive*, you can compute position and orientation of the vehicle from the encoders on the wheels. But this introduces a different set of errors due to the dynamic response of the steering and wheel speeds in response to rapid changes in command. And all it takes to throw the computation off is one good bump that changes the orientation of the vehicle.

If you're using a skid-steer drivetrain, the relationship between the powered-wheel encoder readings and the actual vehicle movement during turns gets muddied considerably in ways that may not be easily predictable. Probably not a good solution.


*ie independent steering and drive for each wheel, with properly programmed steering angle and wheel speed for each wheel.

[Mike Bortfeldt]

While not accelerometer related, there have been a number of posts over the years describing issues with the "drift" associated with gyros over time and the error this causes when calculating field position. One method I've experimented with that seems to work well to compensate/eliminate most of this error utilizes two gyros. A high rate gyro for most turns (250 to 500 deg/sec), and a low rate gyro (30 deg/sec) for higher accuracy in slow curves and determining when the robot is stationary (for zero compensation). With the higher resolution of the low rate gyro, it is much easier to determine when you can automatically adjust the zero point. This method does break down when the robot is in continuous motion, but typically there are periods of time within a match (and certainly before the match starts), where the gyro can update its zero point. During bench testing, I was able to achieve a heading drift of under 2 degrees per hour when stationary. The heading calculation algorithm would automatically switch between the gyros at a 20 deg/sec rate (67% of full scale of the low rate gyro).

Mike

[Invictus3593]

Originally Posted by Ether

If you're using a properly-programmed true swerve drive*, you can compute position and orientation of the vehicle from the encoders on the wheels. But this introduces a different set of errors due to the dynamic response of the steering and wheel speeds in response to rapid changes in command. And all it takes to throw the computation off is one good bump that changes the orientation of the vehicle.

If you're using a skid-steer drivetrain, the relationship between the powered-wheel encoder readings and the actual vehicle movement during turns gets muddied considerably in ways that may not be easily predictable. Probably not a good solution.


*ie independent steering and drive for each wheel, with properly programmed steering angle and wheel speed for each wheel.

What about tank drive? Would it totally throw everything off?

While not accelerometer related, there have been a number of posts over the years describing issues with the "drift" associated with gyros over time and the error this causes when calculating field position. One method I've experimented with that seems to work well to compensate/eliminate most of this error utilizes two gyros. A high rate gyro for most turns (250 to 500 deg/sec), and a low rate gyro (30 deg/sec) for higher accuracy in slow curves and determining when the robot is stationary (for zero compensation). With the higher resolution of the low rate gyro, it is much easier to determine when you can automatically adjust the zero point. This method does break down when the robot is in continuous motion, but typically there are periods of time within a match (and certainly before the match starts), where the gyro can update its zero point. During bench testing, I was able to achieve a heading drift of under 2 degrees per hour when stationary. The heading calculation algorithm would automatically switch between the gyros at a 20 deg/sec rate (67% of full scale of the low rate gyro).

I'm not too familiar with gyros. Do you have any sample code I could take a look at?

[Tom Line]

Originally Posted by Invictus3593

What about tank drive? Would it totally throw everything off?

I'm not too familiar with gyros. Do you have any sample code I could take a look at?

The gyro+encoder routine is one that many teams currently use for autonomous. However, over time the errors due to wheel slip, collisions, and gyro drift make it inaccurate enough that you can't really depend on it through the match.

Polar coordinates lend themselves to this use (angle + distance).

[faust1706]

Originally Posted by Tom Line

The gyro+encoder routine is one that many teams currently use for autonomous. However, over time the errors due to wheel slip, collisions, and gyro drift make it inaccurate enough that you can't really depend on it through the match.

Polar coordinates lend themselves to this use (angle + distance).

We have a constant problem with it climbing, as has been previously said in this tread. To account for the, we had a driver control of a gyro reset. While doing that would defeat the whole project idea, you could use your last calculated point as your new origin and go from there, no?

[Chris Hibner]

Originally Posted by Tom Line

The gyro+encoder routine is one that many teams currently use for autonomous. However, over time the errors due to wheel slip, collisions, and gyro drift make it inaccurate enough that you can't really depend on it through the match.

Originally Posted by faust1706

We have a constant problem with it climbing, as has been previously said in this tread. To account for the, we had a driver control of a gyro reset. While doing that would defeat the whole project idea, you could use your last calculated point as your new origin and go from there, no?

In past years when we needed high accuracy during turns and/or expect collisions or other sources of wheel slip or orientation change, we put the encoders on non-driven follower wheels. We put the wheels in line with the drive wheel, usually on a swing-arm and spring loaded them to keep in contact with the floor. The VEX omni wheels work great for this. In fact, doing it this way allowed us to remove the gyro, which was nice.

[Invictus3593]

Originally Posted by Chris Hibner

...we put the encoders on non-driven follower wheels. We put the wheels in line with the drive wheel, usually on a swing-arm and spring loaded them to keep in contact with the floor. The VEX omni wheels work great for this. In fact, doing it this way allowed us to remove the gyro, which was nice.

From what everyone is saying about Gyros (the slipping and such), it sounds like this method of plotting position would be the most accurate

The next challenge would be plotting the position on a sort of mini-map on the driver's screen. How do you guys think one would go about accomplishing this? One would have to be able to map the location in scale to the diagram's width and height, right? Or is there a less CPU-intensive method?

I'd be willing to try and write up a separate program, but it'd be cool to get it on the dashboard, if possible

ps: thank you guys for all your help!

[Aaron.Graeve]

I think the mini-map idea both has merit and is not overly CPU-intensive. I suppose it would be similar to teams that use line overlays in aligning their shooter. If you keep the total x and y components (or r and theta, whichever floats your boat) as variables stored on the robot, it should be a relatively easy task to use those values to add a point image overlay to a stock background map on the dashboard. The overlay would probably not be that taxing, provided you are careful with your implementation.

[Invictus3593]

Originally Posted by Aaron.Graeve

I think the mini-map idea both has merit and is not overly CPU-intensive. I suppose it would be similar to teams that use line overlays in aligning their shooter. If you keep the total x and y components (or r and theta, whichever floats your boat) as variables stored on the robot, it should be a relatively easy task to use those values to add a point image overlay to a stock background map on the dashboard. The overlay would probably not be that taxing, provided you are careful with your implementation.

I just tried to write up a point overlay in the dashboard like you said using the IMAQ Point overlay vi, but I can't seem to get it to actually plot a few points on the image, do you have any examples?

Back in 2008, we did a demo of a robot called Nitro. It had three omni wheels and used the NI Motion planning SW to calculate trajectories. Anyway, for our demo we built a path builder and a path display using the picture control. You could also do this in an XY graph. Those are both pretty performant, especially the XY graph.

Do you have any sample code left?

[Ether]

Originally Posted by Chris Hibner

In past years when we needed high accuracy during turns and/or expect collisions or other sources of wheel slip or orientation change, we put the encoders on non-driven follower wheels. We put the wheels in line with the drive wheel, usually on a swing-arm and spring loaded them to keep in contact with the floor. The VEX omni wheels work great for this. In fact, doing it this way allowed us to remove the gyro, which was nice.

Chris,

You might want to point out that 3 follower wheels are required if the vehicle has strafing capability.

Also, with 2 followers it is important to realize that they cannot discriminate among the three motions illustrated in the attachment (showing three skid-steer vehicles each with a different center of rotation). This can be mitigated by placing the followers so that the midpoint between them is on the center of rotation of the vehicle.

[Greg McKaskle]

Back in 2008, we did a demo of a robot called Nitro. It had three omni wheels and used the NI Motion planning SW to calculate trajectories. Anyway, for our demo we built a path builder and a path display using the picture control. You could also do this in an XY graph. Those are both pretty performant, especially the XY graph.

Greg McKaskle