At Blablacar, we organise a coding night twice a year (articles about the previous edition are available here and here). The event spans 2 days and a night during which the members of our engineering team can work on the project of their choice alone or in groups.
Being passionate about electronics for a number of years, I endeavoured to build an embedded system designed to improve our daily life:
- Every morning, automatically turn on the TVs we use for our monitoring dashboards, and automatically turn them off in the evening.
- Automatically fire an alert when a build fails on our continuous integration tool (Bamboo).
To KISS (Keep It Simple Stupid) and retain modularity, I decided to split the project into multiple devices.
On one side we have a device which contains all the intelligence required for the project. Let’s call it the ClaudoBip. It will act as the brain and dispatch orders to the other simpler devices, which will be in charge of the execution. Let’s call them the Claudine.
The ClaudoBip is connected to the Internet and has a processing power that is quite “high” for that kind of device : 32bit ARM CPU running at 48MHz / 32K RAM (To compare, the Claudine use a 8bit CPU running at 16MHz / 2.5K RAM and the Apple II launched in 1977 used a 8bit CPU running at 1MHz). Its role is to take the right decision at the right time and inform the Claudine so they can perform their tasks.
For example:
- Ask for the TVs to turn on at 9am.
- Ask for an alert display when a build fails.
ClaudoBip and the Claudine communicate via radio. The radio operates at 433MHz frequency because using this frequency in France does not require any special authorisation and the required hardware is cheap and easy to find.
The ClaudoBip is the transmitter and the Claudine receptors. Claudine will listen to all the messages emitted by the ClaudoBip and handle them if necessary.
In this configuration it’s possible to add as many Claudine as we want without modifying the ClaudoBip.
Here is a representative diagram:
Embedded system
To turn the ClaudoBip into reality, we faced several constraints: size, energy consumption, cost and resiliency.
Due to the simplicity of the tasks at hand it was out of question to use heavy hardware.
A RaspberryPi or other mini-PC were not well suited for the task for multiple reasons:
- High energy consumption
- Required maintenance (eg: OS updates…)
- Low resiliency (power outage could imply OS corruption)
- Way too complicated & too powerful (You don’t use a rocket ship to go to your office in the morning ;-) )
An embedded system matches all these requirements better.
It uses a low energy microcontroller allowing to run programmable software. The software is executed at low level without abstraction stack. We call this a firmware. It is written only once during the programmation phase, and will be accessed in read-only mode on runtime as much as needed.
You already have embedded systems all around you without even noticing them (inside your washing machine, bank card or electronic thermometer, etc.)
For all theses reasons an embedded system was used to build the ClaudoBip.
Hardware choice
To make the ClaudoBip we used the following elements:
- A main microcontroller (to execute the firmware)
- A wifi connection (to query several APIs)
- A clock (to execute recurring tasks)
- A radio transmitter and its microcontoller (to dispatch orders to Claudines)
The chosen main microcontroller is an Arduino MKR1000, mainly for its ARM 32bits processor that offer good performance and its Wifi chip that support SSL encryption.
On top of that, Arduino provides an SDK for easy development.
Microcontrollers don’t have a clock, so we need to add one. We used the standard DS1307. Its role is to provide the current time through the I2C communication protocol, like a watch would do.
To communicate, a simple 433MHz radio transmitter is enough. It is managed by an Atmega328 microcontroller and communicate with the main microcontroller using the I2C protocol.
Building
Now that we have chosen the hardware it’s time to move on to actually making this thing.
After a prototyping phase to make sure the assembly will be smooth and some calculations for the components value, we are now able to move on to the PCB (Printed Circuit Board).
To do that we use the Eagle Software (which provides a very good trial version).
The first step is to create a schema on which we place all the components that we will then connect electrically.
Here is what it looks like for the ClaudoBip:
As you can see, the scheme is cut into 2 parts. On the left side we will have the Arduino MKR1000 (the brain of the project) and on the right side the radio management.
Those 2 parts will be stacked one above the other and communicate using two wire connectors (the gray dot arrows) with the I2C protocol. This offer two advantages:
- A reduced size
- A good scalability: we can stack many additional PCBs above to add functions. Each PCB has its own microcontroller and join the existing I2C link.
Now we can take care of the PCB (still using Eagle).
The previous schema was made to validate the model, but without any real physical constraint linked to components size. The goal now will be to place them using their real shape and draw the electric wire:
Here we can see the components (green slots) that will be connected to the others. The blue lines represents the electric wires to link them.
Time to move on and actually build our PCB. Next steps are:
- Print the circuit and the slots on a bakelite plate covered with a fine copper coating.
- Deep our plate inside a chemical bath that erase the copper.
All the copper that is not protected by ink will be dissolved and disappear.
Here is what it looks like:
After cleaning, only the tracks & slots remain. The PCB is ready to use.
What’s remaining: drill all the slots, place the components inside and solder them.
To add a bit of fun I used a toy bus as a case:
Running
The firmware is written in C, with some specificities to run on embedded components like this. Especially taking into account the reduced RAM and the architecture instructions which are different from the classic X86 we can have on a PC.
The software is able to perform the following tasks:
- The ClaudoBip asks (over radio) to turn on the monitoring TVs at 9am and turn them off at 7pm. The Claudine is in charge of executing the task when receiving the signal.
- Every 30 seconds the ClaudoBip check the different states of our continuous integration builds using the Bamboo API. In case of build failure, it sends the informations over radio and the Claudine in charge of the visual alert lights up.
It’s used each and every day
This project was a good opportunity for me to improve my electronic and software development skills on this type of architecture.
The ClaudoBip is used each and every day in my team to warn us as soon as a build fail and allow us to react more efficiently.
Last but not least, we improved our power consumption by turning off TVs that could stay on over nights or on weekends.
Thanks to all the people helping me to build this project, especially Fanny for having organised the coding night where this project was born (and having bought the hardware), Nicolas T. and Yoann for their precious help in writing this article.
