F17: Optimus
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:
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
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.
Software Design and Implementation
Design & Implementation
Hardware Interface
Software Design
Testing & Technical Challenges
Motor Controller
Group Members
Design & Implementation
The motor controller is responsible for generating the driving and steering action of the car. For this purpose, we have two types motors viz DC motor for driving and Servo motor which is used for changing directions of the car. The motor controller is also interfaced with a speed encoder for generating a feedback mechanism to automatically control and monitor the speed of the car. Our car came equipped with a Servo motor and brushed DC motor which is connected Electronic Speed Control (ESC).
Hardware Design
| SJOne Pin Diagram | ||
|---|---|---|
| Sr.No | Pin Number | Pin Function |
| 1 | P0.0 | CAN RX |
| 2 | P0.1 | CAN TX |
| 3 | P2.0 | Servo motor |
| 4 | P2.1 | DC motor |
| 5 | P2.5 | Speed Encoder |
- Hardware Specifications
1. DC Motor
Our car came with Titan 12T 550 brushed motor and waterproof ESC. The ESC drives the DC motor based on the Pulse Width modulation (PWM) applied to it. The power supply required for this motor is 8.4 V. Maximum speed of upto 30mph can be achieved. The rotational speed is proportional to the EMF generated in its coil and the torque is proportional to the current.The main connection pins driving the motor are VCC,GND and the Control pin (PWM). The pin P2.1 of SJ-one board is connected to supply the required PWM to the motor.
The basic working principle of DC motor is illustrated in the following figure :
Since the preprogrammed controller has to be replaced by using our design ,the DC motor is then tested with Digital Oscilloscope for getting the frequency of operation and equivalent PWM values for full throttle condition in the forward as well as backward condition.
It was observed from the waveform that the frequency of operation is 100Hz. The range of operational duty cycle is 10% to 20% with 15% being the neutral value or the stop condition.
In order to accelerate the car a PWM value in the range of 15.6%-20.0% is applied. The 15.6 is the minimum pickup PWM that should be supplied in order to get the car moving at full load.
2. Servo Motor
The servomotor used in the car is #2056 a waterproof all weather-action and double the steering power as compared to standard servos. The servo motor is responsible for controlling the steering action of right or left by applying a suitable PWM pulse. The servo motor can be driven with 3.3 V power supply. The pin P2.0 of SJ-one board is connected to supply the required PWM to the motor. After testing the servo motor, we found that the frequency of operation is 100Hz and the operational duty cycle range is 10.0%-20.0% with 15% being the neutral value. For a full right deflection, we provide input PWM pulse ranging from 15.0-20.0% and for full deflection to the left we apply 10.0-15.0% of PWM.
3. Speed Sensor
The speed feedback is monitored through the speed encoder which works on the Hall-effect principle.
The Hall-effect speed sensor works as a transducer whose output voltage varies in response to the magnetic field.
The sensor is mounted on the Spur gear instead of the wheel. The sensor would detect the rotation of axle. The motor controller would detect whenever the magnet is aligned with the sensor. This would generate a pulse. The pulse is detected in the form of rising-edge interrupt.
This gives the wheel rotation count. The wheel rotates for every 1/4th rotation of the spur gear. The rotation count can then be converted to rpm to calculate the speed of the car.
Hardware Interface
The CAN bus is used to send and receive messages to and from the Master Controller. The motor controller receives driving and steering signals from the master. The speed calculation is performed using the speed sensor and is sent on the bus, which will be received by the IO controller for display purposes.
Software Design
The following diagram describes the flow of the software implementation for the motor driver and speed feedback mechanism.
Implementation
The motor controller receives all its signals from Master controller from the CAN bus. The motor controller receives the steer and drive command from the master. The motor controller receives the System start command which boots and decodes further drive signals to the motor controller. Upon receiving the drive command the motor controller decodes the steering action. Upon receiving suitable data about the obstacle from sensor controller the master controller relays appropriate steering action. To achieve better performance in steering, the turn is categorized as FULL and HALF. This gives better precision in turning.
- Speed Regulation:
Upon detection of uphill the pulse received from the speed encoder reduces. This is detected and the motor feedback is designed such that the speed is increased by providing higher value of PWM value to drive the DC motor. Similarly, for downhill the pulse count received increases which is detected by the speed encoder and the speed is reduced by applying reduced PWM.
Testing & Technical Challenges
- Wheel Alignment Error
Though the neutral value of PWM is 15% at which the servo is supposed to be aligned straight. In practice, however when we tested the car for straight run slight deflection towards right was observed when the PWM pulse width was set to 15.0 %. Thus, to correct this, we provided correction value of -0.98 giving a resultant PWM pulse width of 14.02%. Thus, we fixed the wheel alignment and obtained the desired straight path traversal.
- Speed Sensor Assembly
The speed encoder was assembled on the spur gear of the car. The installation at first was such that outer fitting was large and was avoiding the pulse trigger by the magnet.As a result of which we were unable to modulate speed.Issue was resolved by using the correct outer assembly of the gear which generated the speed feedback.
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
