TXT-1 Robotic Truck
From MARHES
Contents |
Maintenance Guides
Software
- Installing the Operating System and Drivers
- Configuring the Boot Sequence on the TXT-1s
- Configuring Player
- TXT-1 Remote Login
PCBs and Firmware
- CANBot PCB
- IR PCB
- GPS/IMU PCB
Other Hardware
- Setting up the wireless access point
- Driving a truck manually and observing using the Cannon VB-C10 camera
- Charging the Batteries
- Programming the Embedded Microcontrollers
- Configuring the PC/104
- Configuring a Laptop for the TXT-1s
- How to use the Bumblebee Stereo Camera with PC/104s
- An Overview of the TXT-1's Sensors
Calibration
- IR sensors
- Odometry
- Steering Alignment
- Camera Parameters
Demos
Construction
The TXT-1 robotic trucks get their name from the remote control truck that forms the chasis of the robot. Though heavily modified, the frame, shocks, wheels, motors, and servos still exist from the original trucks. In addition a custom designed metal plate mounted on the chassis holds any computer and sensor equipment. The details of the modification are available in this report.
Features
The TXT-1's versatility stems from its flexible CAN bus system supported by the CANBot Control Unit designed in the MARHES lab and the suite of sensors available to the robot. The flexible player interface to the low level components allows quicker conversion of control algorithms to work on the TXT-1s and allows for easy communication between robots.
CANBus
The CAN is a serial bus system created especially for connecting smart devices. It has very attractive attributes such as real-time message transmission, multi-master capabilities, sophisticated error detection, and availability in the local market which makes it very suitable for industrial and robotic applications. The CAN protocol is a bus system that is widespread in the automotive industry, and is becoming more popular in the robotic field. See the Robot Bus Project at the GRASP Lab.
The CAN protocol is a message-based bus, therefore bases and workstation addresses do not need to be defined, only messages. These messages are recognized by message identifiers. The messages have to be unique within the whole network and define not only the content, but also its priority.
MARHES CAN Bus System
Our lower-level CAN Bus system allows for sensors and actuators to be added and subtracted from the system with no reconfiguration required to the higher-level structure. Initially, message ID's are defined for each type of module. When a new module is added to the bus, the higher-level software reconfigures itself to communicate with the module. This plug and play system allows for ease of transition from one application to the next and also makes our mobile platform flexible to higher-level controllers. The plug and play system will also allow larger module networks to be built without the user having to reconfigure the entire system. Also, it allows for a higher level of abstraction, i.e., each robot is seen as a node in a network consisting of hundreds of robots.
Control Unit Description
The MARHES TXT CAN bus control unit contains all of the necessary modules for vehicle control. This control unit has three modules incorporated into one board. The Control unit is required by each of the vehicles in the MARHES multi vehicle testbed. The three modules on the control unit are the PID speed controller, servo (PWM) controller, and device manager. Each of the three modules contain a microcontroller, CAN transceiver, and status LEDs.
The Device Manager has one connection to the Servo (PWM) Controller's reset pin, which allows the Device Manager to reset the Servo (PWM) Controller as needed. This is a safety feature added to the control unit which allows the vehicle to stop itself in the rare event that the motor controller has locked up.
PID Speed Controller
The Speed Controller reads the speed commands from the CAN bus and measures the actual speed using odometry. A PID controller is used to accurately maintain the desired speed by outputting commands to the CAN servo controller. The speed controller is capable of controlling both linear and angular velocities. The message protocol for the speed controller is shown in the table below.
| ID | DLC | DATA [0] | DATA [1] | DATA [2] | DATA [3] | DATA [4] | DATA [5] | DATA [6] |
|---|---|---|---|---|---|---|---|---|
| 0x290 | 7 | LSB Speed | MSB Speed | LSB FS | MSB FS | LSB CS | MSB CS | LA |
ID: message identifier
DLC: Data length. Number of bytes sent in the message.
Data[n]: The bytes containing the commands.
Variable Variable Name Description MSB Most Significant Byte Most significant byte LSB Least Significant Byte Least significant byte Speed Linear Speed (mm/s) The desired speed in mm/s FS Front Servo The desired front servo value or angular speed CS Camera Servo The desired camera servo value LA Linear/Angular flag LA=X linear speed LA=0 angular speed
The performance of the speed controller is best illustrated from the PID profile in the Figure 2. A constant speed is desired and the plot shows that this speed was achieved and maintained.
Servo (PWM) Controller
The Servo (PWM) Controller supplies the necessary pulses to the two steering servos, camera servo, motor controller, and if needed, four additional PWM channels. The devices currently being used all require a pulse width of 0.5-2.5 ms at a frequency of 50 Hz. This module uses the PIC18F248, operating at 40 MHz, to produce eight PWM signals with 12-bit resolution. The resolution for the servos is 0.043 degrees per bit. The Servo (PWM) Controller accepts message ID 640 (0x280 hexadecimal) and commands of 0 to 4095 (0xFFF hexadecimal). A sample message is shown below in Table 2.
| ID | DLC | DATA [0] | DATA [1] | DATA [2] | DATA [3] | DATA [4] | DATA [5] | DATA [6] | DATA [7] |
|---|---|---|---|---|---|---|---|---|---|
| MSB MS | LSB MS | MSB FS | LSB FS | MSB RS | LSB RS | MSB CS | LSB CS | ||
| 0x290 | 7 | 0x08 | 0x00 | 0x08 | 0x00 | 0x08 | 0x00 | 0x08 | 0x00 |
Variable Variable Name Description MSB Most Significant Byte Most significant byte LSB Least Significant Byte Least significant byte MS Motor Speed (mm/s) Controls the PWM signal sent to the speed controller FS Front Servo Controls the PWM signal sent to the front servo RS Rear Servo Controls the PWM signal sent to the rear servo CS Camera Servo Controls the PWM signal sent to the camera servo
A 12-bit data value is sent to the Servo (PWM) Controller and the microcontroller turns the pulse on for this amount of time and then turns it off for the remainder of the 2.5 ms. Since the Servo (PWM) Controller only receives messages, a "still alive" message is sent every 500 ms with ID 0x310 to comply with the device manager module, which requires this message to maintain CAN bus integrity.
Device Manager
The Device Manager is the CAN component which manages the bus. At start-up, each sensor sends a message with its ID to the bus, then the Device Manager reads the message, and sends a message of the same ID back to each sensor instructing the sensor to begin working. After start-up, the Device Manager checks the bus continuously to see if a sensor has been connected/disconnected and that all components are working properly. If a module stops working for any reason (i.e. broken, disconnected, or locked up), the Device Manager sends an error message to the PC notifying the user about the problem.
CANBot Control Unit Circuit Board
The control unit board was designed using Eagle Pro Circuit Design tool. The image file is shown below.
The constructed CANBot control unit board is shown below with the top view on the right and the bottom view on the left side.
 Bottom |
 Top |
Sensors
In addition to the sensors listed below, more sensor equipment exists in the lab ready to be incorporated into the TXT-1 driver.
InfraRed - IR
The IR devices are based on the Sharp 2Y0A02 InfraRed long distance measuring sensor. This device outputs an analog voltage proportional to the object distance. The range of the Sharp IR long distance measuring sensor is 0.2 − 1.5m. The testbed IR device is composed of three Sharp IR long distance sensors in a 45deg offset array. This allows the system to identify obstacles straight in front of the vehicle, in diagonal and on the side. A single microcontroller chip reads the distance sensors at a 25Hz sampling rate using the built-in Analog to Digital Converters (ADC) and once the range information is read, it is transmitted through the CANBus via the built in CAN controller.
Laser Sensors
Global Positioning System - GPS
A variety of GPS receivers may be connected to the vehicle. Currently the DS-GPM GPS receiver from Designer Systems and the Garmin GPS35 are supported, additionally the interface board is capable of supporting any GPS receiver that outputs standard NMEA 0183 sentences. These devices may be accessed via the slave I2C interface or RS −232 and provide data which includes longitude, latitude, altitude, heading, speed, satellites detected and dilution of precision. Time, date and analog inputs, are available but not used at this time. Both GPS receivers have an adjustable update rate of up to 1Hz and are capable of differential correction with the support of extra hardware. As with other GPS receivers in this class, these receivers are accurate to approximately 15m without differential correction. Data from the GPS receivers, regardless of the particular interface or protocol used, is parsed and packaged into two separate CAN bus messages that are forwarded to bus.
Inertial Measurement Unit - IMU
At present time the IMU used by the testbed is the Microstrain 3DMG. The IMU provides temperature compensated triaxial orientation information in pitch (φ), roll (ψ) and yaw (θ) by integrating data from various internal sensors and measured against a local coordinate system. Specifically, the IMU incorporates three accelerometers for measuring gravity, three magnetometers for measuring magnetic fields and three rate gyroscopes for measuring the IMUs rate of rotation about each of the three axes. An addition of the IMU to the vehicle enables the system to provide 2D Gyro-Enhanced odometry, where the orientation angle is provided by the IMU. Gyro-Enhanced odometry is far more accurate than solely encoder based odometry, particularly in determining the heading of the robot, since this angle is provided by a gyro instead of differences in wheel rotation. While 2D Gyro-Enhanced odometry is automatically provided when the IMU is connected to the system, the user may alternatively request 3D position that makes comprehensive use of the sensor.
Video
The video cameras are the only sensors in the sensor suite that are out of the CAN network. We use FireWire cameras connected directly to the on-board computer. The BumbleBee stereo camera manufactured by Point Grey or a Fire-i digital camera from Unibrain is mounted on each robot.
Odometry
PC-104
A rugged PC-104 (from ADL) miniature computer hosts the software for local control of each vehicle. The PC-104 system has the same capabilities of a full blown desktop system with a reduced size factor ideal for robotic and mobile sensor networks applications. The PC-104 has been equipped with a 40GB hard drive, FireWire, Kvaser CAN cards, WiFi support and a Pentium M processor. Our systems feature RedHat Fedora Core 2 and run the 2.6 Linux kernel. The on-board computer is in charge of running high-level control tasks and interfaces with the robot via the CANBot Control Unit. The high-level control sends linear and angular speed commands to the CANBot Control Unit, which executes PID local control loops based on odometry readings. The CANBot Control Unit is the only CAN device that is mandatory for each of the vehicles and was explained in detail earlier.
Player
The PC-104 system executes Player, the device server. Once Player is running, the robot is controllable via the network. A control program may run on the local machine or using a remote computer on the network. As any other communication system, ours has implicit systematic and non-systematic delays that may affect the performance of the controllers. The lowlevel controller has to deal with the CANBus network delays and latency; nevertheless, the influence of these are assumed to be low enough to be disregarded and the high-level control assumes information is readily available at each sampling interval. However, when the high-level control operates using the Local Area Network (LAN), delays can be significant and may affect the performance of the system. The capability of the platform to operate in local or networked mode opens the opportunity to study the effects of such delays in networked embedded systems.
Player Driver
The TXT Player Driver allows Player to access and control all sensors and actuators in the robot. It is a bridge between the Player Sensor server and the Robot CAN Network. This is made possible via a Kvaser PCMCIA CAN Card and the software library CANLIB. The TXT Player Driver updates information from every sensor connected in the CANBus at a 1ms sampling rate. At this time our driver supports the CAN enabled sensors described in the previous section and the data is provided through the position, position3D, IR, sonar and GPS standard Player interfaces.
New Generation of TXTs
Design of the New TXT Vehicle for Cyber-Physical System Research
Contributors
A great deal of this page is adapted from internal documents created by various research assistants.
Authors José Sánchez
Kenny Walling
Dan Cruz
Colby Toland Photographers José Sánchez
Kenny Walling
Dan Cruz Editor Colby Toland
Media
See TXT-1 Media.
