Programming Questions

[magical_hands]

1. The accelerometer gives the acceleration in “milligs” anyone knows how they are deriving this acceleration equation plus what is “milligs” because i know that acceleration is measure in m/s^2 but haven’t heard of “milligs”.

2. Also, Anyone knows how can i get distance from the milligs unit?

3. Also, if i want to fuse Kevin’s 2006 accelerometer code, 2006 gyro code, and and the CAM code how would i do it?

4. Any one knows how to wire the photoswitch sensors all i see is 2 wires sticking out of the sensor how would i connect it to RC? and where Digital or Analog?

[SoftwareBug2.0]

@magical hands

1. The accelerometer gives the acceleration in “milligs” anyone knows how they are deriving this acceleration equation plus what is “milligs” because i know that acceleration is measure in m/s^2 but haven’t heard of “milligs”.

I would assume that “milligs” is thousandths of the force of gravity.

[Goldeye]

@magical hands

1. The accelerometer gives the acceleration in “milligs” anyone knows how they are deriving this acceleration equation plus what is “milligs” because i know that acceleration is measure in m/s^2 but haven’t heard of “milligs”.

2. Also, Anyone knows how can i get distance from the milligs unit?

3. Also, if i want to fuse Kevin’s 2006 accelerometer code, 2006 gyro code, and and the CAM code how would i do it?

4. Any one knows how to wire the photoswitch sensors all i see is 2 wires sticking out of the sensor how would i connect it to RC? and where Digital or Analog?

1. A g, the acceleration due to gravity is about 9.80665 m/s^2. A millig is one thousandth of that, or 0.00981 m/s^2.

2. You need to integrate twice. Basically, that looks like this.

int velocity;
int position;

int accel = /*Get the acceleration from the accelerometers */
velocity += accel * TIME; /*TIME is how frequently the timer you are running the interrupt on is called.  If you're alternating the gyro and accelerometers, this'll be timer time / # of things you're checking. */
position += velocity * TIME; /*With the gyro, you may actually need to be doing some trig to do this the way you want */

3. You need to fiddle with stuff in adc.h (taken from the gyro code). The challenge is all about figuring out what, exactly. I don’t remember exactly what’s in there, but ask more here if you have trouble.

4. There’s two parts. One’s a receiver, one’s the source. What we did was have them share power and ground, and you only need to use one of the two signal wires on the receiver. However, there’s some weird thing that needs to be done to it to send 5v (It sends 0.01 if you just solder it.) I wasn’t involved in that though. I’ll try to find out for you.

[CoolerQ]

@magical hands

3. Also, if i want to fuse Kevin’s 2006 accelerometer code, 2006 gyro code, and and the CAM code how would i do it?

Where are you getting the 2006 accelerometer code? I don’t see anything on kevin.org…

Thanks,
–Quentin

[Chriszuma]

I would advise against using the accelerometer for computing distance. You have to double-integrate it, which will greatly amplify any inaccuracies of the data. You’re better off using the gear tooth sensors, since you can hook them up to your drive train and get a direct computation of distance.

[CoolerQ]

@Chriszuma

I would advise against using the accelerometer for computing distance. You have to double-integrate it, which will greatly amplify any inaccuracies of the data. You’re better off using the gear tooth sensors, since you can hook them up to your drive train and get a direct computation of distance.

The only problem with that is that you don’t get a direct computation of traveled distance, you get a direct computation of wheel distance. If the wheels slip, which they’re likely to do if you’re driving at a high speed, the distance recorded by the gear tooth sensor could be wildly off. The accelerometer allows you to measure motion of the robot relative to the ground instead of the robot’s wheels relative to the robot’s body.

–Quentin

[Chriszuma]

@CoolerQ

The only problem with that is that you don’t get a direct computation of traveled distance, you get a direct computation of wheel distance. If the wheels slip, which they’re likely to do if you’re driving at a high speed, the distance recorded by the gear tooth sensor could be wildly off. The accelerometer allows you to measure motion of the robot relative to the ground instead of the robot’s wheels relative to the robot’s body.

–Quentin

This is a good point. Suppose you were to add two non-powered casters that simply contacted the gound orthogonally in the center of the robot (much like an old ball mouse but without the ball), and put gear tooth sensors on each of them. Then you could sense sideways slip too.

(it’s just an idea)

[Chris_Hibner]

@Chriszuma

I would advise against using the accelerometer for computing distance. You have to double-integrate it, which will greatly amplify any inaccuracies of the data. You’re better off using the gear tooth sensors, since you can hook them up to your drive train and get a direct computation of distance.

This is a good point - double integration of the accelerometer will not be very accurate after a very short time. It can be made to work, but it is a lot more complicated than you might think at first. Angular rate sensors are nice since any rigid body has the same angular rate at every point on that body. That is not true with acceleration: you can integrate some strange positions due to centrifugal accelerations while turning, unless you know how to compensate for that.

In the past, we’ve always measured distance using an encoder connected to a non-powered wheel in the center of the robot. If you do not have crab steering, a single wheel along the centerline (left-right centerline, that is) should provide enough accuracy for you to do what you want.

Ideally, the wheel should be located at the turning center of your robot, but if it is a little forward or backward from that point, you will be okay. The most important thing is that it is centered side-to-side; otherwise you will think you’re moving when you’re turning in place.

[Tom_Bottiglieri]

@CoolerQ

The only problem with that is that you don’t get a direct computation of traveled distance, you get a direct computation of wheel distance. If the wheels slip, which they’re likely to do if you’re driving at a high speed, the distance recorded by the gear tooth sensor could be wildly off. The accelerometer allows you to measure motion of the robot relative to the ground instead of the robot’s wheels relative to the robot’s body.

–Quentin

We’ve been playing with accelerometers for measuring linear position for a while now, to no avail. We’ve tried recalulating bias more often, calculating bias for longer, mounting the chip to solid block, mounting it to foam rubber to dampen vibration… but as of yet nothing we’ve done has yielded anything but erratic readings.

I think we’ll stick to encoders.

[6600gt]

@Tom Bottiglieri

We’ve been playing with accelerometers for measuring linear position for a while now, to no avail. We’ve tried recalulating bias more often, calculating bias for longer, mounting the chip to solid block, mounting it to foam rubber to dampen vibration… but as of yet nothing we’ve done has yielded anything but erratic readings.

I think we’ll stick to encoders.

When ever you read a accelerometer it give you the acceleration at that point in time. If you track it it every 1ms and basesed on the change between this point and the last calculated the difference and calculated the velocity by calculating the area under the curve and doing the same to calculated the distance traveled in that 1ms, I think it will work. In the end everything gets split down into vectors between the x and the y axis of the accelerometer.

[6600gt]

@Tom Bottiglieri

We’ve been playing with accelerometers for measuring linear position for a while now, to no avail. We’ve tried recalulating bias more often, calculating bias for longer, mounting the chip to solid block, mounting it to foam rubber to dampen vibration… but as of yet nothing we’ve done has yielded anything but erratic readings.

I think we’ll stick to encoders.

When ever you read a accelerometer it give you the acceleration at that point in time. If you track it it every 1ms and basesed on the change between this point and the last calculated the difference and calculated the velocity by calculating the area under the curve and doing the same to calculated the distance traveled in that 1ms, I think it will work. In the end everything gets split down into vectors between the x and the y axis of the accelerometer.

[magical_hands]

Can anyone explain me in simple words what integrate accelerometer means and how it actually works? and how can i integrate my accelerometer?

Also, the photoswitch sensors are pretty kewl this year. However, its bit challenging to get it working! As soon as i get it working i will post code and diagrams

[FlyingDutchman]

ya this has nothing to do with the subject but I need help trying to post or what ever it is that you have to do to put a question on the website… thanks

[SoftwareBug2.0]

@magical hands

Can anyone explain me in simple words what integrate accelerometer means and how it actually works? and how can i integrate my accelerometer?

In this context, integration refers to the mathematical function which is the opposite of differentiation. Differentiation is finding the slope of something, and integration is basically finding the area underneath a curve.

You will be using something called Riemann sums to integrate. Someone on your team who has taken calculus should be able to tell you more about the theory of it if you want to know more.

For what you’re doing, it boils down to doing:

(velocity)+=(acceleration)(time since last reading)
(distance)+=(velocity)(time since last reading)

Think of it this way: If you’re moving 60mph in a car, and you drive for 1/2 hour, you’ll go 30 miles. Likewise, if you’re accelerating at 2 ft./sec for 10 seconds, then you’re moving at a rate of 20 ft./sec.

[magical_hands]

Thanks for the explanation now i get it!