Project: Burt - Assembly #2 Sensors

Onto my second video showing the next assembly step.
(Head to 1:25 in the video to skip to the breadboard layout)

I've assembled and added a ProtoShield, partially using atomicsalad's guide here. NOTE: The usual way to assemble this shield, is to have the female to male connectors aligned with the others in the Arduino stack. I have changed this so that they line up next to the breakboard, and used male headers to connect to the Duemilanove. The height of this shield, with a breadboard and breakout boards, ensures that this will be at the top of the Arduino stack. Which won't be a problem, getting too high will shift the centre of balance.

The breakboard nicely fits the Pololu Power Switch LV and Digital Dimensions accelerometer breakout boards.

The power switch was bought out of impulse. I only noticed during assembly that it is the LV version, Doh! It's too soon to work out the power consumption for the Arduino and sensors. So right now it's just there for testing. If the digital side of Burt can handle the 4x AAA 1.5V batteries, then I could use the switch (to power on the stack, and digitally power off the stack).

After years of practice and a lot of patience, my Google'ing turned up a fantastic practical discussion of accelerometers by Starlino.com - "Accelerometers reviewed and tested. Part 1: DE-ACCM2G (ADXL322), LIS244AL, Pololu MMA7260QT".

I bought the DE-ACCM2G board a few years back. Digital Dimensions have updated that product to a newer MEMS part since then. But thankfully for me I have the ADXL322 chip on my DE-ACCM2G board which fits in with Starlino's testing.

For those that wish to dig further into the depths of MEMS response and filter issues, Starlino has a follow up post entitled "Accelerometer benchmarks. Part 2: LIS331AL and DE-ACCM2G (ADXL322). Filters, amplifiers and vibration response".

I've uploaded Work-In-Progress (WIP) PDE code that grabs data back from the ADXL322. (See Note 1 below for SVN version numbering)

Seeing how stable the data is, backed up with Starlino's analysis, was wonderful to see. After working on a few Nintendo Wii game contracts, I was familiar with analysing the ADXL322 feedback from the WiiMote. But comparing what I remember about the WiiMote data and the buffered data it certainly is poles apart. So much cleaner. It also will save valuable cycle time not having to implement software filtering for this signal line, Result! I can now just play with thresholding the values to deduce what the chassis thinks it's doing, in relation to what the motor controller thinks :)

Next up is the testing of the IR sensor. The Sharp IR sensor is hooked up to Analog pin 2 (Vo), Ground (Gnd), and 5V (Vcc) lines. More WIP PDE code (Note2) (and more here) (Note3) has been uploaded that tests the analog reading and converts it to an approximated distance value. The distance conversion function is described in this Oomlout.com PDF guide. Initial testing shows the sensor sending back sensible values. Further testing is required with the IR sensor data. I'm curious to see how software filtering compares to passive filtering. Theirs certainly spare breadboard lines that could be used for it.

Right, time to look at hooking up the motor controller...

Notes:
1 - SVN version r35 (at the time of writing)
2 - SVN version r38
3 - SVN version r40