1. Correct the checksum calculation and run the program again.
2. Connect the GND wire
3. Check if the accelerometer is working (move the robot, rotate it etc while logging data.
4. Remove the fur carefully and inspect the inside. (make sure the sensors are still taped to the robot).
Detailed Observations:
1. Correcting the checksum:
After correcting the checksum I ran the program twice; once with the GND connected and once without it. In both situations, no more "bad data" was being read.
2. Connecting the GND:
For some reason, as soon as the GND is connected, the normal flow of the program stops. The GUI no longer updates and everything freezes. => check with Kerem again.
3. Checking the accelerometer:
I ran the program 3 times, once just holding the creature, once slightly rotating it from left to right and once slightly rotating it from back to forth. The plots below show the first column read by the accelerometer in these 3 situations respectively:
holding:
rotating on sides:
rotating back and forth:
4. Removing the fur:
I carefully removed the fur and ran the demo program. All the gray shades were caused by the weight of the fur on the sensor so after removing the fur, I saw a very clean, white map. The black area on the bottom left corner was still there. My next task is to see why that is caused.
Some questions, on accelerometer data plots (which need units: I'll assume they are voltage on y-axis, and milliseconds??? on horizontal, time axis. The time axis is quite important).
ReplyDelete- it looks like the range of motion is similar (to oom) for 'holding' (~80) and both 'rotating's (140, 130). I would have expected holding to be more still; can you explain this case better? Might help to do a case of the robot sitting still on the table, as a baseline (just make sure it really is flat). And perhaps one of sitting stably on your lap in a chair that doesn't move easily - laps may have less tremor than our hands or arms.
- Also, 'rotating on sides' is quite smooth, but the other two are noisy. Can you think of an explanation for this based on the motion it was subjected to, or should we look for a technical explanation? Can you run these two traces through a FFT (fourier analsyis to see its dominant frequencies? this will be a clue as to whether they are human-sourced or electricomechanical.
(and, can you confim that the accelerometer is rigidly mounted to the frame, and not vibrating at all?)
- if the time axis is indeed about 4s (4000 ms) it is worthwhile doing longer traces. And some repetitions to make sure this clean-vs-noisy pattern is reproducible.
This comment has been removed by the author.
DeleteThe y axis shows the value for the first element of the accelerometer vector (which has 3 elements in total). The x axis is the time (in milliseconds).
DeleteI will plot the accelerometer data vs time for all the cases you have asked, today. I will also explain the results as much as I can in Feb 20 2013 post.
It might also be useful to plot the other two elements of the accelerometer. ( I will take a look into that as well).
Let me answer some of your questions.
ReplyDelete-- If Bita just plotted the accelerometer signal (with a command like plot(acc)), the horizontal axis is the sample number. If she plotted it against the timestamp value (with a command like plot(timestamp,acc)) then the horizontal axis should be milliseconds. The sampling time for the signals was around 13ms, if I remember correctly.
-- The raw data values are the outputs of the A/D converter. They don't have physical units. If Bita didn't modify the program already running on the Arduino, the accelerometer range must be +/-4g. We can easily change this if we want. But I don't remember the resolution of the converter. It's probably 11 bits and signed (we can change this too, if we want). So the data should range from -1024 (corresponding to -4g) to 1023 (corresponding to +4g). There's a practical way to test this. Let the robot lie still on a table, and record the acceleration vector (all three components) for a few seconds. Then calculate the magnitude of that vector. This should be g (gravitational acceleration). If it's close to 256, then what I wrote above is correct.
-- I think the smoothness is because of the axis of rotation. For example if, coincidentally, Bita was rotating the robot perfectly along the accelerometer's axis, we wouldn't observe any change in the acceleration. Bita, can you plot all three acceleration signals on the same plot?
Bita, this is a bit advanced for you, but if you're really interested, you can check the section on the 0x31 DATA_FORMAT register in the accelerometer's datasheet to learn about max ranges and resolution.
ReplyDeletehttp://www.sparkfun.com/datasheets/Sensors/Accelerometer/ADXL345.pdf
It's fine if you are not interested; you won't have to deal with that part of the Arduino code in this project.
I am more than interested to learn about it. I will read it today.
Delete