A few words on design, technology and SMA / David Delabassee

The weather was really bad here last week-end. So it was the perect excuse to spend some time to play with Kinect!
After a few hours, I have a simple Java/Processing Kinect tracking application apps that works fine.
I am tracking complete blobs but it seems that tracking the center of a blob also gives quite good results (see the blue dot Vs. the large blue rectangle).
Right now, calibration is manual and minimal but it works. It was my first steps but while doing this, I came with several ideas I’d like to test when I’ll have some time : improved calibration, improved blob (and parasite) detections, multi-depth tracking, etc. I have also some ideas I’d like to test to do some simple skeleton detection…

Kinect Tracking from David Delabassee on Vimeo.

I am waiting a few bits to be delivered to do something that involve Kinect and Arduino…

I have received several questions on my previous post about how I did to use the DFRobot Ethernet shied with the DFRobot LCD display shield. This post will clarify that…
According DFRobot site, the Ethernet Shield use digital pins 2, 10, 11, 12 & 13; it is compatible with the Arduino Ethernet library. While the LCD shield use digital pins 5, 6, 7, 8 & 9 and works with the LCB4Bit_Mod library, a modified version of LCD4bits.

This document says that Ethernet Shield uses the 10, 11, 12 & 13 pins and the LCD shields uses the 4, 5, 6, 7, 8, 9, 10 pins. So the details on which pins are used is inconsistent at best!

Using one shield at a time on an Arduino just works but using them stacked, doesn’t! If you exclude a potential power consumption when the 2 shields are used together, the problem should be somewhere else….

To find the issue, I have actually checked in the source code of the library, which pins are actually used.
LCD4Bit_mod.cpp:

...
// --------- PINS -------------------------------------
//RS, RW and Enable can be set to whatever you like
int RS = 8;
int RW = 11;
int Enable = 9;
//DB should be an unseparated group of pins - because of lazy coding in pushNibble()
int DB[] = {4, 5, 6, 7}; //wire these to DB4~7 on LCD.
//--------------------------------------------------------
...


The LCD shield use digital pins 4, 5, 6, 7, 8, 9, 11; while the Ethernet shield use 2, 10, 11, 12 & 13. Clearly both shields are trying digital 11, that’s the problem!

To fix, just change LCD4Bit_mod.cpp (on Mac : Arduino.app/Contents/Resources/Java/libraries/LCD4bit_mod/LCD4it_mod.cpp) to use another unused pin :
int RW = 3; // was int RW = 11;

You can now stack both shields, they will both work!

I did for fun a few experiments with Arduino and here is the first result, a simple GlassFish Hardware watchdog. It uses a regular Arduino (Duemilanove) board with an Ethernet shield and an LCD/keypad shield.

Both shields are from DFRobot, they are quite cheap and reliable too! The only real issue I faced is that both shields didin’t worked together!  It wasn’t very easy to figure why both shields didn’t worked together as the shield documentation is … where is the documentation by the way ?
To find the issue, I had the look the ethernet and lcd library code to figure which digital ports were actually used and it turned out that both shield were trying to use a common IO port (digital 11).
 
To fix this, I changed one of the library (I choose to change the LCD lib) to instead use an unused digital IO port.  My setup is using LCD4Bit_mod, I didn’t bother to check if the conflict was coming form the ‘mod’ version of LCD4Bit.  Using the GlassFish REST Admin API, the watchdog will, at a regular interval, ping a GlassFish instance on the network.

If the GlassFish instance is up, GF will responds back its uptime since it was started and the uptime (ms) is displayed on the LCD screen. It was a basic test so I only display an error when something goes wrong.

I plan to improve this a little bit by for example improving the error messages, doing some lower level tests (e.g. is the GlassFish host reachable at all?, etc). The watchdog could also try to restart the instance using a REST call but this assume that GF is already running.  Anyway, worst case the WatchDog could eventually reboot the server.

The nice thing about this is that it easily extensible, e.g. SMS notification is one GPRS shield away!  I’ll polish the Processing code a little bit and publish it here soon.

In my setup, USB is only used to power the watchdog. The connection to GlassFish is done over HTTP/Ethernet.

I still need to improve the messages, e.g. ‘Querying…’ shouldn’t be displayed once we have an answer from the GF instance but it’s difficult to have meaningull messages on a 32 characters display!

Look Ma, no soldering!

The hardware stack unstacked!

Blog is now installed and running… still need to do some cleanup.