I-m working on a hybrid mbed and Arduino project. Arduino, together with Processing, of course has an interesting GUI interface capability offered with the whole package. And I know the mbed can also receive info from or feed back to Processing. However, in the long run I would like to see my project being platform independent, i.e. capable of communicating with a MS Windows, OSX, Linux, or PDA based environment over serial, bluetooth, xbee or similar serial connections. The GUI should have both text and graphic info presentation capabilities to show sensor values graphicly, via gauges, or via text, and to be able modify parameters. I-ve done a bit of looking around and I-m ending up with either QT or wsWidgets as toolkit and C/C++ as programming environment as the solutions which offer both quite good all platform capabilities and have the advantage of using the same programming language. Alternatives would be Python or JAVA, both of which are interpreted (and thus could be a bit slow for graphic presentation of high sensor data rates), and both of which result in having to work in two different programming environments.

Looking around it is quite striking how few fully documented / developed extension there seem to be to toolboxes to build robotics / instrumentation GUIs. E.g. it is even difficult to find good examples of a ready build basic form with serial IO routines for serial communication (including ability to choose form e.g. up to 10 com ports). That would really seem to be the first starting point to build a GUI for any mbed / Arduino / ... project. Other parts I could imagine being usefool would be definition of a simple way to link a widget to a piece of info received or sent to the mbed (e.g. using CSV data and then linking the display to the x-th element in the CSV list returned), and of course some example forms with nice widgets to show or enter data.

Might it be a good idea to build a repository of building blocks for a "platform independent" GUI here ?

If so, should there first be a bit of discussion about a toolkit --QT, wsWidgets, GTK+, etc-- which offers the best compromise-- and the programming language --C/C++, Java, Python, or a combination of all three-- or should we just go for what currently seems to be one of the best supported but still freely available kits (QT) and its main programming language (C/C++) ?

Hi Arthur,

I think it is very difficult coming up with a generic GUI because itdepends on the target audience.  If you build some kind of "box" and want it to conect to "PCs" it is not uncommon to make the device behave like a web server and using TCP/IP.  That is a good way to get platform GUI independence but is less than ideal if you want to provide a "programmatic" interface to the "box".

Regarding what language toolkit to implement a native GUI in is a "religious" question.  It is also dependent on competence.

Anyway, I would personally go for web interface based on TomCat/Java but that's obviously just my "religion" :-)

Hacking GUIs in C++ is though something I would not recommend because there are too few people who can do it.  I've done some Symbian and Win32 GUI and it was not fun at all.

Anders

I-m really looking at a real time application which reads a number of sensors and controls a number of servos and electric motors, not a web server based thing. Such real time applications want telemetry data over XBee, Bluetooth, or a simple serial (or serial over USB) connection, not a TCP/IP connection. So the primary part needed for a GUI for such an application is the simple serial terminal program example For QT this is one which works under windows: http://code.google.com/p/freejalduino/downloads/list (SerialPortTerminal.tgz has the source code for compiling using the QT libraries, QSerialPortTerminal.exe is a precompiled windows executable). It is a modified version of the QSerialPortTerminal program found on the QT applications site which only recognised COM1 and COM2 under windows, while this version allows you to pick the right COM# from a list (but doesn't actually recognise which are active).

A next part could be a number of labels which can be fed from a text file, and a number of text boxes which can be fed from a line of comma separated values from the mbed. This would allow you to define the labels for the return values independent of the actual application (e.g. wouldn't matter whether you were sending back "gyro x value, gyro y value, gyro z value, acc x value, acc y value, acc z value" or "gyro x value, acc x value, gyro y value, acc y value, gyro z value, acc z value" as you would adjust the label sequence in the text file to properly label the text boxes.

A similar approach would then also allow graphing values over time by choosing which values to graph and setting a colour for each graph.

A final building block could be the reverse of the textual display, i.e. similar screen with labels driven by a text file and parameter values entered by a user (or read back from the mbed). In this instance you might want to be able to set the sequence in which values are returened to the mbed to correspond to what the program on the mbed expects (which may not be the most convenient sequence for display).

The above would still be reasonably simple. A more complex system would only be exchanging subsets for data (e.g. the GUI would indicate to the mbed that it was no in the GPS screen, so only send back the train of GPS values, not all the gyro and acc values, or it would indicate that it wanted the parameter settings for the GPS Navigation screen, or wanted to write back those values after editing them. This could again be "generalized" by driving the screens / subsets with numbers or other identifiers to be exchanged.