E.R.N.I.E

The idea

Surrey EARS run an Arduino course every year. When designing this course we needed some sort of extravagant project at the end to put everyone's newly learnt skills to the test. The idea we settled on is a traffic light network. Each student is tasked with constructing one of many traffic lights which are all connected along a common bus. As the students enter the room they are greeted with a complex line following robot track with multiple crossings. Each student is given a sheet that defines and when and where their traffic light is. It is up to the class to implement all the lights (20 in our case) to prevent the line following robots on the track from crashing into each other.

Implementation

Each traffic light is a relatively simple circuit consisting of an Arduino and 3 LEDs (and resistors) on a breadboard along with a connection to the common bus. Earlier on in the course the students learnt how to use I²C, they will now get to apply what then learned and create a slave device on a shared I²C bus. There is then a base station unit that serves two purposes. Firstly it sends a regular heartbeat along the bus on the general call address which is used to synchronize all the traffic light nodes. Secondly it allows the robots on the track to query the current state of a traffic light. The robots connect to the base station wirelessly via a NRF24L01. The base station was implemented on a ARM mbed board due to the fact it supports "multithreading" allowing the heartbeat to run separately from the query interface.

The base station produces an incrementing heartbeat at regular intervals. This heartbeat is a single 8 bit number that increments from 0 to 24 and then resets. This heartbeat is sent out on the general call address which is unfortunately disabled by default in the wire library that comes with Arduino. This can be remedied by using the following code after setting up wire:

bitSet(TWAR, TWGCE);

The students need to create a interrupt service routine that will update their state and attach it using the onReceive function of the wire library. Each student is given a handout at the start of the session that provides them with a unique address as well as a list of what state they should be in at what heartbeat value e.g:

When a robot is going around the track, it will stop whenever it reaches a junction marker, a solid line across the track. This triggers all the sensors of the robot's sensor bar which is easy to detect. When the robot stops at a junction it will begin to periodically poll the base station for the status of the light it is currently at. Once the robot gets a green light it will travel forward for a set time to clear the solid line caused by the junction. Since the track is a loop the robot only needs a simple counter to know which light it is at. When the robot polls the basestation, the basestation then in turn does a read request to the corresponding traffic light. The students need to create a interrupt service routine which will return its current state and attach it using the onRequest function of the wire library. The traffic light should return a number between 1 and 4 depending on its state.

This simple use of read and write requests means the code the students need to create remains simple while covering everything they need to learn. The students do not need to worry about commands/register values etc.

Problems

Despite what is written in multiple places on the internet about I²C only being able to go ~2m before capacitance renders the bus useless, we managed to get this system to work over 20m of CAT5e cable with crudely soldered connections, daisy chained through breadboards, every meter.

The signal quality over this bus is actually surprisingly good, the gotcha that caused bus instability was not bus capacitance. The issue comes from the Arduino, when it is unpowered the SDA and SCL lines get pulled to ground. Since this is a multi-drop bus, the second any of the students unplugs their Arduino from their laptop the entire bus fails! This leads to a lot of tail chasing during the session.

Future

The traffic light network is currently in the process of being re-engineered. Rather than using I²C, the network is being moved over to RS-422. This bus is designed to go long distances and features separate TX and RX lines. This means that should any student's node cause an issue when replying to the base station on the RX line, the TX line will still function correctly for sending heartbeats to all the other lights. RS-422 transceivers are relatively cheap and correctly disconnect themselves from the bus via a tristate buffer when they are unpowered solving the major issue we had with I²C. By using a circuit called a bias-tee (image from wikipedia) power can also be injected onto the signal lines without interfering with the data. This will allow the lights to still function when unplugged from laptops

The second upgrade the system is undergoing is switching from using NRF24L01 modules to using WiFi. The base station is being replaced with a Raspberry Pi Zero-W and will act as WiFi hotspot. The robots will then use a ESP8266 to connect to the base station. This provides multiple advantages:

• The Raspberry Pi can be be connected to a projector to display the bus status, eventually a web based user interface will be created to manage the network and to show its status. Showing which lights are missing, and which are not responding as expected etc.
• The base station can now be written in python, and by using asyncio it can be made to allow multiple "processes" (actually co-routines) to share access to a single bus. This system can easily be used to extend the base station functionality without needing to compile and flash binaries to a microcontroller.
• The base station software can now be easily tested without  any hardware since it uses a HTTP REST API for the robots and this can be accessed from any computer. The traffic lights can also be simulated in software.
• The robot circuitry is now simpler, instead of a atmel MCU and an NRF radio module, just the ESP8266 is needed. This also lowers the cost.

This improved traffic light system will soon be complete and get its own project here on hackaday.io so stay tuned!

What is a line following robot and how does it work?

As you might have already guessed, a line follower is a robot that follows a marked line. In this project the goal will be to design a robot that can navigate a track with multiple turns made from black electrical tape. The way the robot will be able to detect its position relative to the 
via an array of 3-5 Infrared (IR) reflectance sensors. These sensors consist of two parts, an IR 
an IR photodiode. The LED emits light, which is then reflected by the surface into the photodiode:

Depending on the colour of the surface the amount of light reflected will vary. In our case we will be using a white surface with a black line. As can be seen in the previous diagram, the black surface absorbs all the IR light while the white reflects it all. The photodiode will produce a current proportional to the amount of IR light it receives. Using this we can build the following circuit  (D1 = IR LED, D2 = IR Phototransistor) to detect whether the sensor is above a white or black surface:

While ideally the black line will absorb all IR emitted by the LED, in reality this isn’t the case. The
reflected IR and ambient light will mean that the sensor will output a small amount of current even on the black line. 

The minimum number of sensors needed to successfully follow a line is two. One on either side of the track (you can get away with one sensor but its unreliable). Using two sensors tends to lead to a lot of wobbling so it is recommended to use three, one on the line and one either side.

Once you have an array of sensors you can then steer the robot based on how much light each one receives.

Programming tutorial

The above text is an excerpt from the provided worksheet which is attached to this project, or can be found here. This worksheet will take you through how to program a line following robot even if you have no programming experience. It teaches: how to use the arduino software; how to use the analog and digital pins on an arduino; how conditional statements work; and how to install and use the adafruit motor shield library.

The history of E.R.N.I.E, from left to right: The first version that was produced for the headstart event, The fully reusable version of ERNIE that is available on github, The future improved ERNIE that features a caster for the rear wheel as well a platform to mount extra electronics.

E.R.N.I.E v1 - The past

The first version of E.R.N.I.E was produced in a week for the first headstart event at the University of Surrey. Five units were produced, one completed unit for demonstration and 4 kits for students to assemble. It was made out of wood due to that being the only material on hand and meant we would make any last minute modifications if necessary. The pieces were hot glued together making the chassis very robust but could not be disassembled for future classes. The sensor bars for this version of E.R.N.I.E were created on stripboard, which caused many problems for students who were soldering for the first time. In this version of the chassis the motors are held on with zip ties! The wheels need to be drilled to allow them to fit directly onto the motors and the large dowel. The rear wheel had too much traction and had to be wrapped in electrical tape to allow it to slide.

E.R.N.I.E v2 - The present

For the following year, more E.R.N.I.Es were required, this time eight kits were needed. For this second run of E.R.N.I.Es some improvements were made. The chassis is now made of acrylic as it has a more professional look and no longer requires glue for assembly. Using the same method as the MeArm, T slots are used to hold captive nuts in the acrylic such that it can be screwed together and taken apart again. This includes proper screw mounts for the motors. The rear axel is now metal, and appropriately sized, unfortunately tape is still required to allow the robot to turn. There is now also a slot for a front mounted servo with the intention of using it together with a ultrasonic distance sensor for obstacle avoidance in a future class. Due to the problems caused by the strip board sensor bar, a proper PCB was created for this version. 5 sensor bars were panelised onto a 10cm x 10cm PCB this resulted in a final price of only £0.45 each.

This version of the chassis is what is currently available for download and has been very well tested over several year. The sensor bars work very reliably and the chassis is extremely rigid with the sensor bar holders being the only exception. Around 20 of units of this design have been build.

E.R.N.I.E v3 - The future

Driven by the desire to sell E.R.N.I.E kits, v3 is currently in the work. Taking the lesson learnt from the previous two iterations the following improvements are being implemented:

• Rear caster - In order to remove the reliance on tape to make the rear wheel slide, v3 will feature a caster style wheel. The caster as shown above does not function particularly well. It does not turn properly and has a significant wobble, this requires further development.
• Optional platform - v2 of the chassis had very limited scope for use outside of line following due to a lack of space to mount any other electronics. To solve this in v3, there is now an optional platform that can be installed above where the battery lives.
• Sensor bar holders  - The major problem with v2 is that the sensor bar holders snap easily. To solve this in v3 the sensor bar will be redesigned with two screw holes and the new holders will attach to it in the same manner the motor mounts do.
• Axel  - A new method needs to be devised for retaining the rear axel that does not involve electrical tape. O-rings are a potential candidate for this, but this has yet to be explored.
• Servo - A notch has been added to the servo mount to prevent damage to the wires when installing it.