ECE497 Project Rover
Embedded Linux Class by Mark A. Yoder
I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!
05 Executive Summary 05 Installation Instructions (waiting details) 00 User Instructions 00 Highlights 00 Theory of Operation (Looking forward to more details) 00 Work Breakdown 00 Future Work 00 Conclusions 00 Demo 00 Late Comments: I'm looking forward to seeing this. Score: 10/100
This project is a BeagleBone implementation of a ground-based rover platform. Through a BeagleBone mounted on an RC car, the user will be able to control the car over WiFi - the user can give commands to drive forward, drive backward, turn left, and turn right. The BeagleBone will also send back helpful information to the user over Wifi, such as GPS location and compass heading. Development time permitting, the user will also be able to guide the rover along a path by defining waypoints for movement.
Currently, the project is well underway. The RC car has been acquired and reverse-engineered to gain access to the motor electronics, and the BeagleBone GPIO outputs have been interfaced to allow motor control. A WiFi module has been selected and a procedure has been developed to get it working on the BeagleBone (harder than it seems!). Libraries for the GPS sensor and compass have been written and tested. Code for the network communication to control the BeagleBone over WiFi has been written, and the protocol and libraries currently allow us to type line by line directions to move the rover.
Time permitting and by the end ECE497, the rover may not move autonomously. We are currently working on setting GPS waypoints for the rover to move autonomously so all we have to do is run the program and it will update real-time GPS as it is moving.
When completed, the project will serve as a neat demonstration of the capabilities of the BeagleBone as a robotics platform. The GPIO output, I2C and serial interfaces, WiFi dongle compatibility, and embedded Linux OS of the BeagleBone provide an excellent platform for mobile robotics development.
We bought an RC car from Toys 'R Us and modified it to become an intelligent platform by utilizing a BeagleBone. There are two types of communications with the RC car, commands and queries. An command tells the BeagleBone to move to a different location based on the user input. A query asks the BeagleBone to send data to the user. The data could be either a GPS location or compass heading, depending on what the user asked for. 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. We followed the BeagleBoardUbuntu on elinux.org. Since WiFi is critical to this project, it seemed a better alternative to spending hours working on Angstrom and not really getting anywhere.
However, if you are a true Beagle user and 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.2 11000 mA hours battery (add specs here, website). Since the BeagleBone runs off of 5V with a possible peak current of 1.5 amps we needed a 5V 10 amp voltage regulator (again specs, website) (also add schematic photos). To be safe and avoid short-circuiting the BeagleBone, we decided to buy a barrel connector 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.
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 this, I repeat 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 I 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 I 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. I 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 are a true Beagle user and wants to stay with Angstrom I would suggest following the directions in ECE497 Beagle Bone WiFi.
The work-in-progress code for the platform can be found on the BeagleRover Github Repository.
The rover will be able to be controlled using a simple browser based interface. Additionally, waypoints will be able to be selected in order by clicking on intended location on an Google map interface.
As the code is currently in development, UI details are not finalized. These instructions will be updated.
Here is a youtube.com video of the rover. Ross is recording the video while Jesse is controlling the rover. In the video we spend about a minute talking about how to set up the wireless network and server. Then they show the computer receiving gps and compass data. Then they turn the rover and move to a new location, receive gps and compass data. As expected the data changed and is correct according to Google maps.
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 car where the user controls whether the car as a whole is moving forward or reverse and turns are accomplished by steering. (See Figure 4 in connecting the wires to the PCB) Figure 5 is the pin layout and provides a good reference in knowing which pins in the header connect to what on the BeagleBone. 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.
The Motor Control pin layout is as follows:
Motor Control BeagleBone 1 - P9 header 2 - P9 header 3 - P9 header 4 - P9 header
The GPS pin layout is as follows:
GPS BeagleBone 1 - tx 24 - P9 header 2 - rx 26 - P9 header 3 - gnd 1 or 2 - P9 header 4 - 3.3v 3 or 4 - P9 header 5 - nc 6 - nc
The Compass pin layout is as follows:
The motors are interfaced with GPIO controls in a C library. Movement, waypoint management, and sensor code are all also implemented as C libraries. Data is sent over WiFi to and from the Bone using TCP sockets in Python; the C libraries are accessed by the Bone in Python using the ctypes Python standard module. Browser controls are based on node.js and Google Maps API.
More detail regarding the interaction of different parts of the code and important interfaces will be provided as they are finalized.
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
- 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, completion TBD
- Soldered and interfaced battery subsystem to power BeagleBone
- Researched and purchased compass and GPS sensors
- Wrote libraries to interface to compass and GPS sensor
- Currently coo-developing movement and navigation software **to be completed 11/7; code to add waypoints complete as of 10/31
- Currently co-developing movement and navigation software **to be completed 11/7; code for basic movement complete as of 10/24
- Developed prototype software for network communication, currently developing more robust network protocol implementation **to be completed 11/3; basic prototype code completed 10/31
The major remaining tasks to be completed are
1) Solidify the interface from the networking code to the motor control
2) Code to manage waypoints and drive the motors based off of waypoint inputs
3) Improve GPS library to allow for update rate configuration
Task 1 is absolutely necessary to fulfilling the goals of the project, while tasks 2 and 3 are good features, but not core requirements.
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
Embedded Linux Class by Mark A. Yoder