Measuring the force of a toy car crash

My son came up with the idea of using an arduino in a toy car (like a GI Joe sized car) to monitor the "g-force" of a crash. If the crash is too severe, a red LED lights up indicating the passenger would be dead.

It seemed pretty simple, so I got an accelerometer, taped it to the seat of the car, drove it down a ramp a different points, and monitored the output.

What I am discovering though is that the data I am getting from the accelerometer doesn't vary enough between different points and is shockingly (pun intended) random. I've tried messing with the refresh rate and different values for averaging out the data across multiple readings. I am just not having any luck.

So my question is, is there a different kind of sensor that might work better (a shock sensor maybe?) or maybe some way I can get more consistency and fidelity out of the accelerometer? I am desperate to get this to work as it will be the center piece of our Maker Faire exhibit.

Thank you for any help!

Solid state accelerometers are designed for exactly that purpose and work very well if used properly.

Forum members could probably help, if you would provide some clues about how you are using yours. Post the code properly, with examples of the data output, and a link to the accelerometer module you are using. Hint: read and follow the directions in the "How to use this forum" post.

Rod through a hole with a friction adjust screw and a microswitch.

bluejets:
Rod through a hole with a friction adjust screw and a microswitch.

Only works for crashes where the force is in the direction of the switch. Perpendicular forces, or forces in opposite direction, will not set off the switch.

bluejets:
Rod through a hole with a friction adjust screw and a microswitch.

What units of measurement does it report?

...R

Robin2:
What units of measurement does it report?

It'll report "dead" or "not dead" which is all OP wants. No units needed.

wvmarle:
It'll report "dead" or "not dead" which is all OP wants. No units needed.

I guess I missed that part :slight_smile:

My sister-in-law runs science courses for younger kids. She organized a kids' "crash-test-dummies" project for an exhibition a few years ago using eggs as passengers. IIRC the purpose was to demonstrate the value of seat belts. I was very impressed by how well the kids understood, and could explain the project.

...R

My sister-in-law runs science courses for younger kids. She organized a kids' "crash-test-dummies" project for an exhibition a few years ago using eggs as passengers.

Interestingly if you drop fresh eggs from a first floor window onto grass they will bounce. I have tried this myself and it works.

I think that you need a fast accelerometer with peak hold functionality. If you or the sensor misses the peak force, you can get random values.

Robin2:
My sister-in-law runs science courses for younger kids. She organized a kids' "crash-test-dummies" project for an exhibition a few years ago using eggs as passengers. IIRC the purpose was to demonstrate the value of seat belts.
...R

This is essentially what we hope to do, but without the mess of eggs splattering. Ideally we would have 3 levels we would display via LED (uninjured, inured, dead), but I think at the levels of force we will be using we won't have enough variability.

monitored the output.

How
?

DrDiettrich:
I think that you need a fast accelerometer with peak hold functionality. If you or the sensor misses the peak force, you can get random values.

Thanks. I tried googling for one and am just finding really pricey industrial type ones. Should I head over to the sensors forum to look for more specific help on which sensor is best?

AWOL:
How
?

Watching the serial monitor. I have the code watching for the highest value received by the accelerometer (ADXL335) and it outputs it to the serial port. On each retry I reset the arduino and try again. I have the X-axis aligned with the force, and it shows the most change.

Watching the serial monitor

Simultaneously with data collection?
At what bit rate?

Try writing to a circular buffer and only stopping collection when a peak is detected, then print from the buffer.

wecreatorsthree:
I have the X-axis aligned with the force, and it shows the most change.

With a realistic crash it doesn't work like that. Forces can come in different directions. For your application, it may do just fine.

The problem is that you indeed need some form of peak detection and those peaks will be really short. If you print to Serial you're most likely going to miss the peak.

Best you can probably do is something like:

unsigned int readForce() {
  byte stopButton = 2 // a stop button connected to pin 2
  unsigned int maxForce = 0; // assuming you get an int value returned from the sensor  
  while (digitalRead(stopButton)) {
    force = readSensor();
    if (force > maxForce) maxForce = force;
  }
  return maxForce;
}

You can replace digitalRead() with a more direct register read; that's even faster. readSensor should be a very fast sensor that returns a number indicating the force. Also your sensor should be able to return these values very fast (microsecond scale). This way you can take as many readings as possible until someone presses this stop button, after which you have it print out the value to Serial or an LCD or whatever.
Add a start button that calls this function and enters the never ending loop; the stop button breaks out of it.

Try writing to a circular buffer and only stopping collection when a peak is detected, then print from the buffer.

If you print to Serial you're most likely going to miss the peak

Thank you so much for your replies, I hadn't considered that trying to output the data at the same time as collecting the data could cause me to miss the short spike. I do have peak detection in my code, but it writes that peak to serial at every loop. I'll try adding a button tonight and only have it output the data when I push the button.

With a realistic crash it doesn't work like that. Forces can come in different directions. For your application, it may do just fine.

I was considering adding up the increase across all three axes for a force total and then use that as my measurement for deciding if the passenger would survive, that's of course if I can get more reliable data.

One thing that is giving my brain fits is that depending on which way the accelerometer is tilted, the numbers can go up or down from the base. So I am wondering if I need to measure difference +- the base rather than just looking for peak.

I hadn't considered that trying to output the data at the same time as collecting the data could cause me to miss the short spike.

That would have been instantly obvious to us, if you had posted the code as requested.

The big problem with all those calculations is that it's more and more likely you miss the very short peak. Whether you can even accurately measure the peak also depends on the sampling rate of your accelerometer: the exact same crash can produce very different data because of that.

jremington:
That would have been instantly obvious to us, if you had posted the code as requested.

Sorry, I didn't get a chance to read the replies until I was already at work and do not have access to the code. I will more than happily post the code as soon as I get home. I appreciate everyone taking time to help me.

I wanted to thank everyone who replied.

I had a realization that I was looking at this completely backwards.

I was expecting the values from the accelerometer to go UP and the larger the impact the higher the value.

But, the impact was actually a negative G, so I needed to look at numbers to the left of 0G. I started watching for the lowest value instead of the highest values and I saw a way more varied data set. My sensor reported 0G as around ~420, my highs were ranging from 480 to 510. My lows were ranging from 10 to 300.

I thought I had it all figured out, that the lower the number meant higher the impact. I put that to the test with a bunch of tests impacts and discovered that was wrong as well. It turns out I had to almost see the ranges as 0 to 400 for negative G impacts and 400+ for positive acceleration (accelerating down a ramp).

The lower the impact, the lower the values on the left size of 0G. I got it to a point where sending car down a ramp into a wall gave me really regular readings of around 250. Then if I put something in the way to slow down that impact, I'd get a reading of 100 to 200 (a floppy cardboard box for example). Then, if I put a pillow in front of the wall, I'd get usually well below 100 (as low as 12).

So, I now have reliable ranges that I can use for my 3 LEDs (green = safe, yellow = danger, red = dead). I am only monitoring one axis (x) since it saw the most reliable changes as I have it set inline with the impact. I know in the real world I would need to take the changes across all 3 axis at the same time, but that is beyond what I have time for right now.

I am just happy to say that we are still on target to have this built for the Maker Faire.

Thanks again.