RoadTest: Gertduino
Author: doorknob
Creation date:
Evaluation Type: Independent Products
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: I had considered building my own custom Arduino clone to perform the desired function, however the Gertduino was much more attractive than building my own custom board, because the Gertduino already has the necessary voltage level conversion built in. There are other boards that claim to have similar functionality, such as the AlaMode board, however I had not originally planned to use such a board, rather I had intended to "roll my own" Arduino.
What were the biggest problems encountered?: The documentation supplied for the board is good as a reference, but it is not suitable as a 'getting started' guide. In order to get the product running it was necessary to do my own research at several different web sites to learn enough. As a result, I suspect that a novice user would have difficulty using the Gertduino. Also, the version of the online manual that was linked to from one of the product pages at the element14 site was incomplete, as it was missing the schematic diagram. While I am not certain, my impression is that the advertised "IRDA" interface feature is somewhat misleading, as it appears to be a consumer IR receive-only sensor rather than the actual two-way IRDA transceiver that I had expected to find, based on my (possible mis-) reading of the Gertduino marketing materials.
Detailed Review:
I performed my Road Test of the Gertduino board (supplied by element14 - thanks!) as a component of an experimental all-sky camera that I am building based on the Raspberry Pi. I have been blogging about my experiences with the Gertduino at Ed Kalin's All-Sky Camera Blog and I expect to continue blogging as I work with the board in my project after completing my Road Test.
My overall assessment of the Gertduino is that it has a lot of useful, built-in capabilities and potential which have made it a good match for the requirements of my project, marred only by the need for the user to perform a great deal of time-consuming research to dig up enough information to get started using the board with the Raspberry Pi.
The Gertduino is an Arduino clone that is designed to plug directly into the Raspberry Pi's GPIO expansion port connector, which permits both boards to work in tandem.
The Gertduino has the identical "footprint" as that of the Pi board. When the Gertduino is plugged into the Pi's GPIO expansion connector, most of the Pi's other expansion ports remain both exposed and available for use. For example, the Pi's USB, HDMI, audio, video, power, network, and SD card ports remain accessible. The connectors located on the top face of the Pi (such as the camera module connector) are blocked by the Gertduino, however if a flexible cable is inserted into the connector prior to mounting the Gertduino onto the Pi, those functions can still be used. My application requires the use of the Pi's camera module, and the Gertduino did not interfere with my use.
Mounting of the Pi board has always been a bit of a problem - the latest version of the Pi has two fixturing holes which are typically used as mounting holes, which at least partially address those problems. Mounting of the Gertduino atop the Pi is not particularly sturdy, either - the GPIO port connector provides some mechanical stability for the Gertduino board, and a rubbery bumper stuck to the opposite end of the board's bottom that rests atop the double-high USB connector of the Model B Pi adds to the stability of the mounting (and works to prevent a short circuit between the bottom of the Gertduino board and the top of the Pi's components), but there is no obvious way to securely hold the Gertduino board to the Pi beyond the friction provided by those contact points. In some applications that may cause problems, but so far with my application it has not been a problem. I have not tried mounting the Gertduino atop a Model A Pi board (which lacks the double-height USB connector), however I wonder whether some additional support might be required when using the board with the Model A.
To actually start using the Gertduino takes a fair amount of work, including setting jumpers, loading software onto the Pi, modifying some of the Pi's configuration files, and loading code onto the Gertduino's processor(s), which I have detailed in my blog postings. On the one hand, that means that a novice user may stumble a bit in getting started - in fact, so did I - but when all is said and done the user gains an understanding and insight into how things actually work under the covers that would be missed if everything were done automagically for you. As a disclaimer, I drive a car with a manual transmission and stick shift, and so coping with Gertduino setup was par for the course for me. Others may prefer an automatic, however.
Once installed, there are several ways to actually use the Gertduino. You could, for example, simply use the Gertduino as if it were a standalone Arduino that can be conveniently programmed by running the Arduino IDE development software on the Pi. However that approach misses the real power inherent in the Gertduino board, namely the ability to craft an application that uses the best features of the Pi and the Arduino in tandem. For example, the Pi notably lacks built-in analog-to-digital conversion capabilities, which can be provided by the Gertduino. In fact, that's the basis for many of my application's needs that the Gertduino will fill. I want to take analog sensor readings - temperature, humidity, battery voltage readings, perhaps also accelerometer outputs as well, and more, and integrate them along with with photo and/or video captures performed by the Gertduino. But performing digital I/O with the Gertduino is also so straightforward that I will use it for digital interfacing as well - turning LEDs on and off, perhaps activating a heating element to prevent condensation from forming inside my camera housing, and more.
The Pi itself has the capability of performing digital I/O. It can also natively handle I2C and SPI communication. But those functions can also be performed by the Gertduino acting as a "front-end I/O co-processor" for the Pi, a configuration that I prefer to use for my application. In my all-sky camera, my program logic on the Pi will be responsible for snapping photos and uploading them to network-attached storage. It will work nicely for the Pi to also orchestrate querying the Gertduino for sensor readings on demand, forwarding them to the network-attached storage as well.
The Gertduino's built-in buffered LEDs (six of them) are a useful feature, albeit one that was confusing until I was able to find the Gertduino schematic and understand how the buffering was implemented. It would have been helpful for the documentation to mention that the LED states should be initialized within your Arduino program (if you choose to use them), otherwise you may get some stray and unexpected LED on/off behavior. Of course if you intend to use the pins that are connected to the LEDs for digital I/O functions other than driving the LEDs, you will see the LEDs blinking nevertheless. For my application, I would have preferred for the Gertduino to provide headers to make it easier to use or disable the buffering (and the LEDs) with more flexibility (such as mounting one or more of the LEDs off-board). The lack of that flexibility is not a big deal to me, however.
A substantial part of the Gertduino board's "real estate" is taken up by unpopulated circuit pads that could be used to add an external power port to the board. I question the need for such a function, inasmuch as I'd expect that powering the Gertduino directly from the Pi will be the normal operating mode for the board for most users, rather than running the board as a standalone Arduino. So I would have preferred devoting that board space to other functions (such as making the LED interface more flexible, as described above). It's not a problem, rather it's just one of those WIBNI ideas that came to me while working with the board.
I have not yet attempted to access the Gertduino's real-time clock feature. That will happen soon, however - keep an eye on my blog where I will report my experiences. While there may be other reasons for using the on-board ATmega48 processor beside RTC emulation, I haven't yet found a need for it in my application. But I'm still working on fleshing out the all-sky camera, and so it is possible that a need will arise, so I will keep that bonus functionality in the back of my mind. In similar fashion, my application does not require the use of the on-board pushbuttons, however I expect that they will come in handy while I am debugging my sensor interface code, and so I will keep them in mind for future use.
As mentioned above, the Gertduino's "IRDA" feature has turned out to be less than expected, and so I did not test it or use it. In fact, I did not actually need that function for my all-sky camera application, and would not have built it into my Arduino clone if I had gone down that route, but since it was advertised as a Gertduino capability it got me thinking of ways to use it - until I discovered that my newly-imagined use would not have been practicable, which is why I decided not to use it at all.
In summary, once I got over the getting-started hurdles, the Gertduino has turned out (so far) to be a valuable adjunct to my all-sky camera application, and I intend to continue exercising its features as I work to enhance its integration with the rest of my camera development.
