Week 10: Exploring Sensor Ideas

Now that I have the groundwork for NXT-Arduino comms up and running, I've begun throwing around various ideas for custom sensors to implement. I've been throwing most of these ideas around in my head, and I'm going to very briefly identify the ones I feel are most viable, and jot down a few spurious ideas about each.

IR Receiver - This is a relatively simple idea and should be comparatively easy to implement. Attach an IR photodiode to the Arduino and run some processing on the signal. Then package the data for transmission to the NXT.

• Perform IR code processing through custom solution or pre-existing IR library
• Need to keep data processing asynchronous, will have to store results until NXT polls
• Needs some form of queuing structure, can infinitely expand (within memory limits)
• Sensor is useful for remote control of the bot, and IR remotes are everywhere
• Need to determine if code recognition is done on the Arduino or NXT side

6 DOF Gyro/Accelerometer - Slightly more complex, I have a SparkFun module laying around that could be interfaced with the Arduino. Several possibilities here for practical use, and can also more clearly demonstrate the concept of register bank for multiple sensor values.

• Possible problem with the A4/A5 analog pins on the Arduino being the only hardware I2C lines available. It should be possible to attach the the module and extend the bus on a particular sensor line, but I really want to keep separation between the NXT and sensors discrete. Software-side bitbanging of the protocol is an option here
• No need to store previous sensor values, can simply maintain a bank of 6 registers (3 per axis, per sensor means 6 total registers). NXT can address each register independently to access each of the two "sets" of available data (gyro or the accelerometer)

• Latency may become an issue given the real time nature of the sensor, to retrieve measurements along all DOFs will require three separate polls for three separate register accesses. The latency of consecutive I2C accesses can be factored out by driving multiple I2C buses and then running three parallel accesses instead of three consecutive accesses on the same line. The tradeoff is port use on the NXT.

Electret Mic - An idea I've been throwing around, use a mic for tone recognition. This could serve similar purposes as the IR Receiver for remote control, or possibly recognition of the surrounding environs (buzzers/sound elements/etc.). The Arduino Uno's Atmega328 is a little skimpy for real time processing at any level above an FFT, so I think I'll stick to that for pitch recognition.