Writing a simple Android app: 1. Background and Environment Setup

STEM Speed Ramp

The STEM Speed Ramp


As part of the Siemens commitment to supporting local schools, some of the guys and gals in engineering have been working on a project for the national STEM education programme. For those of you who don’t know, STEM stands for Science Technology Engineering and Mathematics and is designed to encourage young people in the UK into these professions (see http://www.nationalstemcentre.org.uk/stem-in-context/what-is-stem).

The project involved creating a ramp that toy cars could run down, their speed detected by a loop detector. This is exactly the same as can be found in real roads and if you look closely at roads and motorways next time you’re in a car you’ll notice where the slots that contain the loops have been cut into the tarmac. By varying the distance up the ramp that the car is released, the speed of the vehicle can be changed as it goes over the detector. The ramp then measures this speed and if the car is travelling below the ‘speed limit’ it lights up a smiley face and if it is travelling above the speed limit, it lights up a red unhappy face and drops a squash ball onto the vehicle (as you do!).

The students have workbooks which lead them through various challenges such as configuring jumpers on the boards and assembling a few of the components. They must also perform some of the calculations required to make the ramp work correctly and then send the results to the ramp.

This is where the Android app comes in. The ramp includes a serial to WiFi module and the firmware which runs on an STM32 board, provides a simple command line interface to support the configuration data entry.

In order to configure the ramp, the Android app simply needs to collect the data, turn it into a set of text commands and send them down a socket to the WiFi module which will convert it into a serial connection and pass it to the STM32 board firmware.

Before starting on the app coding, the ramp firmware engineer and I sat down and decided on these parameters and how they’ll be sent and I was also provided with a document which described in detail how the screens need to be constructed and what configuration data must be captured and sent. The specification included a splash screen, the artwork for which was to be provided by an external design agency.

Configurator screen specifications

Part of the configurator screen specifications

The ramp configuration protocol

The protocol we settled on is completely text based with and end of line marker of either carriage return or line feed. This was done to enable independent testing and setup of the ramp using Telnet should the app not be available for some reason.

When the Android app first makes the connection, it sends a carriage return to the device. All lines sent to the ramp receive a prompt in reply which is simply:


Configuration is carried out by sending each parameter one at a time in the following way:


followed by a carriage return or line feed.

The following parameters can be specified:

Parameter Description Min Value Max Value
HEADWAY The distance between the loops in mm 1 9,999
DISTCONV Distance conversion from mm to miles 1 9,999,999
TIMECONV Time conversion seconds to hours 1 99,999
CARSCALE Car scale (1:x) 1 999
GRAVITY Acceleration constant of gravity (m/s2) 0.01 999
DROPTIME Ball drop time to impact (ms) 1 9,999
CARACCEL The expected acceleration of the car (m/s2) 0.01 999
SPEEDDISPLAY The length of time the speed display should be left on in seconds. 0.1 99
SPEEDLIMITTHRESH Speed limit in miles per hour 1 99
SIMPAUSE The pause time between simulated runs in demo mode. 0.1 99

Table 1: STEM Ramp Parameters

A conversation between the app and the ramp to set the headway and distance conversion therefore might therefore go something like this with the app starting things off with a couple of carriage returns to make sure everything is ok:


Getting the development environment set up

My Android development environment

My Android development environment

In order to get this going, the team provided me with the target Android device. It’s not a particularly great one I have to admit. It has a resistive touch screen and runs Android 2.3.3 so it’s not very sophisticated. I have managed to convince them to look for something a bit better though so there should be a much better device available fairly soon. In the meantime though I’ll work with what we already have.

Having first connected the device to my laptop using the world’s shortest, but unfortunately all that was available, USB cable, I started by opening up Eclipse (I’m using Juno) and creating a new workspace for the project which I called ‘stem ramp’.

New Workspace Dialog

Creating the new workspace

The next thing is to get hold of the Android SDK which you can do from here: http://developer.android.com/sdk/index.html

If you don’t already have Eclipse, it looks like you can download it from the Android site and it’ll have the Android developer tools already packaged in it. Nice. Anyhow, for me I had to do it in the slightly more long-winded way by downloading the zip file containing the tools and extracting it to a local directory. Following the online instructions I then went on to install the Eclipse plug in (http://developer.android.com/sdk/installing/installing-adt.html).

Once that is done, you have to configure the Eclipse tools to point at the Android SDK that was downloaded and extracted earlier. You do this by restarting Eclipse and doing the following:

1. In the “Welcome to Android Development” window that appears, select Use existing SDKs.

2. Browse and select the location of the Android SDK directory you recently downloaded and unpacked.

3. Click Next.

Next I created the Android project through the New-> AWS Android Project menu. I selected a target of Android 2.3.3, named the project ‘STEM Ram Configurator’ and set the namespace to com.siemens.stem.

Having created the project, the next thing I did was to set up the device for debugging using the instructions found here: http://developer.android.com/tools/device.html and gave it a try. I had a bit of trouble which turned out to be a broken USB cable but after replacing it, everything seemed ok.

The other thing I had to do on my Mac was to add the path to the platform-tools directory to the PATH in my .profile file. The easiest way to do this is to open a new terminal window and run the command:

open -a TextEdit .profile

This opens TextEdit with the .profile file loaded. Add in the following line somewhere replacing the placeholder with the path to your SDK installation folder:

# Add in Android tools
export PATH="/[PATH TO ANDROID SDK]/platform-tools":$PATH

You might be prompted to ‘unlock’ the file as you do this, just go with it. What this does is allow you to use the command line tools for accessing and controlling your Android device from a terminal on your development machine. To try it, open a new terminal window and type in:

adb devices

You should see your connected Andoid device listed in response.

In the next post I’ll describe how I went about creating the structure of the app and laying out the screen. If you’d like to go straight to the source code, I’ve uploaded it to GitHub and it can be found here: https://github.com/jpmasters/stem-ramp-configurator


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: