F17: Optimus
From Embedded Systems Learning Academy
Contents
- 1 Optimus
- 2 Abstract
- 3 Objectives & Introduction
- 4 Team Members & Responsibilities
- 5 Schedule
- 6 Parts List & Cost
- 7 CAN Communication
- 8 DBC File
- 9 Android and Communication Bridge
- 10 Geographical Controller
- 11 Sensor and I/O
- 12 Motor Controller
- 13 Master Controller
- 14 Common Technical Challenges
- 15 Conclusion
- 16 References
Optimus
Optimus - Self Navigating R/C Car powered by SJOne(LPC1758) micro controller.
Abstract
[[|thumb|centre|700px|System Diagram]]
Objectives & Introduction
Team Members & Responsibilities
- Android and Communication Bridge:[[|233px|right]]
- [ Parimal]
- [ Parimal]
- Geographical Controller:
- [ Sneha]
- [ Sarvesh]
- [ Sneha]
- Master Controller:
- [ Unnikrishnan]
- [ Revathy]
- [ Kripanand]
- Motor Controller
- [ Unnikrishnan]
- [ Rajul]
- [ Unnikrishnan]
- Sensor and I/O Controller:
- [ Sushma]
- [ Supradeep]
- [ Harshitha]
- [ Sushma]
Schedule
Legend:
Major Feature milestone , CAN Master Controller , Sensor & IO Controller , Android Controller, Motor Controller , Geo , Testing, Ble controller, Team Goal
| Week# | Date | Planned Task | Actual | Status |
|---|---|---|---|---|
| 1 | 9/23/2017 |
|
|
Complete. |
| 2 | 9/30/2017 |
|
|
Complete |
| 3 | 10/14/2017 |
|
|
Complete |
| 4 | 10/21/2017 |
|
|
complete |
| 5 | 10/28/2017 |
|
|
Complete |
| 6 | 11/07/2017 |
|
|
Complete |
| 7 | 11/14/2017 |
|
|
Complete. |
| 8 | 11/21/2017 |
|
|
Complete. |
| 9 | 11/28/2017 |
|
|
Complete. |
| 10 | 12/5/2017 |
|
|
Complete |
| 11 | 12/12/2017 |
|
|
On Track |
Parts List & Cost
The Project bill of materials is as listed in the table below.
| Item# | Part Description | Vendor | Qty | Cost |
|---|---|---|---|---|
| 1 | SJ One Board (LPC 1758) | From Preet | 6 | $480 |
| 2 | [1] | Prof. Kaikai Liu provided | 1 | $0 |
| 3 | Accelerometer/Magnetometer LSM303 | Adafruit | 2 | $40.00 |
| 4 | Bluetooth Module | Sparkfun | 1 | $34.95 |
| 5 | CAN Transceivers | From ebay. | 15 | $51 |
| 6 | Battery Pack | From Sheldon Hobbist | 1 | $49.99 |
| 7 | RP Lidar | 5 | $400 | |
| 8 | LED $ Digit Display | From Preet | 1 | $0 |
| 9 | GPS Module | From Adafruit | 1 | $43.34 |
| 10 | General Components | From Amazon | - | $ |
| 11 | RPM Sensor | From traxxas | 1 | $20 |
| 12 | PCB | 1 | $10.66 | |
| 13 | Acrylic Board | From Amazon | 1 | $12.53 |
| 14 | PCAN dongle | From Preet | 1 | $0 |
| 15 | Power Bank | From Amazon | 1 | $41.50 |
| 16 | PCB Manufacturing | From PCB Way | 5 | $70 |
CAN Communication
System Nodes : MASTER , MOTOR , BLE , SENSOR , GEO
| SNo. | Message ID | Message from Source Node | Receivers |
|---|---|---|---|
| Master Controller Message | |||
| 1 | 2 | System Start command to start motor | Motor |
| 2 | 17 | Target Speed-Steer Signal to Motor | Motor |
| 3 | 194 | Telemetry Message to Display it on Android | BLE |
| Sensor Controller Message | |||
| 4 | 3 | Lidar Detections of obstacles in 360 degree grouped as sectors | Master,BLE |
| 5 | 36 | Heartbeat | Master |
| Geo Controller Message | |||
| 4 | 195 | Compass, Destination Reached flag, Checkpoint id signals | Master,BLE |
| 5 | 4 | Turning Angle | Master,BLE |
| 5 | 4 | Heartbeat | Master |
| Bluetooth Bridge Controller Message | |||
| 4 | 38 | Heartbeat | Master |
| 5 | 213 | Checkpoint Count from AndroidApp | Geo |
| 5 | 214 | Checkpoints(Lat,Long) from Android App | Geo |
DBC File
https://gitlab.com/optimus_prime/optimus/blob/master/_can_dbc/243.dbc
Android and Communication Bridge
Group Members
Design & Implementation
Pin Configuration:
Hardware Design
Software Design and Implementation
Android App
BLE Controller
Testing & Technical Challenges
Geographical Controller
Group Members
Hardware Design
GPS and Compass Module:
We are using DJI’s NAZA GPS/COMPASS to get the GPS coordinates and Heading angle. The diagram of the module is as follows:
File:CMPE243 F17 Optimus Gps.jpg
Hardware Schematic
The message structure of the GPS and Compass module is as follows:
Message Structure:
The 0x10 message contains GPS data. The message structure is as follows:
55 AA 10 3A DT DT DT DT LO LO LO LO LA LA LA LA
The payload is XORed with a mask that changes over time.
Values in the message are stored in little endian.
HEADER
BYTE 1-2: message header - always 55 AA BYTE 3: message id (0x10 for GPS message) BYTE 4: length of the payload (0x3A or 58 decimal for 0x10 message)
PAYLOAD
BYTE 5-8 (DT): date and time BYTE 9-12 (LO): longitude (x10^7, degree decimal) BYTE 13-16 (LA): latitude (x10^7, degree decimal)
CHECKSUM
BYTE 63-64 (CS): checksum
XOR mask
All bytes of the payload except 53rd (NS), 54th, 61st (SN LSB) and 62nd (SN MSB) are XORed with a mask. Mask is calculated based on the value of byte 53rd (NS) and 61st (SN LSB).
Pin Configuration:
The Pin Configuration is as follows:
Software Design
Algorithm:
Distance calculation:
We are using the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface
Haversine formula:
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
c = 2 ⋅ atan2( √a, √(1−a) )
d = R ⋅ c
where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km)
Bearing Angle calculation:
Formula:
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
where φ1,λ1 is the start point, φ2,λ2 the end point (Δλ is the difference in longitude)
Since atan2 returns values in the range –π to +π (that is, -180° to +180°), to normalize the result to a compass bearing (in the range 0° to 360°), negative values are transformed into the range 180° to 360°) by converting to degrees first and then using (θ+360) % 360, where % is (floating point) modulo.
DBC Messages:
Messages sent from GEO module:
BO_ 4 GEO_TURNING_ANGLE: 2 GEO
SG_ GEO_TURNING_ANGLE_degree : 0|9@1- (1,0) [-180|180] "" MASTER,BLE
BO_ 37 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_signal : 0|8@1+ (1,0) [0|255] "" MASTER
BO_ 195 GEO_TELECOMPASS: 6 GEO
SG_ GEO_TELECOMPASS_compass : 0|12@1+ (0.1,0) [0|360.0] "" MASTER,BLE SG_ GEO_TELECOMPASS_bearing_angle : 12|12@1+ (0.1,0) [0|360.0] "" MASTER,BLE SG_ GEO_TELECOMPASS_distance : 24|12@1+ (0.1,0) [0|0] "" MASTER,BLE SG_ GEO_TELECOMPASS_destination_reached : 36|1@1+ (1,0) [0|1] "" MASTER,BLE SG_ GEO_TELECOMPASS_checkpoint_id : 37|8@1+ (1,0) [0|0] "" MASTER,BLE,SENSOR
BO_ 196 GEO_TELEMETRY_LOCK: 1 GEO
SG_ GEO_TELEMETRY_lock : 0|8@1+ (1,0) [0|0] "" MASTER,SENSOR,BLE
BO_ 214 GEO_TELEMETRY: 8 GEO
SG_ GEO_TELEMETRY_LONG : 0|32@1- (0.000001,0) [0|0] "" MASTER SG_ GEO_TELEMETRY_LAT : 32|32@1- (0.000001,0) [0|0] "" MASTER
Messages received by GEO module:
BO_ 212 BLE_GPS_DATA: 8 BLE
SG_ BLE_GPS_long : 0|32@1- (0.000001,0) [0|0] "" GEO SG_ BLE_GPS_lat : 32|32@1- (0.000001,0) [0|0] "" GEO
BO_ 213 BLE_GPS_DATA_CNT: 1 BLE
SG_ BLE_GPS_COUNT : 0|8@1+ (1,0) [0|0] "" GEO,SENSOR
Implementation
Periodic callback function description:
1 Hz Function:
a. Check CAN bus
b. Send Heartbeat to Master module
c. Send GPS lock to Master and Sensor modules
100 Hz Function:
a. Get GPS coordinates
b. Get Heading angle
c. Get Checkpoints count
d. Calculate Bearing angle
e. Calculate Turning angle
f. Calculate Distance remaining
g. Send Heading angle
h. Send Bearing angle
i. Send Turning angle
j. Send Distance remaining
k. Check Destination reached
Testing & Technical Challenges
Sensor and I/O
Group Members
Design & Implementation
Hardware Design
Hardware Interface
Software Design and Implementation
Design & Implementation
Hardware Interface
Software Design
Testing & Technical Challenges
Motor Controller
Group Members
Design & Implementation
Hardware Design
Software Design
Implementation
Testing & Technical Challenges
Master Controller
Group Members
Introduction and Responsibilities
Master controller is the brain of the car.
All the decisions are taken by the master module. Some of the major responsibilities of the master module are:
- System command (Initial Start) : Upon successful connection with Android app, master command will send as system start command to all the other modules on the CAN bus. This command advises all the modules to start their processing(similar to wake up).
- Obstacle avoidance : Based on the sensor values, master will decide the direction to be taken by the motor.
- GPS data: Depending upon the GPS calculated direction and obstacle data received from sensor module, master controller will decide the steer and drive of the motor.
- Determine if all the modules on the bus are active or inactive.
The master controller using the data from other modules, drives the car safely to the destination.
Hardware Design
- Interface of CAN Bus with six SJ-One controller boards on PCB was designed.
- Ribbon Cables were used instead of individual jumper wires to assist in designing less complex circuit.
Software Design
Master Controller needs to periodically receive and transmit updated data from all the modules in order to make an efficient decision. Based on the priority of the data, corresponding CAN messages are parsed in 100Hz, 10Hz or 1Hz periodic scheduler tasks respectively. Data received can be viewed and traced in real time using PCAN View or BUS Master tool.
Software Implementation
The diagram below details out the flow of data to and from the Master Controller.
Heartbeat
Master Controller is responsible to identify if all the modules are active or inactive. All the modules send the heartbeat messages on the CAN Bus every 1Hz. If the heartbeat message is not received from any module, master marks the system status of the module as inactive. The system status message is update at run time on the I/O and the app. User can then reset the inactive module.
The code snippet for the receiving heartbeat messages and determining system status is as follows:
if(dbc_decode_BLE_HEARTBEAT(&ble_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr)) system_status_message.MASTER_SYSTEM_STATUS_ble = 1; if(dbc_decode_SENSOR_HEARTBEAT(&sensor_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr)) system_status_message.MASTER_SYSTEM_STATUS_sensor = 1; if(dbc_decode_GEO_HEARTBEAT(&geo_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr)) system_status_message.MASTER_SYSTEM_STATUS_geo = 1; if(dbc_decode_IO_HEARTBEAT(&io_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr)) system_status_message.MASTER_SYSTEM_STATUS_io = 1; if(dbc_decode_MOTOR_HEARTBEAT(&motor_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr)) system_status_message.MASTER_SYSTEM_STATUS_motor = 1;
To determine the direction and throttle of the car, master controller needs the data from sensor and Geo module. These data are critical for the system and are parsed in 10Hz periodic tasks.
After the master receives BLE_CMD = START, master will send SYSTEM_CMD= START command to all of the modules, which notifies them that the Bluetooth communication via app has been initiated.
The car is capable of reaching a destination or just running while avoiding obstacles with no destination set.
The software design of the master controller supports two modes for the car:
Free Run mode
- For switching to free run mode, the “FREE RUN” button needs to be selected from the app.
- As per the sensor data, the movement of the car is decided by the master controller.
- By default the motor is commanded to move straight.
- If there is an obstacle in the middle sensor, then the sensor data for left and right sensor is checked.
- If there is an obstacle at a very short distance, critical obstacle bit is set and car is first stop.
- When the car needs to stop due to obstacles, reverse sensor value is checked.
- The car stops only when there are obstacles in all directions or user sends Stop from the app.
- The following table depicts the motor command sent by master to the motor controller as per the sensor values.
| Sr no | Left sensor value | Middle sensor value | Right sensor value | Critical value | Rear sensor value | Motor Command |
|---|---|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 | X | STRAIGHT |
| 1 | 0 | 0 | 1 | 0 | X | HALF RIGHT |
| 2 | 0 | 1 | 0 | 0 | X | LEFT |
| 3 | 0 | 1 | 1 | 0 | X | RIGHT |
| 4 | 1 | 0 | 0 | 0 | X | HALF LEFT |
| 5 | 1 | 0 | 1 | 0 | X | STRAIGHT |
| 6 | 1 | 1 | 0 | 0 | X | LEFT |
| 7 | 1 | 1 | 1 | 0 | 0 | REVERSE |
| 8 | 1 | 1 | 1 | 0 | 1 | STOP |
| 9 | X | X | X | 1 | 0 | REVERSE |
| 10 | X | X | X | 1 | 1 | STOP |
- When STOP button is selected from the app,the BLE will advise the same to master controller and master will send SYSTEM_CMD= STOP to all the modules. This stop command notifies them that the Bluetooth communication via app has been deactivated.
- For switching to navigation mode, the “NAVIGATION MODE” button needs to be selected from the app.
- In this mode, Geo module sends the desired direction to the master controller.
- The master controller will check if there is any obstacle in the desired path.
- In case of obstacle, car moves as per the obstacle avoidance algorithm (free run mode).
- Once Destination Reached signal is received from the Geo module, the car stops.
Common Technical Challenges
Issue 1
One of the most unexpected issue faced during testing, was we were unable to receive data from motor and sensor module during testing for demo1. After debugging, we realized that the ribbon cable we purchased was meant for a special purpose and was shorted internally as shown in the picture because of which we were unable to receive data from the CAN bus.
Conclusion
This project has helped each one of us grow, not just academically, but professionally as well. This project did achieve the goals it promised, these were:
- CAN: Teaching us to work with the CAN bus and protocol; a simple, robust and noise immune mode of communication and using DBC files as a method of managing CAN messages.
- GIT: Using GIT as a method of continuous integration and improve productivity. GIT allowed us to work independent of our schedules, boosting our productivity beyond the time the team members met.
- Team Work: Working in a fairly large group gave us a real sense of team work and collaboration.
- Professionalism and accountability.
On testing the car we found a lot of practical hurdles that we had to overcome. Debugging issues was a large part of our efforts to improve the working of our car. To mention a few:
- Hardware issues:
- Ribbon Cable: Issues with ribbon cables, we found the hard way that the ribbon cable we initially used was for a specific purpose making it incompatible with our boards.
- Voltage fluctuation disrupting the CAN bus: Inconsistent soldering on on of the power rails, caused the CAN bus to fail altogether.
- Bluetooth bridge: Maintaining a Bluetooth connection between different activities in the app was a problem.
- Sensor: A section of code was rearranged to solve a problem that prevented the sensor from sending messages to the CAN bus.
- I/O: The I/O module is receiving a large amount of data, causing a task overrun. This was fixed by re-prioritizing the display and rearranging the code.
To the teams that are designing their car:
- Use a faster sensor and apply filters like a median or Gaussian filter to improve sensor performance.
- Ensure hardware connections are tested thoroughly.
- Start with the implementation for the Geo module early.
- Ensure that your Android App can communicate consistently with SJOne board.
Project Videos
CMPE243_F16_Spartan_and_Furious Demo Day Video
Project Source Code
References
Acknowledgement
We would like to acknowledge the following people for their help in completing this project:
- Preet for his invaluable teachings.
- The ISAs for their great advice and tips.
- Siddarth for helping with the design for our 3D mount.
- Maxbotix for a generous student discount on their product.
- Microchip for the free CAN ICs.
- Cratus Technologies for letting us use their 3D printer.
References Used
- LPC_USER_MANUAL
- CAN transceiver
- Haversine Formula Wikipedia
- Magnetometer Wikipedia
- MCP2551 Datasheet
- Hall Effect Sensor Wikipedia
- Ultimate GPS Adafruit
- uLCD-32PTU
- Maxbotix Ultrasonic Datasheet
- Adafruit Ina219 current sensor
- SparkFun Bluetooth Modem - BlueSMiRF Gold
- Android Bluetooth API Guid
- Maps Android API
- RPM sensor 6520 Installation Guide
- Configuration of Electronics Speed Control
