Not So Smooth

While waiting for the rest of the parts to turn up I decided to play with the colour mixing logic to produce a colour for each orientation of the accelerometer. The aim is to get six colours, Red, Green, Blue, Cyan, Magenta and Yellow.

In my first attempt I was just using absolute values from the accelerometer this allowed for mapping to Red, Green and Blue on each axis. E.g. X and -X (Upside down) both mapped to blue. To get the six colours, X and -X must be different.

The following table shows how I think this should work.

Axis Colour RGB(Hex)
X Red FF0000
Y Green 00FF00
Z Blue 0000FF
-X Magenta FF00FF
-Y Cyan 00FFFF
-Z Yellow FFFF00

The readings I am getting from the accelerometer range from -1024 -> 1024, actually they sometimes fall outside this.

So for each axis reading I convert to the hex value based on the following logic.

if (reading > 0)
reading_avg = map(reading, 0, 1024, 0, 255)
else
reading_avg = map(reading, -1024, 0, 0, 255)

The map function maps the given reading from one range to another.

I am taking the average of the last 10 readings to smooth the transition, as the accelerometer in a resting position gives varying readings, hence reading_avg.

This works in a fashion, but is not as nice and smooth in the transition as it is when dealing with three colours. It often jumps to another colour rather than a smooth fade.

I think this is caused by a reading flipping into a negative value, causing a sudden change from a low value.
So when X and Y are giving readings near FF, and Z is or should be 0 a slight movement will cause it to go negative and produce a reading near the FF range. So I need to make the logic a bit smarter around the boundary cases.

I have just noticed as documenting this that I am using the average values in the calculations which may not be helping.

Looking back at the code now I am thinking less haste more DOCUMENTATION :)

So some success in was achieved with this, have something to work on.
Need to recheck code logic, look at adjusting the smoothing function to average across more values, and maybe adjustments in the mapping logic around the boundary cases.

But now the new bits are here, I think some wireless transmission tests might be the go.