Every hardware hobbyist has experienced that painful moment when you smell smoke and discover that it's coming from your hardware project. It's a rite of passage. Wouldn't it be nice if you could test your hardware before burning it? At the Open Hardware Summit, held in Boston recently, I saw that MathWorks' Simulink offers an appealing alternative that allows you to debug your model (embedded software) before deploying it onto hardware.
This Simulink robot tracks a green dot cutout and follows it. Central is the Raspberry Pi.
A Simulink-powered robot caught my eye at the summit. Like a good pet, this robot tracked a green ball moving around on the demo floor. The robot is interesting from a hardware perspective because it uses both a Raspberry Pi and an Arduino Mega2560 communicating over the UART serial port interface. But more interesting is the amount of time spent on writing C code. It's negligible!
If you are a hardware hobbyist like I am, you probably enjoy designing and building systems rather than wrestling with code issues. Simulink makes this possible with its graphical modeling environment and automatic code generation capabilities. From an educator’s perspective, Simulink offers a way to ease the learning curve for programming languages. Also, portability of your design to another hardware platform becomes easier than having to move your C-code to another development environment. I watched the program get worked on at summit -- it looked so easy.
However, let’s dig a little deeper into the demo to understand how this is possible. Here’s a snapshot of the Simulink model deployed on the Raspberry Pi. This block diagram matches the mental model of a hardware hobbyist way more than C code does:
Raspberry Pi connects to a webcam and acts as the vision system for this robot. The image-processing algorithm for detecting a green ball is implemented using a built-in block from Simulink. The Pi also computes steering and driving commands for the Arduino based on the ball location in its field of vision. These commands are then communicated over the serial interface. This division of work makes sense, since the Pi is an order of magnitude faster in terms of processing speed as compared to an Arduino Mega. By simulating this model with real-time camera input, you can visualize, debug, and test the computer vision algorithm before you decide to deploy it on the Pi. Once you are confident about the design, you can generate code from this model with the click of a button to deploy it on the Pi.
Similarly, the following snapshot shows the Arduino model used for motor control:
The Arduino Mega2560 drives the motors and interfaces to a couple of sensors, such as a bump sensor, a light sensor, and an ultrasonic distance sensor. As you can see from the model, the Arduino receives steering and driving commands from the Pi, decodes the commands to compute the intended state of the robot (for example, steering, stopping, or driving straight). The servo angle is then sent to the motors connected to the wheels that control the movement of the robot. The four-wheel steering logic block shows an intuitive way of representing the different states of the robot. This chart highlights the current state of the robot during simulation, which is a handy debugging capability. Here’s a snapshot of the state transition diagram:
As with the Pi model, you can test this model with signals from Simulink or with hardware in the loop.
All the blocks in these two models are built-in Simulink blocks except the serial communication to the Arduino block from the Raspberry Pi model. The demo developers wrote a small amount of C-code to develop this block. The user community has come up with a way to create your own hardware interface blocks that are not provided in the Simulink library. For example, here’s a guide that describes how to develop Simulink driver blocks for Adafruit motor shield.