2
\$\begingroup\$

We are creating a ball that changes colour depending on its speed when it rolls.

I have a 3 axis accelerometer sensor.

This is the code we are using at the moment:

int xAxis = A3;
int yAxis = A1;
int zAxis = A2;
int axisValue = 0;

int led = 13;
int led2 = 12;
int led3 = 11;

void setup() {
  Serial.begin(38400);
  Serial.println("Starting up");

  pinMode(led, OUTPUT);     
  pinMode(led2, OUTPUT);     
  pinMode(led3, OUTPUT); 
}

void loop() {
  axisValue = analogRead(xAxis);    
  Serial.print("X="); Serial.print(axisValue);

  axisValue = analogRead(yAxis);    
  Serial.print(",Y="); Serial.print(axisValue);

  axisValue = analogRead(zAxis);    
  Serial.print(",Z="); Serial.println(axisValue);

  if (axisValue > 300 ) {
    digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
    digitalWrite(led2, LOW);   // turn the LED on (HIGH is the voltage level)
    digitalWrite(led3, LOW);   // turn the LED on (HIGH is the voltage level)
    Serial.println("more than 300");
  } 
  else if  (axisValue < 300 ) {
    digitalWrite(led, LOW);     // turn the LED on (HIGH is the voltage level)
    digitalWrite(led2, HIGH);   // turn the LED on (HIGH is the voltage level)
    digitalWrite(led3, HIGH);   // turn the LED on (HIGH is the voltage level)
    Serial.println("less than 300");
  }
 // delay(200);                 
}

So I have some LEDs that turn on and off. But I want to change the light according to speed not only to position. How can I do that?

\$\endgroup\$
  • \$\begingroup\$ You have to compare the change in position instead of actual position. But are sure that accelometer output will give the position of sensor? \$\endgroup\$ – nidhin May 30 '14 at 1:32
  • \$\begingroup\$ You'd be better off measuring the time it takes for adjacent optical sensors to become occluded and dividing their respective distance by that. The method you propose and the naive method in which you've implemented it makes it unlikely to work. \$\endgroup\$ – Samuel May 30 '14 at 1:53
  • \$\begingroup\$ What is the program running on? \$\endgroup\$ – Scott Seidman May 30 '14 at 2:49
  • \$\begingroup\$ The most accurate method would be to integrate a direction cosine matrix (DCM) \$\endgroup\$ – hassan789 May 30 '14 at 3:28
1
\$\begingroup\$

An accelerometer measures acceleration, not speed. In order to get speed, you will have to integrate the acceleration data over time. Since this is in the discrete domain (you can only sample the acceleration a finite number of times per second) it is more of an approximation and can be related by the following formula where A = acceleration, V= Velocity, T = Sampling period.

V[k+1] = V[k] + T*A[k]

So every time the acceleration is sampled, you would need to evaluate this formula, then make V(k) = V(K+1). This is essentially integration.

Also keep in mind that the acceleration data the sensor reads includes the force due to gravity, this is usually accounted for by subtracting 9.8m/s from the z axis readings, however in your case, since the accelerometer is spinning, the effect of gravity would likely (hopefully) cancel itself out by being applied equally on all axis.

Usually accelerometers need to be oriented precisely to avoid huge errors. For instance an angle error of just 1 degree would cause the velocity to be off by 1.7m/s after 10 seconds. For applications where the orientation is not fixed, a gyroscope is usually used in conjunction with the accelerometer to account for the actual orientation of each axis. Since the accelerometer will be spinning rapidly in your case, I cannot quite say for sure how it will behave. Since you only need relative velocities, it may work consistently enough for your needs, or it might not work at all, I can't say. Even with properly orientated accelerometers, calculating velocity produces significant errors since each small error in the acceleration is going to be added together over time. In my experience this error could be around 3 m/s after 10 seconds or more. Its worth a shot though, good luck!

\$\endgroup\$
  • \$\begingroup\$ The gravity vector would only cancel if the accelerometer sampling period was exactly an integer multiple of half of a single rotation of the ball. Then only if it's rolling on perfectly on a single axis. In other words, yeah, that's not going to happen. \$\endgroup\$ – Samuel May 30 '14 at 1:59
  • \$\begingroup\$ Actually, in this case the direction of the gravity vector is most closely reflective of the angular position \$\endgroup\$ – Scott Seidman May 30 '14 at 2:51
  • \$\begingroup\$ Are you sure Samuel? At first I thought it wouldn't cancel out, but I thought about it for a while and I think - assuming the sampling rate is fast enough that it must cancel out. Just picture a vector rotating along a single point in any 2D plane in 3D space. The sum (or integral) of that vector will be zero. \$\endgroup\$ – THEMuffinMan7 May 30 '14 at 4:49
  • \$\begingroup\$ @THEMuffinMan7 Given a non-integer multiple sampling period of the rotational period, it will cancel given infinite time. Any real situation though, will not get close. Think of this as shot noise like that from sampling coin flips, except the number of states depends on the ratio between the sampling period and the rotational period... in three dimensions. \$\endgroup\$ – Samuel May 31 '14 at 1:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.