ATDD with Lego Mindstorms EV3

We have been building automated acceptance tests using web browsers, mobile devices and web services for several years now. Last week Erik Zeedijk and I came up with the (crazy) idea to implement features for a robot using ATDD. In this blog we will explain how we used ATDD while experimenting with Lego Mindstorms EV3.

What are we building?

When you practice ATDD it is really important to have a common understanding about what you need to build and test. So we had several conversations about requirements and specifications.

We wanted to build a robot that could help us clean up post-its from tables or floors after brainstorms and other sticky note related sessions. For our first iteration we decided to experiment with moving the robot and using the color scanner. The robot should search for yellow post-it notes all by itself. No manual interactions because we hate manual work. After the conversation we wrote down the following acceptance criteria to scope our development activities:

• The robot needs to move his way on a white square board
• The robot needs to turn away from the edges of the square board
• The robot needs to stop a yellow post-it

We used Cucumber to write down the features and acceptance test scenarios like:

<br /> Feature: Move robot<br /> Scenario: Robot turns when a purple line is detected<br /> When the robot is moving and encounters a purple line<br /> Then the robot turns left<br />

Scenario: Robot stops moving when yellow post-it detected<br /> When the robot is moving and encounters yellow post-it<br /> Then the robot stops<br />

Just enough information to start rocking with the robot! Ready? Yes! Tests? Yes! Lets go!

How did we build it?

First we played around with the Lego Mindstorms EV3 programming software (4GL tool). We could easily build the application by click our way through the conditions, loops and color detections.

But we couldn’t find a way to hook up our Acceptance Tests. So we decided to look for programming languages. First hit was the leJOS. It comes with a custom firmware which you install on a SD card. This firmware allows you to run Java on the Lego EV3 brick.

Installing the firmware on the EV3 Brick

The EV3 main computer “Brick” is actually pretty powerful.

It has a 300mhz ARM processor with 64MB RAM and takes micro SD cards for storage.
It also has Bluetooth and Wi-Fi making it possible to wirelessly connect to it and load programs on it.

There are several custom firmware’s you can run on the EV3 Brick. The LeJOS firmware allows us to do just that where we can program in Java with having access to a specialized API created for the EV3 Brick. Install it by following these steps:

1. Download the latest firmware on sourceforge: https://sourceforge.net/projects/ev3.lejos.p/files/
2. Get a blank SD card (2GB – 32GB, SDXC not supported) and format this card to FAT32.
3. Unzip the ‘lejosimage.zip’ file from the leJOS home directory to the root directory of the SD card.
4. Download Java for Lego Mindstorms EV3 from the Oracle website: https://java.com/legomindstorms
5. Copy the downloaded ‘Oracle JRE.tar.gz’ file to the root of the SD card.
6. Safely remove the SD card from your computer, insert it into the EV3 Brick and boot the EV3. The first boot will take approximately 8 minutes while it created the needed partitions for the EV3 Brick to work.

ATDD with Cucumber

Cucumber helped us creating scenarios in an human readable language. We created the Step Definitions to glue it all the automation together and used the remote access to the EV3 via Java RMI.

We also wrote some support code to help us make the automation code readable and maintainable.

Below you can find an example of the StepDefinition of a Given statement of a scenario.

[java]
@Given(“^the robot is driving$”)
public void the_robot_is_driving() throws Throwable {
Ev3BrickIO.start();
assertThat(Ev3BrickIO.leftMotor.isMoving(), is(true));
assertThat(Ev3BrickIO.rightMotor.isMoving(), is(true));
}
[/java]

Behavior Programming

A robot needs to perform a series of functions. In our case we want to let the robot drive around until he finds a yellow post-it, after which he stops. The obvious way of programming these functions is to make use of several if, then, else statements and loops. This works fine at first, however, as soon as the patterns become more complex the code becomes complex as well since adding new actions can have influence on other actions.

A solution to this problem is Behavior Programming. The concept of this is based around the fact that a robot can only do one action at a time depending on the state he is in. These behaviors are written as separate independent classes controlled by an overall structure so that behavior can be changed or added without touching other behaviors.

The following is important in this concept:

1. One behavior is active at a time and then controls the robot.
2. Each behavior is given a priority. For example; the turn behavior has priority over the drive behavior so that the robot will turn once the color sensor indicates he reaches the edge of the field.
3. Each behavior is a self contained, independent object.
4. The behaviors can decide if they should take control of the robot.
5. Once a behavior becomes active it has a higher priority than any of the other behaviors

Behaviour API and Coding

The Behavior API is fairly easy to understand as it only exists out of one interface and one class. The individual behavior classes build-up is then defined by the overall Behavior interface and the individual behavior classes are controlled by an Arbitrator class that decides which behavior should be the active one. A separate class should be created for each behavior you want the robot to have.

When an Arbitrator object is instantiated, it is given an array of Behavior objects. Once it has these, the start() method is called and it begins arbitrating; deciding which behavior will become active.

In the code example below the Arbitrator is being created where the first two lines create instances of our behaviors. The third line places them into an array, with the lowest priority behavior taking the lowest array index. The fourth line creates the Arbitrator, and the fifth line starts the Arbitration process. One you create more behavior classes these can simply be added to the array in order to be executed by the Arbitrator.

[java]
DriveForward driveForward = new DriveForward();
Behavior stopOnYellow = new StopOnYellow();
behaviorList = new Behavior[]{driveForward, stopOnYellow};
arbitrator = new Arbitrator(behaviorList, true);
arbitrator.start();
[/java]

We will now take a detailed look at one of the behavior classes; DriveForward(). Each of the standard methods is defined. First we create the action() method in which contains what we want the robot to perform when the behavior becomes active. In this case moving the left and the right motor forwards.

[java]
public void action() {
try {
suppressed = false;

Ev3BrickIO.leftMotor.forward();
Ev3BrickIO.rightMotor.forward();
while( !suppressed ) {
Thread.yield();
}

Ev3BrickIO.leftMotor.stop(true);
Ev3BrickIO.rightMotor.stop(true);
} catch (RemoteException e) {
e.printStackTrace();
}
}
[/java]

The suppress() method will stop the action once this is called.

[java]
public void suppress() {
suppressed = true;
}
[/java]

The takeControl() method tells the Arbitrator which behavior should become active. In order to keep the robot moving after having performed more actions we decided to create a global variable to keep track of the fact if the robot is running. While this is the case we simply return ‘true’ from the takeControl() method.

[java]
public boolean takeControl() {
return Ev3BrickIO.running;
}
[/java]

You can find our leJOS EV3 Automation code here.

Test Automation Day

Our robot has the potential to do much more and we have not yet implemented the feature of picking up our post-its! Next week we’ll continue working with the Robot during the Test Automation Day.
Come and visit our booth where you can help us to enable the Lego Mindstorms EV3 Robot to clean-up our sticky mess at the office!

Feel free to use our Test Automation Day €50 discount on the ticket price by using the following code: TAD15-XB50

We hope to see you there!

Qxperts. We empower companies to deliver reliable & high-quality software. Any questions? We are here to help! www.qxperts.io