Arduino Frameworks: Shuttle & Fleet

To make the code for this project more readable and flexible, we created two custom frameworks for Arduino. Frameworks in Arduino are essentially just classes in C++. The frameworks created are aptly named Shuttle and Fleet. The Shuttle framework provides a way to create shuttle objects in our code and is the heart of code in this project. The Fleet framework was created to contain and manage any number of Shuttle objects.


This is where details on the Shuttle framework go.


This is where details on the Fleet framework go.

First Shuttle Test

We began our first real-world testing today. We took the two modules, transmitter and receiver, on-board the SFSU shuttle to monitor their behavior and see if our code worked using the GPS module to trigger checkpoint transmissions. Unfortunately, the test was unsuccessful as only one of the checkpoints was passed.


The unsuccessful test was due to a programming error. We had decided to move the checkpoints around and forgot to update the longitude of the checkpoint’s coordinates in the transmitter code. See our more recent, more successful test.

Testing has begun!

We have finally gotten our project up and running and were able to perform a test run on the SFSU Shuttle today. We setup the receiver just outside the campus shuttle stop. The receiver was connected to a computer to monitor the Arduino’s serial output.

Sans Modem Testing a Success

We tested our transmitter -> receiver code again (see previous test) today by taking the two Arduino modules onto the shuttle. Just as before they were connected using wires for serial transmission as opposed to our Satel Satelline modems; we felt the modems might add too much complexity, as we only wanted to test the modules themselves, not their radio transmission.

The test was mostly a success, with the only hiccup being a missed checkpoint at the Stonestown Mall U-Turn. The ETA’s calculated were fairly accurate, only off by a minute at most.

Bug Squashed: Serial

Talk about the serial ttl bug and the ttl converter pin 2 -> pin 3 bug here…

Demo Video COMPLETE!

The demonstration video is complete! Hopefully this helps explain the project a bit better than just text and images. Enjoy.

A productive 24 hours.


Last week we sat down and decided on an appropriate packet for our on-board modules to transmit to the receivers. More on that here. Once the packet design was completed, we took on the task of writing code to decode the packet.

The first step in developing an optimal decoding method was to determine what we wanted to be able to decode, and what we didn’t. Our packet was designed to handle the occasional “flipped bit” as well as other transmission errors, but we didn’t want to write a decoder that would make something out of nothing (or in this case, too little).

In order for a packet to be received, it must start with the start bit, in our case the bang ‘!’. Anything without that character will be skipped over and assumed to be garbage. When a valid packet is detected, we want to immediately start putting the information being received into two buffers: shuttleID[ ] & checkpointID[ ]

These buffers are filled based on the criteria that a shuttle id is an ASCII number, while a checkpoint ID is an ASCII letter. The packet is assumed to be read once a stop bit (‘#’) is encountered or the maximum packet size has been reached by the contents of these two buffers. Now that the packet is supposedly captured, we need to validate it and turn the multiple values from our packet into a single, correct-valued shuttle id and a single, correct-valued checkpoint id. This is done using a validation method where the character that appears most in the packet is assumed to be the correct character. If multiple characters have the same value, e.g. !AABB1122#, the validator is left associative and the shuttle id would be A, the checkpoint id 1. When the decoder code was completed we tested via serial communication simulating possible real-world scenarios, with expected, reliable results.

ETA Algorithms

Figuring out a suitable method of determining the shuttle’s ETA with the information that the STaR System provides plays a major role in the success of the project. While it is much too early to decide which computation method works best, we have gone through some testing using spreadsheets and estimated timing data and decided on a preliminary algorithm. The algorithm works by taking average times to each checkpoint and modifying them based on the actual time it takes the shuttle to pass to each checkpoint. More can be read about a similar algorithm here.

Web App

After crunching some numbers through the ETA algorithm, we switched focus to researching a web interface to display our ETA. This involved researching server-side applications and the easiest methods of sending data from a microcontroller to a webpage. This is currently being beta tested and expected to be completed very soon, which will give us much more flexibility for testing the system, as we won’t have to rely on attaching a screen to our modules quite yet.

Site is live!

Just a skeleton for now, but stay tuned!