Looks pretty impressive, congrats.

Thanks folks

You should sell your design lol :)

Thanks Tyler.  Great find.  What is uint32_t?  I think I saw that in your prior code too, if I'm correct.  

uint32_t is a 32-bit unsigned integer data type as defined in the AVR version of inttypes.h (a common C/C++ library), part of the Arduino core:

• http://www.nongnu.org/avr-libc/user-manual/group__avr__inttypes.html
• http://www.atmel.com/webdoc/avrlibcreferencemanual/group__avr__inttypes.html

Both links describe the same thing, but one is by Atmel (Microchip, nowadays) and the other by AVR Libc. Not actually sure which one of them is responsible for it.

The common Arduino equivalent on the Arduino Uno is unsigned long. I like using inttypes.h because it explicitly sets the word length (32-bits, in this example), whereas the word length may change if using the Arduino language. An easy example is double: it's 4 bytes on Arduinos that use ATmega chips (e.g. Uno), but 8 bytes on those with 32-bit chips (e.g. Due).

Nice video Tyler.  Why did the graph peak for the whiteout object? And what software did you use to graph your chart?  Thanks very much.  

Each object is a different height and volume, so the echo time is different for each, which is what I was hoping. I used Excel to graph the data.

The way the preprocessor debug blocks are setup, they can all be completely removed from compilation by commenting out one line. It makes it really easy to turn debugging on or off in different files. Though ForceSensor.cpp has only simple DEBUG() macros, I've gone a bit further with them in other files. AutoMoveSD.cpp, for example, uses three 'levels' of debugging, each of which can be activated or deactivated individually, or all at once. It lets me control how many debug lines the program is spitting out. Might make it easier to remove all of them, if need be, too. Would use some parser to remove any line with 'DEBUG', 'PRE', 'POST', or 'BREAK', then use a diff tool (git, etc) to make sure I'm not deleting a line by accident. Anyway, it seems ugly but its better than nothing, and way better than bare 'Serial.print(blah)' lines that I later have to hunt down and comment out.

Constraining the sensor values wouldn't have worked since any value over 255 would have been set to 255, but mapping them might have -- Arduino core has a map(...) function: 

uint8_t eightBitValue = map(tenBitValue, 0, 1023, 0, 255);

The way I did it ensured half-up rounding with integers ((numerator + denominator/2)/denominator). I'm not certain that map does this.

Thanks Tyler. How did you know the "debug" command worked with the sensor?  Was it in the documentation?

I don't know where to find documentation for sensors and libraries.  Where do you get yours?  Please kindly advise.

Thank you. 

Nothing really works with the sensor. It's just a resistor. Arduino's analogRead() does the trick. I usually find docs by Googling them.