Build an Automated Vehicle Locator

Several things inspired Electrical and Computer Engineering Professor Chris Coulston and his team at Penn State Erie, The Behrend College, to create an online vehicle-tracking system. Mainly, the team wanted to increase ridership on a shuttle bus the local transit authority provided to serve the expanding campus. Not enough students were “on board,” in part because it was difficult to know when the bus would be arriving at each stop.

So Coulston’s team created a system in which a mobile GPS tracker on the bus communicates its location over a radio link to a base station. Students, professors, or anyone else carrying a smartphone can call up the bus tracker web page, find out the bus’ current location, and receive reliable estimates of the bus’ arrival time at each of its stops. Coulston, computer engineering student Daniel Hankewycz, and computer science student Austin Kelleher wrote an article about the system, which appears in our June issue.

Circuit Cellar recently asked Coulston if the system, implemented in the fall 2013 semester, had accomplished its goals and might be expanded.

“The bus tracker team is tracking usage of the web site using Google Analytics,” Coulston said. “The data reveals that we get on average 100 hits a day during cold weather and fewer on warmer days. Ridership has increased during this past year, helping assure the long-term presence of the shuttle on our campus.”

“Over winter break, shuttle service was increased to a distant location on campus,” he added. “In order to better track the location of the shuttle, a second base station was added. The additional base station required a significant rework of the software architecture. The result is that the software is more modular and can accept an arbitrary number of base stations. There are no plans at present to add a second bus—a good thing, because this change would require another significant rework of the software architecture.”

Initially, Coulston looked to other real-time vehicle trackers for inspiration: “There are a variety of live bus trackers that motivated my early ideas, including the University of Utah’s Live Tracker  and the Chicago Transit Authority’s CTA Bus Tracker. Given our single bus route on campus, I was motivated to keep the interface simple and clean to minimize the amount of time needed to figure out where the bus is and how long it’s going to take to get to my stop.”

The system, as it was originally implemented in August 2013, is fully described in the June issue, now available for single-issue purchase or membership download. The following article excerpt provides a broad overview and a description of the team’s hardware choices.

THE BIG PICTURE
Figure 1 shows the bus tracker’s hardware, which consists of three components: the user’s smartphone, the base station placed at a fixed location on campus, and the mobile tracker that rides around on the bus.

The bus tracking system includes a Digi International XTend radio, a Microchip Technology PIC18F26K22 microcontroller, and a Raspberry Pi single-board computer.

Figure 1: The bus tracking system includes a Digi International XTend radio, a Microchip Technology PIC18F26K22 microcontroller, and a Raspberry Pi single-board computer.

Early on, we decided against a cellular-based solution (think cell phone) as the mobile tracker. While this concept would have benefited from wide-ranging cellular coverage, it would have incurred monthly cellar network access fees. Figure 1 shows the final concept, which utilizes a 900-MHz radio link between the mobile tracker and the base station.

Figure 2 shows the software architecture running on the hardware from Figure 1. When the user’s smartphone loads the bus tracker webpage, the JavaScript on the page instructs the user’s web browser to use the Google Maps JavaScript API to load the campus map. The smartphone also makes an XMLHttpRequests request for a file on the server (stamp.txt) containing the bus’ current location and breadcrumb index.

Figure 2: The bus tracker’s software architecture includes a GPS, the mobile tracker, a smartphone, and the base station.

Figure 2: The bus tracker’s software architecture includes a GPS, the mobile tracker, a smartphone, and the base station.

This information along with data about the bus stops is used to position the bus icon on the map, determine the bus’ next stop, and predict the bus’ arrival time at each of the seven bus stops. The bus’ location contained in stamp.txt is generated by a GPS receiver (EM-408) in the form of an NMEA string. This string is sent to a microcontroller and then parsed. When the microcontroller receives a request for the bus’ location, it formats a message and sends it over the 900-MHz radio link. The base station compares the bus position against a canonical tour of campus (breadcrumb) and writes the best match to stamp.txt.

Early in the project development, we decided to collect the bus’ position and heading information at 2-s intervals during the bus’ campus tour. This collection of strings is called “breadcrumbs” because, like the breadcrumbs dropped by Hansel and Gretel in the eponymously named story, we hope they will help us find our way around campus. Figure 3 shows a set of breadcrumbs (b1 through b10), which were collected as the bus traveled out and back along the same road.

Figure 3: Breadcrumbs (b1 through b10) containing the bus’ position and orientation information were taken every 2 s during a test-run campus tour.

Figure 3: Breadcrumbs (b1 through b10) containing the bus’ position and orientation information were taken every 2 s during a test-run campus tour.

The decision to collect breadcrumbs proved fortuitous as they serve an important role in each of the three hardware components shown in Figure 1.

MOBILE TRACKER
The bus houses the mobile tracker (see Photo 1). Figure 4 shows the schematic, which is deceptively simple. What you see is the third iteration of the mobile tracker hardware.

Figure 4: The mobile tracker includes a Microchip Technology PIC18F26K22 microcontroller, a Micrel MIC5205 regulator, a Digi International XTend RF module, and a Texas Instruments TXS0102 bidirectional translator

Figure 4: The mobile tracker includes a Microchip Technology PIC18F26K22 microcontroller, a Micrel MIC5205 regulator, a Digi International XTend RF module, and a Texas Instruments TXS0102 bidirectional translator

An important starting point in the design was how to step down the bus’ 12-V supply to the 5-V required by our circuit. In terms of hardware, the best decision we made was to abandon the idea of trying to integrate a 12-to-5-V converter onto the mobile tracker PCB. Instead we purchased a $40 CUI VYB15W-T DC-DC converter and fed the mobile tracker 5-V inputs…

We used Micrel’s MIC5205 regulator to step down the 5 V for the 3.3-V GPS receiver, which easily supplied its peak 80 mA. Since we ran a Digi International XTend radio at 5 V for the best range, we ended up with mixed voltage signals. We used a Texas Instruments TXS0102 bidirectional voltage-level translator, which handles voltage-interfacing duties between the 5-V radio and the 3.3-V microcontroller.

The mobile tracker unit

Photo 1: The mobile tracker unit

We selected Microchip Technology’s PIC18F26K22 because it has two hardware serial ports, enabling it to simultaneously communicate with the GPS module and the radio modem when the bus is traveling around campus. We placed two switches in front of the serial ports. One switch toggles between the GPS module and the Microchip Technology PICkit 3 programming pins, which are necessary to program the microcontroller. The second switch toggles between the radio and a header connected to a PC serial port (via a Future Technology Devices FT232 USB-to-serial bridge). This is useful when debugging at your desk. An RGB LED in a compact PLCC4 package provides state information about the mobile tracker.

The XTend RF modules are the big brothers to Digi International’s popular XBee series. These radios come with an impressive 1 W of transmitting power over a 900-MHz frequency, enabling ranges up to a mile in our heavily wooded campus environment. The radios use a standard serial interface requiring three connections: TX, RX, and ground. They are simple to set up. You just drop them into the Command mode, set the module’s source and destination addresses, store this configuration in flash memory, and exit. You never have to deal with them again. Any character sent to the radio appears on the destination modem’s RX line.

The GPS receiver utilizes the CSR SiRFstarIII chipset, which is configured to output a recommended minimum specific (RMC) string every 2 s…

The mobile tracker’s firmware listens for commands over the serial port and generates appropriate replies. Commands are issued by the developer or by the base station…

Burning breadcrumbs into the mobile tracker’s flash memory proved to be a good design decision. With this capability, the mobile tracker can generate a simulated tour of campus while sitting on the lab bench.

BASE STATION
The base station consists of an XTend RF module connected to a Raspberry Pi’s serial port (see Photo 2). The software running on the Raspberry Pi does everything from running an Nginx open-source web server to making requests for data from the mobile tracker.

From Figure 1, the only additional hardware associated with the base station is the 900-MHz XTend radio connected to the Raspberry Pi over a dedicated serial port on pins 8 (TX) and 10 (RX) of the Raspberry Pi’s GPIO header.

The only code that runs on the base station is the Python program, which periodically queries the mobile tracker to get the bus’ position and heading. The program starts by configuring the serial port in the common 9600,8,N,1 mode. Next, the program is put into an infinite loop to query the mobile tracker’s position every 2 s.

Photo 2: The base station includes an interface board, a Raspberry Pi, and a radio modem.

Photo 2: The base station includes an interface board, a Raspberry Pi, and a radio modem.

Two Campuses, Two Problems, Two Solutions

In some ways, Salish Kootenai College (SKC)  based in Pablo, MT, and Penn State Erie, The Behrend College in Erie, PA, couldn’t be more different

SKC, whose main campus is on the Flathead Reservation, is open to all students but primarily serves Native Americans of the Bitterroot Salish, Kootenai, and Pend d’Orellies tribes. It has an enrollment of approximately 1,400. Penn State Erie has roughly 4,300.

But one thing the schools have in common is enterprising employees and students who recognized a problem on their campuses and came up with technical solutions. Al Anderson, IT director at the SKC, and Chris Coulston, head of the Computer Science and Software Engineering department at Penn State Erie, and his team have written articles about their “campus solutions” to be published in upcoming issues of Circuit Cellar.

In the summer of 2012, Anderson and the IT department he supervises direct-wired the SKC dorms and student housing units with fiber and outdoor CAT-5 cable to provide students better  Ethernet service.

The system is designed around the Raspberry Pi device. The Raspberry Pi queries the TMP102 temperature sensor. The Raspberry Pi is queried via the SNMP protocol.

The system is designed around the Raspberry Pi device. The Raspberry Pi queries the TMP102 temperature sensor. The Raspberry Pi is queried via the SNMP protocol.

“Prior to this, students accessed the Internet via a wireless network that provided very poor service.” Anderson says. “We wired 25 housing units, each with a small unmanaged Ethernet switch. These switches are daisy chained in several different paths back to a central switch.”

To maintain the best service, the IT department needed to monitor the system’s links from Intermapper, a simple network management protocol (SNMP) software. Also, the department had to monitor the temperature inside the utility boxes, because their exposure to the sun could cause the switches to get too hot.

This is the final installation of the Raspberry Pi. The clear acrylic case can be seen along with the TMP102 glued below the air hole drilled into the case. A ribbon cable was modified to connect the various pins of the TMP102 to the Raspberry Pi.

This is the final installation of the Raspberry Pi in the SKC system. The clear acrylic case can be seen along with the TMP102 glued below the air hole drilled into the case. A ribbon cable was modified to connect the various pins of the TMP102 to the Raspberry Pi.

“We decided to build our own monitoring system using a Raspberry Pi to gather temperature data and monitor the network,” Anderson says. “We installed a Debian Linux distro on the Raspberry Pi, added an I2C Texas Instruments TMP102 temperature sensor…, wrote a small Python program to get the temperature via I2C and convert it to Fahrenheit, installed SNMP server software on the Raspberry Pi, added a custom SNMP rule to display the temperature from the script, and finally wrote a custom SNMP MIB to access the temperature information as a string and integer.”

Anderson, 49, who has a BS in Computer Science, did all this even as he earned his MS in Computer Science, Networking, and Telecommunications through the Johns Hopkins University Engineering Professionals program.

Anderson’s article covers the SNMP server installation; I2C TMP102 temperature integration; Python temperature monitoring script; SNMP extension rule; and accessing the SNMP Extension via a custom MIB.

“It has worked flawlessly, and made it through the hot summer fine,” Anderson said recently. “We designed it with robustness in mind.”

Meanwhile, Chris Coulston, head of the Computer Science and Software Engineering department at Penn State Erie, and his team noticed that the shuttle bus

The mobile unit to be installed in the bus. bus

The mobile unit to be installed in the bus.

introduced as his school expanded had low ridership. Part of cause was the unpredictable timing of the bus, which has seven regular stops but also picks up students who flag it down.

“In order to address the issues of low ridership, a team of engineering students and faculty constructed an automated vehicle locator (AVL), an application to track the campus shuttle and to provide accurate estimates when the shuttle will arrive at each stop,” Coulston says.

The system’s three main hardware components are a user’s smartphone; a base station on campus; and a mobile tracker that stays on the traveling bus.

The base station consists of an XTend 900 MHz wireless modem connected to a Raspberry Pi, Coulston says. The Pi runs a web server to handle requests from the user’s smart phones. The mobile tracker consists of a GPS receiver, a Microchip Technology PIC 18F26K22 and an XTend 900 MHz wireless modem.

Coulston and his team completed a functional prototype by the time classes started in August. As a result, a student can call up a bus locater web page on his smartphone. The browser can load a map of the campus via the Google Maps JavaScript API, and JavaScript code overlays the bus and bus stops. You can see the bus locater page between 7:40 a.m. to 7 p.m. EST Monday through Friday.

“The system works remarkably well, providing reliable, accurate information about our campus bus,” Coulston says. “Best of all, it does this autonomously, with very little supervision on our part.  It has worked so well, we have received additional funding to add another base station to campus to cover an extended route coming next year.”

The base station for the mobile tracker is a sandwich of Raspberry Pi, interface board, and wireless modem.

The base station for the mobile tracker is a sandwich of Raspberry Pi, interface board, and wireless modem.

And while the system has helped Penn State Erie students make it to class on time, what does Coulston and his team’s article about it offer Circuit Cellar readers?

“This article should appeal to readers because it’s a web-enabled embedded application,” Coulston says. “We plan on providing users with enough information so that they can create their own embedded web applications.”

Look for the article in an upcoming issue. In the meantime, if you have a DIY wireless project you’d like to share with Circuit Cellar, please e-mail editor@circuitcellar.com.

 

 

 

 

One Desk Serves Two Roles for Professor and Designer

Chris Coulston, head of the Computer Science and Software Engineering department at Penn State Erie, The Behrend College, has a broad range of technical interests, including embedded systems, computer graphics algorithms, and sensor design.

Since 2005, he has submitted five articles for publication in Circuit Cellar, on projects and topics ranging from DIY motion-controlled gaming to a design for a “smart” jewelry pendant utilizing RGB LEDs.

We asked him to share photos and a description of the workspace in his Erie, PA, home. His office desk (see Photo 1) has something of an alter ego. When need and invention arise, he reconfigures it into an “embedded workstation.”

Coulston's workspace configured as an office desk

Photo 1: Coulston’s workspace configured as an office desk

When working on my projects, my embedded workstation contains only the essential equipment that I need to complete my project (see Photo 2).  What it lacks in quantity I’ve tried to make up for in quality instrumentation; a Tektronix TDS 3012B oscilloscope, a Fluke 87-V digital multimeter, and a Weller WS40 soldering iron.  While my workstation lacks a function generator and power supply, most of my projects are digital and have modest power requirements.

Coulston can reconfigure his desk into the embedded workstation pictured here.

Photo 2: Coulston can reconfigure his desk into the embedded workstation pictured here.

Coulston says his workspace must function as a “typical office desk” 80 percent of the time and electronics station 20 percent of the time.

It must do this while maintaining some semblance of being presentable—my wife shares a desk in the same space. The foundation of my workstation is a recycled desk with a heavy plywood backing on which I attached shelving. Being a bit clumsy, I’ve tried to screw down anything that could be knocked over—speakers, lights, bulletin board, power strip, cable modem, and routers.

The head of a university department has different needs in a workspace than does an electronics designer. So how does Coulston make his single office desk suffice for both his professional and personal interests? It’s definitely not a messy solution.

My role as department chair and professor means that I spend a lot time grading, writing, and planning. For this work, there is no substitute for uncluttered square footage—getting all the equipment off the working surface. However, when it’s time to play with the circuits, I need to easily reconfigure this space.

I have found organization to be key to successfully realize this goal. Common parts are organized in a parts case, parts for each project are put in their own bag, the active project is stored in the top draw, frequently used tools, jumper wires, and DMM are stored in the next draw. All other equipment is stored in a nearby closet.

I’ve looked at some of the professional-looking workspaces in Circuit Cellar and must admit that I am a bit jealous. However, when it comes to operating under the constraints of a busy professional life, I have found that my reconfigurable space is a practical compromise.

To learn more about Coulston and his technical interests, check out our Member Profile posted earlier this year.

 

Chris Coulston

Chris Coulston