ECE497 Project Rover
Embedded Linux Class by Mark A. Yoder
Team members: Ross Hansen, Jesse Brannon, Michael Junge
This project is a BeagleBone implementation of a ground-based rover platform. Through a BeagleBone mounted on an RC car, the car can be directed to turn to a specified compass heading or move forward. A user is able to control the car with predefined movement code or in real-time over WiFi. The BeagleBone can also send back helpful information to the user over Wifi, such as GPS location and compass heading. Although not complete, functionality to direct the rover along a path by defining waypoints is currently in development.
This work provides highly useful code even for applications outside of this specific rover project - digital compass and GPS sensor interfacing, Python-based networking, and RC car motor control code is all written and easily extendable into other applications. Additionally, the work performed for this project in the area of RC car reverse engineering and BeagleBone USB Wi-Fi can serve as useful community knowledge for other projects.
We bought an RC car from Toys 'R Us and modified it to become an intelligent platform by utilizing a BeagleBone. To successfully recreate our work, certain skills will be helpful: dremel-based hardware modification, soldering, experience with Beagle Bone or an equivalent embedded processor bases system, familiarity with the Python and C programming languages, and basic circuit knowledge such as power regulation from batteries.
Modifying RC Truck/Car
As shown in Figure 1, we removed the aesthetic cover form the truck. We also cut out most of the plastic with a Dremel tool. We did this to expose the circuity below. Cutting out most of the plastic is necessary unless you are skilled enough to drill only a small hole to feed the wires through and can replace the circuit board back into place without viewing it. Figure 1 also shows, four screw slots. In order to obtain access to the circuity, you must remove the screws from their sockets. Now turn the truck so that it's undercarriage is facing up, remove the housing unit of the battery. The battery unit should be loose and thus be removed since you already removed the four place holder screws. Be careful though to not pullout or detach any wires from the their respected places as you are pulling out the circuit board. Figure 2 shows the circuit board removed from it's housing with the wires exposed. The red and black wires you see are respectively power and ground, the same for all electrical work.
Figure 3 is focused on the specific connections that we soldered to the board. We choose the top left corner (where three of the connections are) because when we reverse engineered the board, this area is where the wireless signals are received and sent to the motor controllers. The fourth wire was supposed to be the pin on the right but as you can see by the picture, the circuit pad is burned off. We just followed the hard trace and soldered at the next available node. After testing, this improvised step seemed suitable for our needs. The same four pins are labeled on the circuit board as F,W,L,R. Originally, we thought these meant forward, backward, left and right. However the RC Truck is designed with tank steering so in order to go forward it theoretically should require two separate signals. We tested this theory and found out that it did in fact require two signals, thus the F,W,L,R labels are incorrect. The pins attach to relays on each motor, and correspond to "right forward", "right backward", "left forward", and "left backward", and are digital control signals. Therefore, in order to turn left you would drive the "right backward" and "left forward" pins high. Fortunately, motor conflicts are not destructive and exact pin mappings can be determined by experimentation - if you mistakenly drive the "right forward" and "right backward" pins high, for instance, the relay will click and the motors will not move, without any damage to the motors or electronics.
If you want to reverse engineer this circuit board for yourself instead of just following this guide, you will need a separate 5V dc power supply as well as the 9V battery that was included, a 5V wall adapter with stripped wires will be suffient for the extra power supply. Then you should look for the wireless adapter board. Most RC electronics will have a separate wireless circuit board. Ours happened to be already physically attached to the motor controllers. Find the output signals from the wireless adapter and test which signals control which motors and direction of motors. To test this just attach the 5V to the pin on the circuit board while the truck battery is installed and switched on. Also you will need to find a ground wire to attach for common ground. We just soldered directly to the terminal on the installed battery for our ground.
After several problems with the WiFi on the BeagleBone not working as expected, we decided to overwrite our Angstrom Beagle Image with Ubuntu. To install Ubuntu, we simply followed this Instructable up to and including Step 6. There is also good information on the BeagleBoardUbuntu page on elinux.org.
However, if you want to pursue the Angstrom route then I would suggest reading Dr. Yoder's Out of The Box, Bone. Note: If you want WiFi to work properly, install the A5 image not the A6 image.
Whether you use the Angstrom image or Ubuntu is up to you. However, you will still need to wire the BeagleBone up so that it runs off of battery power. We bought a 7.4 Vdc 10400 mAh battery. Since the BeagleBone runs off of 5V with a possible peak current of 1.5 amps we needed a 5V regulator that can supply that power voltage regulator. To be safe and avoid short-circuiting the BeagleBone, it is advisable to buy a barrel connector for proper power connection. This barrel connector replaces the need to solder wires to the hardware of the BeagleBone, thus allowing for us to safely supply power the way the BeagleBone was designed. As seen in Figure 4, the barrel connector, battery and voltage regulator with heat sink can be seen. Figure 5 is our Regulator circuit. It shows how to connect the regulator to the rest of the BeagleBone hardware.
Note: We specifically used a BeagleBone for it's smaller size and less cost due to less capabilities. However, you could use any board that has an Omap processor, such as the Beagle XM Board.
Connecting to WiFi is an important part of our project. We intended this project to receive data from a user on a mobile laptop. We decided to use WiFi to avoid following the RC truck around a field with the laptop in our hands. WiFi helps the user stay in the same place while the RC truck moves around the field. We ordered an Adafruit WiFi adapter that Adafruit specifically sponsors for the BeagleBone. They also have an install tutorial. After several days of researching WiFi capabilities for the BeagleBone, we continually ran into many difficulties. One of the many difficulties is with 'opkg upgrade' that Adafruit says to run. DO NOT RUN 'opkg upgrade'. Depending on what software image you are running, you will receive an error that for some reason cannot be resolved. There are many reported cases on Adafruit's help forums. There are also several more reported cases for the BeagleBone group on google groups. After researching and WiFi experimentation we discovered that the Adafruit WiFi adapter works well on the A6 version of the BeagleBone hardware while running A5 version of Angstrom. This is the only valid combination we could find. The A5 hardware shows and detects the adapter, but for some reason the adapter does not connect to a wireless router. When the same SD card is plugged into an A6 hardware, it connects fine without issue to a router. We also noticed that the A6 software image does not even recognize the BeagleBone following the same procedure as for the A5 software.
Because of the difficulties, we decided to not use the Angstrom images supported by Beagle. We instead installed Ubuntu Operating system on our A6 hardware. With Ubuntu installed it was as easy as plug and play. All we did after installing Ubuntu was to physically plug in the adapter and it was recognized immediately. However, if you want to stay with Angstrom I would suggest following the directions in ECE497 Beagle Bone WiFi.
The code for the platform can be found on the BeagleRover Github Page and Github Repository.
A Makefile is provided, and the code can be compiled with the command "make" in the root directory of the project; this will build a main binary movement and shared libraries for movement control over WiFi.
See the README for detailed instructions on installation and documentation of the code structure.
Required Parts List
1 x RC Truck
1 x BeagleBoard (could be Bone/XM/Board)
1 x Battery
1 x Barrel Connector
1 x GPS
1 x Compass
1 x BreadBoard
The rover is designed for two different operating modes.
- Stand-alone control and navigation
- Remote operation over Wi-Fi via Python
The README file on the software Github Page includes details about running the software for each of these modes. For stand-alone operation, the compiled binary movement can be executed to run commands such as moving forward or turning to a specific heading. For remote operation, Python scripts are provided to setup a server/client interface to communicate with the BeagleBone. When communicating with the Bone over Wi-Fi, the Python script presents the user with options of what to send to the BeagleBone.
Selection: 1: FWD 2: BCK 3: TURN 4: COMPASS QUERY 5: GPS QUERY 9: EXIT
The user then inputs the selection number, and an option if necessary. For instance, the option for sending a "FWD" command is the duration in microseconds, while the option for a "TURN" command is the heading relative to magnetic north. FWD, TURN, COMPASS QUERY, and GPS QUERY are all implemented and functional, but BCK is currently unimplmented; the code is simple and implementation would be trivial, but for the end application of this software (emulating UAV movements) it was unnecessary.
Upon sending the command, the BeagleBone will return feedback to the user over Wi-Fi. In the case of a movement command it will return that the command was executed successfully, and if a sensor was queried it will return the result. The Python script will then prompt the user for another command to send.
In the video we demonstrate how to set up the wireless server/client communication and the functionality present over the network interface, including sensor queries and movement commands. Although these movements are accomplished over Wi-Fi, they can also be programmed for stand-alone operation. The jerky turning and vigorous stopping that the car displays in the video is due to the high traction of the tires on the track surface - reducing the traction on the tires would eliminate this.
Theory of Operation
The BeagleBone is connected to the RC car via 4 GPIO pins and a ground wire. The four GPIO pins control left forward, left reverse, right forward, and right reverse on the tank-style drive base. Tank-style means that each side is controlled independently, as opposed to a standard steering where the user controls whether the car as a whole is moving forward or reverse and turns are accomplished by rotating the front axle. Figure 6 shows how the GPIO pins on BeagleBone are connected to the motor control PCB. As seen in Figure 4 the motor control wires are white. The GPIO pins are the two orange and two yellow wires labeled in the figure.
Seems like you need a PWM control so the motors can run slower.
The Motor Control pin layout is listed below. These are defined in movement.c, and can be redefined easily to match a different pin configuration. These pins are connected to relays on the RC car, so the motors are either on or off.
Motor Control BeagleBone Pin Right Forward 40 - P8 header (software sysfs GPIO 77) Right Reverse 44 - P8 header (software sysfs GPIO 73) Left Forward 42 - P8 header (software sysfs GPIO 75) Left Reverse 46 - P8 header (software sysfs GPIO 71)
WiFi is achieved with Adafruit's USB WiFi Module. The USB WiFi Module is connected to the only usb port on the BeagleBone.
Figure 7 is the BeagleBone P9 Header layout and provides a good reference in knowing which pins in the header connect to pins on the BeagleBone. Figure 8 shows how the pins for the gps and compass are connected to the P9 header. Figure 9 shows where the Compass, GPS and WiFi module are mounted. We had to mount them outside of the box because placing them inside of the wooden box attenuated the signals excessively.
The GPS is connected to the BeagleBone over UART serial. The GPS pin layout is as follows:
GPS BeagleBone Pin 1 - TX 24 - P9 header 2 - RX 26 - P9 header 3 - GND 1 or 2 - P9 header 4 - 3.3 V 3 or 4 - P9 header 5 - NC 6 - NC
Over UART, the GPS sends back 6 strings in NMEA format every second. Each of these 6 strings includes some or all of the following data: Latitude, Longitude, if the GPS has a fix, UTC time, and some other data that we don't need. For more information, read the GPS' datasheet. We chose to parse the string that starts with "$GPGLL" because it included all of the information we need listed previously.
The format for the $GPGLL string is:
$GPGLL,Latitude,N/S,Longitude,E/W,UTC time,Fix Status,Mode Indicator,Checksum
This is what the $GPGLL string looks like when the GPS does not have a fix.
We know the GPS doesn't have a fix, because of the 'V.' The second to last comma-delimited item will be 'V' when there is no fix and 'A' when there is a fix. Also, the Latitude and Longitude fields are left blank when there is no fix, as shown.
The compass is connected to the BeagleBone via I2C. The Compass pin layout is as follows:
Compass BeagleBone Pin 1 - GND 1 or 2 - P9 Header 2 - 3.3 V 3 or 4 - P9 Header 3 - I2C SDA 20 - P9 Header 4 - I2C SCL 19 - P9 Header
The compass simply returns the current heading at a default rate of 20 Hz.
All hardware interfacing is accomplished in C, using the standard interfaces for each protocol. Motor control is done via GPIO, the compass is I2C, and the GPS is UART. Compass interfacing is provided in a compass library Compass/compass.c, GPS interfacing is provided in a GPS library GPSLibs/gps.c, and the motor control is provided in movement.c. Waypoint storage and helper functions are provided in a library in Waypoints/waypoint.c.
For stand-alone operation, movement.c is compiled with the necessary libraries as a stand-alone binary.
For network operation, the Python scripts utilize compiled libraries in sharedLibs. Currently, due to the structure of how the sensors are interfaced in the movement library, all interfacing is accomplished through a library movementLib.so, which provides wrapper functions to the GPS and Compass. In the future, this functionality should be better divided out into each individual sub-library. This interfacing between Python and C is done with Python CTypes. The BeagleBone and base station communicate over Wi-Fi using TCP sockets via the Python Socket and SocketServer modules. All of these Python modules, ctypes, socket, and SocketServer, are standard in Python 2.7.
A summary of the major development areas and the primary contributor(s) to each subsystem:
- RC car hardware interfacing and mounting: Michael Junge
- Power subsystem development: Michael Junge
- Wireless communication hardware: Michael Junge, Jesse Brannon
- GPS and Compass sensor interfacing: Jesse Brannon
- Movement and navigation software development: Jesse Brannon, Ross Hansen
- Network communication software development: Ross Hansen
Tasks completed and in development by each team member:
- Constructed hardware interfaces to compass sensor and drive base electronics
- Investigated WiFi issues on Angstrom - determined that the Angstrom A5 image on BeagleBone A6 hardware is a known working configuration **still under invesgitation, won't be fully completed due to hardware/software issues between Angstrom and Beagle
- Soldered and interfaced battery subsystem to power BeagleBone
- Decided and installed an Ubuntu image instead of Anstrom specifically for the WiFi functionally
- Researched and purchased compass and GPS sensors
- Wrote libraries to interface to compass and GPS sensor
- Co-developed movement and navigation software
- Co-developed movement and navigation software
- Developed software for network communication
Although full rover functionality for movement and sensor data retrieval was completed, two additional features were currently in development at the end of the original timeframe of this project.
1) Code to manage waypoints and drive the motors based off of waypoint inputs
2) Improve GPS library to allow for update rate configuration
These two features were not necessary for this project, but are useful for a sister project in development by the same team; so development will continue on these two tasks. The code in the BeagleRover repository will be updated with final versions of the code as it is completed.
This project has the possibility to branch into several interesting areas.
- The BeagleBone platform has the processing power for various interesting sensory systems, such as computer vision. The RC car interface and networking platform allows for a variety of interesting applications of sensor systems, where driving decisions are made based off of sensor inputs or sensor data is relayed remotely back to a powerful processing node.
- A GUI is being developed that could be used to send commands to control the rover. Work on it can be seen here: ECE497_Project_RoverGUI
- This project is a two-dimensional navigation system for a ground-based rover, but could be extended for use on aerial vehicles. Additional requirements for this would include some sort of altimeter sensor interface, modification of control outputs to accommodate aerial control surfaces, and an addition of a third dimension to location and navigation code.
BeagleRover is a functioning implementation of a rover intelligence platform for the BeagleBone. When mounted on an RC car, the BeagleBone can direct the car motors to move around and it can relay GPS and compass data across a Wi-Fi network.
This project was highly interesting and enjoyable to work on. It incorporated a wide range of skills fundamental to embedded systems - hardware, sensor interfacing via multiple protocols, and both high and low-level software development. Although a complete project in its current status, even more exciting is the possibility for extension in the future; the basic system of network functionality, location and heading sensor data, and mobility provide an interesting platform for lots of different embedded work. Combined with the versatility of Linux running on the BeagleBone, this project provides an interesting application of the BeagleBone's potential and a flexible platform for future development.
Embedded Linux Class by Mark A. Yoder