Language Immersion

They say that the best way to learn a language is to immerse yourself in it. Based on my recent experiences with programming in C++, I would tend to agree. Having had no formal training in any sort of programming before, I was initially rather worried that coding sensing sequence for the dome would be a difficult task. The previous code I had written was very rudimentary stuff - it worked, but was not terribly refined or advanced at all. I've managed to complete a basic skeleton of code in just under three days of work that allows me to run through an entire sensing routine for 16 LEDs in a hemisphere. With limited resources around, I headed over to RIT's Wallace Library to pick up some books on C++. The Arduino uses a language based on C++, with some additional functions created specifically for use with Arduino microcontrollers. I spent the better part of a day and a half reading through them, taking notes and copying down concepts that I would need to help me code my solution.

My initial pseudocode sketch looked a little like this:
- initialize serial communication on microcontroller
- wait for user input before starting lighting sequence
- turn on light 1
- sense with all other LEDs, repeat 10x (take 10 readings per light)
- average data from sensed light
- output data to serial port
- repeat process for all other lights, until every LED has been used both as an emitter and as a sensor.

The difficult part of this code is the exclusion of one LED from the sensing process. The emitter cannot be used as a sensor simultaneously - otherwise, it will flicker and produce uneven results from the rest of the sensing LEDs. For previous code, the LEDs had been set in a single-dimensional array, which could be called throughout the entire sensing process quickly. It was a compact way to represent a big group of sensing LEDs. Unfortunately, however, to my knowledge it is not possible to exclude a single item from an array. Thus another solution had to be created.

For this, I decided that it would be appropriate to put all of the lighting sequences into their own two-dimensional array, manually. Each column of the array contained a new lighting sequence, where each column omitted the emitter LED from the sensing sequence. For the Arduino Mega, I could support 16 sensor LEDs, giving me an array that was 16 columns long and 15 rows tall. The 15 rows in height comes from the fact that each illumination sequence uses one LED less than the total number of LEDs (one LED is emitting!). Using this as a starting point, functions could be modified to step down rows of a column, triggering sensing LEDs one by one and skipping the emitter LED.

ArduinoMegaBoard.JPG
The fully-wired Arduino Mega board to test the new code.


It Works! (basically)

A few days after beginning my comprehensive crash-course of C++, I put out my first "finished" bit of LED sensing/emitting code. This code could run 16 LEDs off of my Arduino Mega board, completing its sensing/emitting sequence in only 15 seconds. This is the initial version, though, and it is not perfect. I have yet to refine its output to the point where it prints useful, labeled data to the serial monitor - a big issue of usability. Another issue is that of electronic interference at the A/D converter on the microcontroller. This setup runs as quickly as it does because all LEDs are essentially sensing at the exact same time. This may be causing significant interference and tampering with the results of the system. Unfortunately, at this time I cannot prove this theory with any hard data - my testing setup used LEDs which had no measured response functions. These were the only LEDs I have right now that are in a quantity greater than 12.

The basic system is functional, then. The components, however, are not. More LEDs with "good" response functions are necessary to continue testing the system and determine whether electrical interference between LEDs is a significant issue in the system. Initial code from this test setup is found below, in .pde form.


Revisions (I)

With the framework for my code finished, I've decided to tackle some revisions to this code. Such revisions include:
- fix issue with emitter LED flickering. I must have misplaced some brackets; the emitter LED flickers during the sensing sequence, which can't be beneficial to the sensors in this setting.
- clean up output. Previously, the output was a very large, messy set of numbers that were not labeled, averaged, or categorized. I want to create an algorithm to average the outputs of ten readings from the sensor LEDs, and output that instead of a bunch of raw numbers. This will make processing the data much easier when the time arises to do that.
- print the name of each sensor (A0, A1, A2, etc.) above each reading - since the number of readings does not change from sequence to sequence, but the pattern of sensor LEDs does change, I end up with a block of numbers that are all associated with different LEDs.

The good news is that I have solved one of the problems. The flicker from the emitter LED was just a result of a couple lines of misplaced code. That was a fairly easy fix. Unfortunately the code for averaging my results has been a very tricky implementation... I have spent most of the day (7/20/11) trying to get averages from my sensors, but have been unable to come up with any useful results. Having beaten my head against a brick wall of C++ for six hours today, I'm beginning to think that it's time to take a little break and work on my poster and presentation for RIT's Student Research and Innovation Symposium, which takes place on August 8th. Seeing as that's about two weeks from Monday, it's time to get working on the presentation materials.

Revisions (II)

With the help of some wonderful people in the Arduino forums (see http://arduino.cc/forum), I have solved the issues I was having with the averaging system yesterday. Now, the Arduino serial monitor prints a single output - an average of ten readings - for each sensor with every given emitter. This simplifies the output of the system greatly. I hope to implement standard deviation here too, as that will provide some useful data as to how large the variations in the system really are. Things will be looking even better when I get enough LEDs that are actually useful sensors - then I can fill my new system with good LEDs and begin testing its outputs.