Wednesday, June 13, 2012

Arduino, QP, and road intersection requirements

For many months now I've been planning to implement a simple project with the QP framework and its graphical modeler, QM. The QP framework makes it easy to create reactive systems based on the idea of UML statecharts.

Finally I got the motivation to sit down and learn its basics: I am teaching talented high schoolers this summer, and I am going to ask them to verify that a road intersection controller meets its requirements. I implemented this road intersection controller on an Arduino Uno using the QP framework. The sample code supplied with QP was a huge help for this.

Now I see how "tiny" the Arduino Uno is. I am using 10 of its digital ports. It comes with only 13, and I am leaving a strategic three unused because they're spaced so close to each other that some ports have to be skipped to avoid bending pins.

The intersection has four directions (N, S, W, E). Cars approaching from north and south have a basic stoplight without turn arrows. Cars approaching from west and east have a protected left turn arrow. And, all four roads have pedestrian crossing. The intersection "detects" a vehicle waiting in a left turn lane, just like in real life. It also allows a pedestrian to push the crosswalk button. (In reality this means that there are two pushbuttons wired to the Arduino: one for left turn, one for pedestrian crossing.) These two are the only events the Arduino processes, since only two digital pins can have an interrupt attached to them. The remaining ports are wired to LEDs, to display the state of lights.

The three leftmost LEDs are for north/south traffic. The next four are east/west traffic, with right-most yellow being the protected left turn. The right-most blue LED is pedestrian "WALK" signal. (Blue is the new green.) At this moment, pedestrians may not walk, east/west traffic is stopped while north/south traffic is speeding up to beat the yellow.

This was surprisingly easy to implement with the QP framework: I just basically enhanced the Arduino BSP source code that came with the QP framework to accommodate all the digital ports I am using, then drew the UML statechart for the intersection controller. And it worked. Better yet, developing this was fun.

The combination of QP and QM gives me confidence that it's easy to make the intersection controller much more advanced: eastward vehicle detection separate from westward, independent pedestrian crossings, dynamic timing (based on flow of vehicles), and more. The limitation is the number of available Arduino pins.

Would you look at the requirements I've written up for the intersection controller, and see if I am missing any? I'd like to make this set of requirements pretty thorough, as the more requirements there are, the more flexibility the students will have for what to test. If you have some suggestions, please post here or contact me any way you prefer!

Lastly, I want to thank Dr. Miro Samek, the author of QP + QM software. He's undoubtedly very busy, but he found the time to answer a question from me by email. Maybe someday I'll have an opportunity to use his great software in a commercial product!