Post date: Jun 04, 2014 3:30:22 PM
Introduction. This page describes the major components of Temple University's robotic car constructed for the RAS Prepared Robotics Competition. The robotic car's major components are divided into two sections, hardware and software. The hardware section explains the hardware components that had a significant role in the robotic car's implementation and how those hardware components are interconnected, whereas the software section explains what major operations are implemented and the tools used to develop the software.
Figure of major hardware components and how those components are connected to each other. The arrows signify the direction information is flowing. For instance, the majority of the information flowing between the gyroscope and the activity board is from the gyroscope to the activity board.
Hardware. The figure above is an abstraction that shows the robotic car's major hardware components. In other words, only the hardware components that carry out either conspicuous or high-level operations are described here. Other components, such as Analog-to-Digital (A2D) converters and batteries, are thus excluded. Below are concise descriptions of each major component's purpose in the project. The names of each major hardware component are hyperlinks to webpages that include more information on the particular component.
Parallax's 3-Axis Gyroscope Module. The gyroscope is important tool in determining the robotic car's angle off the ground for the RAS competition's Angle Find course. Specifically, the gyroscope returns the angular rate for the pitch, roll, and yaw axes. Since the angular rate is in degrees per second, the angle is approximated as a Riemann sum. The sum calculated by continuously adding together angular rates and multiplying the sum by the period between each angular rate taken from the gyroscope.
The picture on the left is taken from this website.
Parallax's Boe-Bot. Only the chassis and wheels of Parallax's Boe-Bot kit are used in the robotic car's construction. The wheels, of course, are driven by the continuous rotation servos and allows the robotic car to move. The chassis, of course, is where all the robotic car's hardware components are mounted. The chassis is modified such that a shelf made out of Plexiglass is securely located above the flat-area of the chassis. The amount of space between the shelf and the chassis's flat area is just enough to firmly hold the battery pack which supplies power to the robotic car's components. The electronic components sit on top of the shelf. Mounted underneath the chassis are all the servos, the wheels, leg, photo-resistors, and the bright LEDs.
Parallax's Propeller Activity Board. The activity board is a development board that carries important components such as EEPROM memory, FTDI USB-UART interface, and the Propeller microcontroller unit (MCU). The Propeller MCU acts as the "brain" of the robotic car, executing the embedded software (see the subsection entitled "Embedded Software" under software) and interacting with connected peripheral devices, such as the photo-resistors and servos.
Digi's Series 1 XBee Pro Wireless Transceivers. The XBee transceivers allow for a wireless communication channel, through which the robotic and the computer communicate with the 8N1 (8 data bits, no parity bits, 1 stop bit) asynchronous serial communication protocol. Thus, the computer and the robotic car each have their own respective XBee transceiver, although they interface to their XBee transceiver differently.
Parallax's Continuous Rotation Servos. As one would expect, the continuous rotation servos turn the wheels that drive the robotic car, including turning and moving in a straight direction. And, as standard, the continuous rotation servos are easily controlled with the Radio Control (RC) Pulse Width Modulation (PWM) communication protocol. Unlike the standard servo, the continuous rotation servos, of course, continuously spin when not in neutral.
Parallax's Standard Servo. The standard servo planted beneath the chassis is attached to a "leg", a metallic component that can be turned such that the robotic car's smaller wheel is lifted off the ground. The standard servo is, of course, what causes the leg to turn to a specified position. The extra height reached by the leg is necessary for the RAS competition's Boulder Field course, where the robotic car needs to climb over bulky "boulders" in order to finish the course.
Photo-resistors. As required by the robotic-car's line-allowing algorithm, a combination of the photo-resistors and A2D converters produce values indicative to how much light is reflected back from the ground. Relatively smaller values are obtained for less reflected light, whereas relatively larger values are obtained for more reflected light.
The photo-resistors are positioned such that the intended line to follow should always be trapped between the two photo-resistors. Since the line is assumed a color significantly darker than the ground's normal color (namely, the line is black, whereas the surrounding area is white), a lower value indirectly obtained from a particular photo-resistor indicates the line is passing under the particular photo-resistor.
Bright LEDS. The bright LEDs prevent ambient lighting from interfering with the photo-resistors. Ambient lighting is liable to change and, considering the line-following algorithm implemented into the robotic car relies on thresholds, care must be taken to prevent the interference.
Another laptop running a Windows OS could have easily replaced the one seen in the figure.
Computer. The computer's role is to run the computer software (see the subsection "Computer Software" under software) and physically interface with only two peripherals, an XBee transceiver and a Xbox 360 controller.
Figure of the software's major operations and which system (either the computer or the robotic car) each operation executes on.
Software. The figure above enumerates the major operations carried out by the project's software. In short, the computer software is developed more so as a wireless interface to the robotic car, allowing for remote mode selection (i.e. either line or manual) and similar control-related operations. The embedded software, on the other hand, carries out the commands received from the computer software and transmits messages back to the computer software.
Figure of the GUI that runs as part of the computer software
Computer Software. The computer software primarily implements a remote interface through which the robotic car is controlled. The graphical user interface (GUI) is developed in Java with Netbeans IDE, primarily utilizing the Swing library for the graphical interface and the 3rd-party jxinput library for enabling usage of the Xbox 360 controller. The software for accessing the computer's serial port and using the XBee Transceivers is developed in C++ with Visual Studios 2012 IDE, primarily relying on the asio boost library.
Embedded Software. The embedded software refers to the software developed for the Activity Board's Propeller MCU and contains the implementations of all of the robotic car's operations. All the embedded software is developed in C++ with SimpleIDE. The SimpleIDE includes a "Simple" library from which inter-integrated circuit (I2C), RC-PWM, and Transistor-Transistor Logic (TTL) 8N1 asynchronous serial communication protocols are called in order to develop high-level software for interfacing with the activity board's peripheral devices.
Below is a more detailed description of the operations carried out by embedded software. The description is intended to follow the concise description in the figure of the project's major software operations.
Set the mode. There are two modes of operation, line and manual. If the embedded software is set to its line mode, the embedded software continuously reads the values from the two pairs of photo-resistors and A2D converters. Based on the two values, the embedded software directs the continuous rotation servos such that the robotic car follows a skinny enough black line. If the embedded software is set to its manual mode, the user can manually control the robotic car's continuous servo motors with either the computer's keyboard or the Xbox 360 controller.
Either extend or retract leg. The embedded software instructs the standard servo attached to the bottom of the chassis to either extend or retract the leg, depending on the user's input. If the leg is extended, the robotic car is more able to climb over higher surfaces.
Set which side of robotic car is the front. Originally, the side the robotic car closest to its two large drive wheels was considered the front of the robotic car, and thus the manual controls were programmed, accordingly. However, in order to more easily take advantage of the extended leg, the embedded software is modified such that the side of the robotic car with smaller, spherical wheel can become the front.
Flush angle indirectly produced by the gyro. Because the embedded software determines the angle as a Riemann sum of many angular rates, drift error occurs. In order to reduce the impact of drift error, the embedded software is developed such that the angle can manually be flushed down back to zero.
Display angle produced by gyro. As required by the RAS competition's Angle Find course (please see the competition section on the RAS competition's main page), the incline's angle needs to visibly be shown once the robotic car reaches the end of the course. Embedded software is developed so that an angle is stored a few seconds after the robotic car exceeds a minimum angle threshold. The user can then instruct the embedded software to only display the stored angle through the seven segment display. Once the user decides to flush the angle, the embedded software resumes continuously updating to the seven segment display with the latest calculated angle.