Difference between revisions of "F15: Minion"
(→Software Implementation) |
(→Software Implementation) |
||
Line 1,197: | Line 1,197: | ||
To implement all the motor related functions, we have employed a dedicated task. Initially, the pre-scaled PWM values are fed to the motors based on the direction and level from the Master. We have a bit robust algorithm to obtain these PWM values which has offsets and level multipliers. The advantage of this is we can change the code to function for multiple levels with minimum effort. | To implement all the motor related functions, we have employed a dedicated task. Initially, the pre-scaled PWM values are fed to the motors based on the direction and level from the Master. We have a bit robust algorithm to obtain these PWM values which has offsets and level multipliers. The advantage of this is we can change the code to function for multiple levels with minimum effort. | ||
− | '''Motor | + | '''Motor Feedback''' |
After feeding the motors with the required levels, we have to check if the car is actually moving at that speed. This is ensured through feedback and control based on that. The feedback is obtained through the speed sensor collaborated with the DC motor, which triggers a pulse on every rotation and this is recorded by a rising edge based interrupt. The interrupt callback function increments the number of pulses. A separate logic is used to calculate and then compare the actual and required(from Master) speed levels. The corrective measures are enforced to achieve the desired speed. | After feeding the motors with the required levels, we have to check if the car is actually moving at that speed. This is ensured through feedback and control based on that. The feedback is obtained through the speed sensor collaborated with the DC motor, which triggers a pulse on every rotation and this is recorded by a rising edge based interrupt. The interrupt callback function increments the number of pulses. A separate logic is used to calculate and then compare the actual and required(from Master) speed levels. The corrective measures are enforced to achieve the desired speed. | ||
Revision as of 14:09, 9 December 2015
Contents
- 1 Grading Criteria
- 2 Minion
- 3 Abstract
- 4 Objectives & Introduction
- 5 Schedule
- 6 Parts List & Cost
- 7 DBC Implementation
- 8 Design & Implementation
- 9 Testing
- 10 Technical Challenges
- 11 Conclusion
- 12 References
Grading Criteria
- How well is Software & Hardware Design described?
- How well can this report be used to reproduce this project?
- Code Quality
- Overall Report Quality:
- Software Block Diagrams
- Hardware Block Diagrams
- Schematic Quality
- Quality of technical challenges and solutions adopted.
Minion
Abstract
This section should be a couple lines to describe what your project does.
Objectives & Introduction
Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.
Team Members & Responsibilities
Sensor Controller:-
Motor & I/0 Controller:-
Communication Bridge & Android Controller:-
- Akshay Kanchar
- Asmita Deshpande
Geographical Controller:-
- Amit Pachore
- Sindhuja Gopalakrishnan Elango
Master Controller:-
- Gaurao Chaudhari
- Akshay Dabholkar
Tester:-
Treasurer:-
- Keerthanaa Alagudurai
Hardware:-
- Amit Pachore
- Gaurao Chaudhari
- Bhupendra Naphade
Release:-
- Akshay Kanchar
Schedule
Common Schedule
Sl. No | Start Date | End Date | Task | Status | Actual Completion Date |
---|---|---|---|---|---|
1 | 9/22/2015 | 9/28/2015 | RC Car and important component buying | Completed | |
2 | 9/29/2015 | 10/6/2015 | 1) Algorithm and architecture 2) Setup of car and decision on CAN Id's |
Completed | |
3 | 10/7/2015 | 10/13/2015 | 1) Coding and final set-up of car 2) Successful communication of CAN bus. 3) Car in running position. |
Completed | |
4 | 10/14/2015 | 10/20/2015 | Sensor Data gathering and movement according to sensors. | Completed | |
5 | 10/21/2015 | 10/27/2015 | 1) LCD Display working and finalizing the data to be displayed on LCD module. 2) GEO data gathering and controlling of car using Android module. |
Completed | |
6 | 10/28/2015 | 11/3/2015 | Integration of all the modules into one. | Completed | |
7 | 11/4/2015 | 11/10/2015 | Inclusion of new features in the car. | ||
8 | 11/11/2015 | 11/17/2015 | Testing depending upon the newly added features. | ||
9 | 11/18/2015 | 11/24/2015 | Testing of Car and testing the self driving capability | Completed | |
10 | 11/25/2015 | 12/1/2015 | Testing of Car |
Sensor Controller Schedule
Sl. No | Start Date | End Date | Task | Status | Actual Completion Date |
---|---|---|---|---|---|
1 | 9/20/2015 | 10/5/2015 | Study available sensors and place order | Completed | 10/4/2015 |
2 | 10/6/2015 | 10/13/2015 | Collaborate with the other sub teams to finish the CAN bus communication | Completed | 10/13/2015 |
3 | 10/13/2015 | 10/20/2015 | Develop simple test code for the sensors | Completed | 10/18/2015 |
4 | 10/21/2015 | 10/30/2015 | Interface all sensors and develop code for reading all sensors. | Completed | 10/30/2015 |
5 | 10/30/2015 | 11/2/2015 | Positioning of sensors and identifying dead band if any | Completed | 11/2/2015 |
6 | 11/2/2015 | 11/5/2015 | Work on light and battery sensor (optional) | ||
7 | 11/06/2015 | 12/17/2015 | Final testing and debugging |
Motor & I/0 Controller Schedule
Sl. No | Start Date | End Date | Task | Status | Actual Completion Date |
---|---|---|---|---|---|
1 | 9/21/2015 | 9/25/2015 | Order LCD Display | Completed | 9/25/2015 |
2 | 9/28/2015 | 10/3/2015 | Going through the motor concepts and PWM | Completed | 10/2/2015 |
3 | 10/4/2015 | 10/9/2015 | Intreface the DC and SERVO Motors with SJONE board | Completed | 10/8/2015 |
4 | 10/10/2015 | 10/13/2015 | Establishing basic CAN communication with other modules | Completed | 10/13/2015 |
5 | 10/11/2015 | 10/16/2015 | Getting the car to run with the PWM signals from Motor controller | Completed | 10/15/2015 |
6 | 10/17/2015 | 10/23/2015 | Research on Speed cotrol method and sensor for the same interface LCD display with LPC1758 via UART | Completed | 10/21/2015 |
7 | 10/23/2015 | 11/4/2015 | Establishing reliable CAN communication for IO & Motor with others | Completed | 11/4/2015 |
8 | 11/5/2015 | 11/12/2015 | Integrate Speed sensor and get feedback. Start working on start,stop buttons and headlight | Completed | 11/11/2015 |
9 | 11/13/2015 | 11/20/2015 | Testing substantial self driving capability of the car | ||
10 | 11/21/2015 | 11/30/2015 | Complete integration, Debugging and Fine tuning | ||
11 | 12/1/2015 | 12/5/2015 | Final Validation |
Geographical Controller Schedule
Sl. No | Start Date | End Date | Task | Status | Actual Completion Date |
---|---|---|---|---|---|
1 | 09/27/2015 | 10/07/2015 | Ordering Parts and understanding each module | Completed | 10/11/2015 |
2 | 10/07/2015 | 10/13/2015 | CAN Communication with other boards and understanding each module | Completed | 10/13/2015 |
3 | 10/07/2015 | 10/30/2015 | Algorithm for distance and heading calculation and coding | Completed | 10/30/2015 |
4 | 10/14/2015 | 10/20/2015 | Interfacing of compass(I2C) and GPS (UART) with SJONE board | Completed | 10/20/2015 |
5 | 10/20/2015 | 10/30/2015 | Coding, Compass Calibration,GPS Calibration | Completed | |
5 | 10/25/2015 | 11/15/2015 | Individual unit testing | Completed | |
6 | 10/30/2015 | 11/30/2015 | Interfacing with Android, Master and IO controllers | ||
7 | 10/30/2015 | 11/30/2015 | Integration Testing,On Car Calibration | First level of On Car Calibration Completed |
Master Controller Schedule
Sl. No | Start Date | End Date | Task | Status | Actual Completion Date |
---|---|---|---|---|---|
1 | 09/30/2015 | 10/6/2015 | a) Design of Algorithm and Architecture for Master Module. b) Setup of CAN communication between two controllers. |
Completed | 10/6/2015 |
2 | 10/7/2015 | 10/13/2015 | a) Development of CAN message system for Android, Sensor and GPS, I/O reception. b) Decide about periodic function frequencies that’ll be handling different modules. |
Completed | 10/13/2015 |
3 | 10/14/2015 | 10/20/2015 | a) Development of driving,stopping and obstruction avoidance algorithm for motor. b) Implementation of LED Display to display number of messages on CAN bus. c) Implementation of turning algorithm as per the data received from the Geo Controller. |
Completed | 10/20/2015 |
4 | 10/21/2015 | 10/27/2015 | a) Designing of Kill switch with the help of Motor, I/O and Android. b) Design the system to restore the last known configuration. c) Implementation to reset modules if the CAN bus reaches BUS off state. |
Completed | 10/27/2015 |
5 | 10/28/2015 | 11/3/2015 | a) Design of Head Light functionality with the help of Sensor module. b) Implementation of log files saving to SD card. |
Completed | |
6 | 11/4/2015 | 11/10/2015 | a) Integration of all the modules with Master module and check it after combining everything. b) Probable implementation of additional features. |
On going | |
7 | 11/11/2015 | 11/17/2015 | a) Refine the work done earlier.Change areas that need a change. b) Test the Master module while all the modules are integrated together and list down modifications and additions to be done. |
Completed | |
8 | 11/18/2015 | 11/24/2015 | Testing of system and specially making sure that last week’s shortcomings are taken care of. | ||
9 | 11/25/2015 | 12/1/2015 | a) Final testing of individual modules. b) Testing the self-driving capability of the car. |
||
10 | 12/2/2015 | 12/8/2015 | Final working on the shortcomings in the previous week. | ||
11 | 12/9/2015 | 12/15/2015 | Final Testing of Car. |
Communication Bridge & Android Controller Schedule
Sl. No | Start Date | End Date | Task | Status | Actual Completion Date |
---|---|---|---|---|---|
1 | 9/29/2015 | 10/06/2015 | Ordering bluetooth module and setting up android dev enviornment | Completed | 10/06/2015 |
2 | 10/06/2015 | 10/13/2015 | Implementing basic UI with Start and Stop buttons and testing bluetooth module | Completed | 10/12/2015 |
3 | 10/13/2015 | 10/27/2015 | Integrating android app with bluetooth module and SJ One board | Completed | 11/01/2015 |
4 | 10/27/2015 | 11/03/2015 | Establishing communication with other modules using CAN and testing Prototype | Completed | 11/07/2015 |
5 | 11/03/2015 | 11/17/2015 | Enhancing UI features with Google Maps and display of sensor data from different modules | Ongoing | |
6 | 11/17/2015 | 12/01/2015 | Setting up Communication with GPS and Master and prototype testing | ||
7 | 12/01/2015 | 12/08/2015 | Final app testing |
Parts List & Cost
Sr. No | Part Name | Source of Purchase | Part Number | Quantity | Cost($) |
---|---|---|---|---|---|
1 | RC Car | Sheldons Hobbies | 360541 Stampede RTR | 1 | 239.99 |
2 | Battery | Sheldons Hobbies | VEN1548 - 5000NiMh 7.2 V | 1 | 44.99 |
3 | Traxx AC Adaptor | Sheldons Hobbies | TRAXXAS 2976 AC Adaptor to 12V | 1 | 24.99 |
4 | Compass | Dx.com | HMC5883L Digital Compass Module - Blue | 1 | 2.47 |
5 | GPS Module | Sparkfun.com | SparkFun Venus GPS with SMA Connector GPS 11058 | 1 | 44.08 |
6 | LCD module | mouser.com | NHD-0420D3Z-NSW-BBW-V3-ND | 1 | 29.68 |
7 | Bluetooth Module | Amazon.com | Sunkee HC-05 | 1 | 8.88 |
8 | Ultrasonic sensors | Amazon.com | HC-SR04 | 5 | 8.59 |
9 | PCB | Amazon.com | PCB | 2 | 10.6 |
10 | Female to Female connectors | aliexpress.com | Female to Female connectors | 2 | 1.5 |
11 | Compass | aliexpress.com | HMC5883L Digital Compass Module - Blue | 1 | 6.73 |
12 | GPS Antenna | Sparkfun.com | Antenna GPS Embedded SMA | 1 | 19.49 |
13 | female to female connectors+bergstrip+lm7805+SJ 32 pin socket | Excess solution | female to female connectors+bergstrip+lm7805+SJ 32 pin socket | 1 | 4.7 |
14 | Components | Excess solution | Connector+screws+Nuts+Standoffs | 1 | 10 |
15 | Component cable and led and other | Excess solution | Component cable and led and other | 1 | 17.29 |
16 | Ultrasonic sensors | Amazon.com | HC-SR04 | 5 | 8.69 |
DBC Implementation
VERSION ""
NS_ : NS_DESC_ CM_ BA_DEF_ BA_ VAL_ CAT_DEF_ CAT_ FILTER BA_DEF_DEF_ EV_DATA_ ENVVAR_DATA_ SGTYPE_ SGTYPE_VAL_ BA_DEF_SGTYPE_ BA_SGTYPE_ SIG_TYPE_REF_ VAL_TABLE_ SIG_GROUP_ SIG_VALTYPE_ SIGTYPE_VALTYPE_ BO_TX_BU_ BA_DEF_REL_ BA_REL_ BA_DEF_DEF_REL_ BU_SG_REL_ BU_EV_REL_ BU_BO_REL_ SG_MUL_VAL_
BS_: BU_: NOONE SENSOR MASTER MOTORIO ANDROID GEO
BO_ 220 MOTORIO_CMD: 4 MASTER SG_ MOTORIO_CMD_LeftRightdirection : 0|8@1+ (1,0) [0|2] "" MOTORIO SG_ MOTORIO_CMD_LevelOfDirection : 8|8@1+ (1,0) [0|5] "" MOTORIO SG_ MOTORIO_CMD_FrontBackDirection : 16|8@1+ (1,0) [0|2] "" MOTORIO SG_ MOTORIO_CMD_LevelOfSpeed : 24|8@1+ (1,0) [0|5] "" MOTORIO
BO_ 010 KILL_REQUEST: 0 ANDROID SG_ KILL_REQUEST : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 020 KILL_MESSAGE: 0 MASTER SG_ KILL_REQUEST : 0|0@1+ (1,0) [0|0] "" MOTORIO,SENSOR,GEO,ANDROID
BO_ 030 STOP_REQUEST: 0 ANDROID SG_ STOP_REQUEST : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 040 STOP_COMMAND: 0 MASTER SG_ ANDROID_HEARTBEAT_cmd : 0|0@1+ (1,0) [0|0] "" MOTOR
BO_ 210 SONARS: 4 SENSOR SG_ SENSOR_SONARS_FrontDistance : 0|8@1+ (1,0) [0|0] "" MASTER,MOTORIO SG_ SENSOR_SONARS_LeftDistance : 8|8@1+ (1,0) [0|0] "" MASTER,MOTORIO SG_ SENSOR_SONARS_RightDistance : 16|8@1+ (1,0) [0|0] "" MASTER,MOTORIO SG_ SENSOR_SONARS_RearDistance : 24|12@1+ (1,0) [0|0] "" MASTER,MOTORIO
BO_ 230 TOTAL_DISTANCE_TO_TRAVEL: 4 ANDROID SG_ TOTAL_DISTANCE_TO_TRAVEL: 0|16@1+ (1,0) [0|0] "" GEO
BO_ 240 SEND_CHECKPOINTS: 8 ANDROID SG_ SEND_CHECKPOINTS_Latitude: 0|32@1+ (1,0) [0|0] "" GEO SG_ SEND_CHECKPOINTS_Longitude: 32|64@1+ (1,0) [0|0] "" GEO
BO_ 250 DISTANCE: 4 GEO SG_ DISTANCE_FinalDistance : 0|16@1+ (1,0) [0|0] "" MASTER SG_ DISTANCE_CheckpointDistance : 16|16@1+ (1,0) [0|0] "" MASTER
BO_ 260 TURN_ANGLE_DIRECTION: 2 GEO SG_ TURN_ANGLE_DIRECTION_TurnAngle : 0|8@1+ (1,0) [0|0] "" MASTER SG_ TURN_ANGLE_DIRECTION_TurnDirection : 8|8@1+ (1,0) [0|0] "" MASTER
BO_ 270 RUN_PAUSE: 0 ANDROID SG_ RUN_PAUSE : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 280 HEARTBEAT_: 0 MOTORIO SG_ MOTORIO_HEARTBEAT_cmd : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 281 HEARTBEAT: 0 GEO SG_ GEO_HEARTBEAT_cmd : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 282 HEARTBEAT: 0 ANDROID SG_ ANDROID_HEARTBEAT_cmd : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 283 HEARTBEAT: 0 SENSOR SG_ SENSOR_HEARTBEAT_cmd : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 410 DESTINATION_REACHED: 0 MASTER SG_ SENSOR_HEARTBEAT_cmd : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 420 BATTERY_STATUS: 1 SENSOR SG_ BATTERY_STATUS_VALUE : 0|0@1+ (1,0) [0|0] "" MASTER,MOTORIO
BO_ 610 BOOT_REQUEST: 0 MASTER SG_ BATTERY_STATUS_VALUE : 0|0@1+ (1,0) [0|0] "" MOTORIO,SENSOR,ANDROID,GEO
BO_ 620 BOOT_REPLY_MOTORIO: 0 MOTORIO SG_ BOOT_REPLY_MOTORIO : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 621 BOOT_REPLY_SENSOR: 0 SENSOR SG_ BOOT_REPLY_SENSOR : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 622 BOOT_REPLY_GEO: 0 GEO SG_ BOOT_REPLY_GEO : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 623 BOOT_REPLY_ANDROID: 0 ANDROID SG_ BOOT_REPLY_ANDROID : 0|0@1+ (1,0) [0|0] "" MASTER
BO_ 630 BOOT_STATUS: 0 MASTER SG_ BOOT_STATUS : 0|0@1+ (1,0) [0|0] "" MOTORIO,ANDROID
BO_ 650 SOURCE_COORDINATE: 8 GEO SG_ SOURCE_COORDINATE_LATITUDE : 0|32@1+ (1,0) [0|0] "" ANDROID SG_ SOURCE_COORDINATE_LONGITUDE : 32|32@1+ (1,0) [0|0] "" ANDROID
CM_ BU_ NOONE "No node, used to indicate if it's a debug message going to no one."; CM_ BU_ MASTER "The Master controller driving the car."; CM_ BU_ SENSOR "The Sensor controller of the car."; CM_ BU_ MOTORIO "The Motor-IO controller of the car."; CM_ BU_ ANDROID "The Android controller of the car."; CM_ BU_ GEO "The Geo controller of the car."; CM_ BO_ 100 "Sync message used to synchronize the controllers";
BA_DEF_ "BusType" STRING ; BA_DEF_ SG_ "FieldType" STRING ; BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
BA_DEF_DEF_ "BusType" "CAN"; BA_DEF_DEF_ "FieldType" "";
BA_ "GenMsgCycleTime" BO_ 220 10; BA_ "GenMsgCycleTime" BO_ 210 10; BA_ "GenMsgCycleTime" BO_ 250 10; BA_ "GenMsgCycleTime" BO_ 260 10; BA_ "GenMsgCycleTime" BO_ 280 1; BA_ "GenMsgCycleTime" BO_ 281 1; BA_ "GenMsgCycleTime" BO_ 282 1; BA_ "GenMsgCycleTime" BO_ 283 1; BA_ "GenMsgCycleTime" BO_ 420 1;
VAL_ 100 MASTER_HEARTBEAT_cmd 0 "MASTER_HEARTBEAT_cmd_NOOP" 1 "MASTER_HEARTBEAT_cmd_SYNC" 2 "MASTER_HEARTBEAT_cmd_REBOOT";
Design & Implementation
CAN Communication Table
Sr. No | Message ID | Message function | Message Data | From | To |
---|---|---|---|---|---|
High | |||||
1 | 0x220 | Motor Control (Direction Control- Straight, Left or Right Level of Direction-Level 0, Level1, Level 2 Motion Control- Stop, Forward or Reverse Speed Control - Stop, Level1, Level2 or Level3) |
Byte[0] -> Direction Control Byte[1] -> Level of Direction Byte[2] -> Motion Control Byte[3] -> Speed Control |
Master | Motor |
2 | 0x010 | Kill Message (User request to stop the car under emergency) |
Control Frame. No data bytes. | Android | Master |
3 | 0x020 | Kill Message (Master request to stop all controllers and reboot under emergency) |
Control Frame. No data bytes. | Master | All |
4 | 0x030 | Stop (User request to stop the car) |
Control Frame. No data bytes. | Android | Master |
5 | 0x040 | Stop (Master stops the motor) |
Control Frame. No data bytes. | Master | Motor |
6 | 0x210 | Sensor Data (Distance in cms) |
Byte[0] -> Forward Distance Byte[1] -> Left Distance Byte[2] -> Right Distance Byte[3] -> Back Distance |
Sensor | Master/Motor-IO |
7 | 0x230 | Total Distance to Travel | Byte[0-1] | Android | Geo |
8 | 0x240 | Send Checkpoints | Byte[0-3] -> Latitude Byte[4-7] -> Longitude |
Android | Geo |
9 | 0x250 | Distance (Distance in foot) |
Byte[0-1] -> Final Distance remaining Byte[2-3] -> Checkpoint distance |
Geo | Master |
10 | 0x260 | Turn Angle and Direction | Byte[0] -> Turn Angle Byte[1] -> Direction (1-Left,2-Right) |
Geo | Master |
11 | 0x270 | Run and Pause Command | Control Frame. No data bytes | Android | Master |
12 | 0x280 | Heartbeat Message | Control Frame. No data bytes | Motor | Master |
13 | 0x281 | Heartbeat Message | Control Frame. No data bytes | Geo | Master |
14 | 0x282 | Heartbeat Message | Control Frame. No data bytes | Android | Master |
15 | 0x283 | Heartbeat Message | Control Frame. No data bytes | Sensor | Master |
Medium | |||||
16 | 0x410 | Destination reached. (Stops the car when destination is reached) |
Control Frame. No data bytes | Master | All |
17 | 0x420 | Battery Status | Byte[0-1] | Sensor | Master/IO |
Low | |||||
18 | 0x610 | Boot Request | Control Frame. No data bytes | Master | All |
19 | 0x620 | Boot Reply (Date and time will be sent to Master) |
Byte[0-4] | Motor-IO | Master |
20 | 0x621 | Boot Reply (Date and time will be sent to Master) |
Byte[0-4] | Sensor | Master |
21 | 0x622 | Boot Reply (Date and time will be sent to Master) |
Byte[0-4] | Geo | Master |
22 | 0x623 | Boot Reply (Date and time will be sent to Master) |
Byte[0-4] | Android | Master |
23 | 0x630 | Boot Status (Enable the map and run button in Android) |
Control Frame. No data bytes | Master | Motor-IO/Android |
24 | 0x640 | System Start | Control Frame. No data bytes | Android | All |
25 | 0x650 | Source Co-ordinates | Byte[0-3] -> Source Latitude Byte[4-7] -> Source Longitude |
Geo | Android |
Car Framework and Components
The RC car, Traxxas Stampede, in its raw form consists of a Titan 12T 550 Brushed DC motor, a Servo motor, an XL-5 ESC (Electronic Speed Control) unit, battery and a pre-programmed wireless receiver and controller. The Battery used in the RC car is an 8.4 V, 3000 NiMH from Traxxas. The wireless receiver gets commands from the remote control and drives the motors accordingly, but the DC motor can be controlled only through ESC.
The ESC (Electronic Speed Control) unit is an electronic module, which receives PWM signals from the controller and varies speed and direction of the DC motor and also acts as dynamic brakes. ESCs are often used in RC models. The ESC has the capability to provide dynamic braking depending on the mode in which it is being operated.
Motor and I/O Controller
Hardware Design
Motor Module
The motor module comprises of a servo motor for the direction control and a DC motor for speed control. The servo motor helps the car in turning left and right where as the DC motor on the other hand helps the car move forward and backward. The DC motor used in the project is a brushed motor. Conventionally, brushless motors are faster and more efficient than brushed motors. But, the reason for selecting a brushed motor over a brushless motor is that we employ a dedicated battery for the motor such that we do not have any issues with power and efficiency. Moreover, we need not operate the car at high speeds.
The initial task in the motor module is to find the operating ranges of the motor so that we get to know the output signal range and frequency from the SJONE board which would be replacing the pre-programmed controller. The simplest way to find the operating ranges of the motor is to tap and analyze PWM signal that is being supplied to the motor over an oscilloscope. The results as shown in the below pictures indicate that the operating duty cycle of both the motors lie between 10% to 20% and the frequencies at which the motors operate is 100Hz.
The hardware interface of the Motors and SJONE board includes the following connections.
Sl. No | Connection on the car | Pin on SJSU One Board | Purpose |
---|---|---|---|
1 | Input to DC Motor | P2.1 | PWM input to drive DC motor |
2 | Input to Servo Motor | P2.0 | PWM input to drive DC motor |
3 | Speed sensor | P2.4 | PWM output from speed sensor |
The Motor controller receives the commands from the Master controller which guides it to navigate the car based on the information from the Sensors and GPS. While it does so, it also needs to get feedback from the DC motor and control the motor independently in order to ensure that the car is moving with the speed requested by the Master. This requires increasing or decreasing the actual speed level that is being provided to the Motor in case of movement along uphill, downhill, glass and high friction tracks.
The feedback is achieved through a shaft encoder which works based on Hall-effect. The installation of the speed sensor was pretty easy as we went with the one from Traxass, the same manufacturer as our RC car. It involves removing the DC motor casing, placing the sensor over the spur gear and the magnet holder. The sensor would sense the rotation of the axle. It produces a pulse when the magnet comes into the line of the sensor, which is then detected by the Motor controller.
IO Module
The IO module Consists of a 4 line * 20 characters serial LCD. Data from GPS and sensor module is displayed continuously by refreshing it every second. SJ one board communicates with LCD through UART. GPS data :-
- Latitude
- Longitude
- Final distance remaining
Sensor data:-
- Left sensor reading
- Right sensor reading
- Front sensor reading
- Rear sensor reading
Additionally, IO module controls lighting up headlights/taillights based on the direction of the car movement.
Hardware Interface
LCD unit requires 5V power supply for its working. The VCC and Ground pins are connected to common power supply lines that is used to power up all the boards. The Rx pin of LCD is connected to TXD2 (p2.8) pin on SJ one board. Two of the GPIO pins p2.6 and p2.7 controls the headlights LED’S and taillights LED’S respectively.
Sl. No | Pin on IO Module | Pin on SJSU One Board | Purpose |
---|---|---|---|
1 | Vcc | Common power supply | 5V for LCD |
2 | Ground | Common Ground | Ground for LCD |
3 | Rx | P2.8(TXD2) | Receive data from SJone board through UART |
4 | Headlight LED’s(2) | P2.6 | Turn on headlights when car is moving in the forward direction |
5 | Taillight LED’s (2) | P2.7 | Turn on tail-lights when car is moving in the reverse direction |
Software Design
Motor/IO Module
The controller on boot up initializes the CAN communication, UART and also the PWM for initialization pulse required for the motor to run. The inter-controller communication is done over CAN bus. It is configured to receive and transmit messages at 100K baud-rate. The type of CAN ID is Standard. Later these are accomplished at run time using the periodic scheduler task.
LCD communicates with SJ one board through UART. The UART port is configured to operate at the default baud rate of 9600 bps. “FO” character is sent to initialize the UART port after a delay of 100 ms, upon powering up the board. The display unit responds after 100 ms. Now the LCD module is configured and can receive further messages to display on it. Data from modules such as GPS and sensor are received continuously through CAN. It is decoded, converted into proper format and displayed on the LCD periodically.
The Motor controller, after sending the initialization pulse to the DC motor, waits for a start command from the Master over CAN and then controls the motors in order to reach the destination with required levels of speed and direction. The control algorithm for the Motor operation is as shown below.
Software Implementation
“Can receive” function is called in periodic scheduler 100 Hz task. This function lets the Motor/IO module receive CAN messages from other modules connected to it. CAN set up filter function has been used to accept only essential messages required by this module. Based on the CAN message identifier, corresponding action is performed. These are the CAN messages required by the motor/IO module.
CAN MESSAGE ID:-
- 0x210 – Sensor data
- 0x220 – motor control message from master
- 0x240 , 0x250 – GPS data
Data from sensor and GPS modules are stored in global message buffers. Sensor data is 8 bit whereas GPS data ranges between 16-32 bits. These integer values are converted into character type and then sent to LCD through UART.
LCD display function is called in 1Hz periodic scheduler task. Thus Sensor and GPS data get displayed on the LCD every sec.
The 3D design used as a support for mounting the LCD is shown below:
Motor Control On receiving the CAN message(0x220) from the Master, the data is extracted and and used for specific functions as shown below.
*Byte0 – Servo Direction *Byte1 – Servo Level *Byte2 - DC Direction *Byte3 - DC Level
Based on this data, the first two bytes decide the direction(left/right) and the level(angle), respectively in which the car should turn using the Servo motor. Similaly, the next two bytes decide the direction(forward/backward) and the level(speed) in which the car has to move.
To implement all the motor related functions, we have employed a dedicated task. Initially, the pre-scaled PWM values are fed to the motors based on the direction and level from the Master. We have a bit robust algorithm to obtain these PWM values which has offsets and level multipliers. The advantage of this is we can change the code to function for multiple levels with minimum effort.
Motor Feedback After feeding the motors with the required levels, we have to check if the car is actually moving at that speed. This is ensured through feedback and control based on that. The feedback is obtained through the speed sensor collaborated with the DC motor, which triggers a pulse on every rotation and this is recorded by a rising edge based interrupt. The interrupt callback function increments the number of pulses. A separate logic is used to calculate and then compare the actual and required(from Master) speed levels. The corrective measures are enforced to achieve the desired speed.
The transmit messages, except Heart beat message(sent every one second), are transmitted once every 100ms. The Motor/IO controller, on receiving a boot request from Master controller, transmits a boot reply message in order to let the Master know that it has booted successfully. The heart beat message is transmitted continuously to indicate that the controller is active and this will be acknowledged by the Master.
Master Controller
As the name suggests, it is main controller on the car which interacts with all other controllers over the CAN Bus to achieve real-time functionality. Basic function of the Master Controller is to receive data from Android, Geo and Sensor Modules and develop the algorithm to drive the car autonomously based on the received data through the Motor Controller.
Hardware Design
- RC car was the basic infrastructure that was required to implement the project.
- CAN Bus with five SJone controller boards was integrated on General purpose Printed Circuit Board (PCB).
- Sufficient power-supply ports and external pins were provided to each controllers.
- Flat Ribbon Cables were used to reduce circuit complexity arising from external connecting wires.
Software Design
Algorithm
- Master Controller uses FreeRTOS environment to achieve its functionality.
- It uses Periodic Scheduler Task provided by Preet at its core to communicate with all other controllers.
- The functions of the Periodic Scheduler Task were used in a customized manner to transmit/receive the messages at specific intervals of 1Hz,10Hz,100Hz and 1000Hz.
- File logger function was used to log the real-time data onto SD card which was used for debugging purpose.
- Can Message structure of 11-bit id was implemented to send and receive CAN messages over the CAN Bus.
- CAN acceptance filter was set-up to receive messages specific to Master Controller from the CAN Bus, since it is the broadcast Bus.
Geo-Based :
- Step 1: Check if there is no obstruction. If there is no obstruction proceed to step2, otherwise proceed to step7.
- Step 2: Check if distance towards next check-point is greater than 30. If distance towards next check-point is greater than 30, proceed to step3, otherwise go to Step 6.
- Step 3: Check if turning angle is greater than 10. If turning angle is greater than 10, proceed to step4, otherwise go straight go to step7.
- Step 4: Check if turning angle is greater than or equal to 90. If turning angle is greater than or equal to 90, turn left or right according to the turning bit with level of direction 3 go to step7, otherwise proceed to step5.
- Step 5: Check if turning angle is greater than or equal to 45 and less than 90. If turning angle is greater than or equal to 45 and less than 90, turn left or right according to the turning bit with level of direction 2, otherwise turn left or right according to the turning bit with level of direction 1 go to step7.
- Step 6: Check if distance towards next check-point is less than 10.If the distance is less than 10, stop the car, otherwise move slowly with level of speed 1.
- Step 7: End.
Software Implementation
- Master Controller starts with initialization of CAN Bus and setting up reception filter from the main() function.
- The Periodic Scheduler Task then takes over to implement the actual functionality of the Master Controller.
- CAN_is_busoff() was used at an interval of 10Hz through periodic scheduler task to check if CAN bus was working continuously.
- The basic flow of control is as follows:
Sensor Controller
Sensor controller consists of sonar and ultrasonic sensors that are inter-connected to the SJOne board and CAN bus. The sensors detect if there is any obstacle around the car and report the distance of obstacle.
Hardware Design
MB1010 LV MaxSonar EZ1 Sensor
Hardware design consists of four sensors connected to ports of LPC1758. The sensors in front, right and left direction are MB1010 sensors while the one at back is HCSR04. The sensors are connected to +5V to achieve the highest beam pattern that is available.
The LV MaxSonar EZ detects objects from 0 inches to 254 inches and provides sonar range from 6 to 254 inches with 1 inch resolution. Objects from 0 to 6 inches are reported as 6 inches. Sensor operates at 42KHz. The sensor reports output formats in from of pulse width output, analog voltage output, and RS232 serial output. We have selected pulse width output.The sensor will continually measure range and output if RX data is left unconnected or held high. If held low the sensor will stop ranging. We have commanded a range reading by triggering high for 20uS.
Below are the timing diagrams for the sensor
HCSR-04 sensor
HCSR-04 sensor is a ultrasonic ranging module which detects obstacle from 0 to 400 cm. It is a four pin module – Vcc, trig, echo and Gnd. It includes transmitter, receiver and control circuit. The sensor operates at 40 KHz.It Requires 5V 15mA power supply. When a short 10uS pulse is provided to the trigger input, the sensor will transmit out 8 cycle of ultrasonic burst at 40kHz and makes the echo pin high.The Echo pin is lowered to logic low when the ultrasound burst is reflected off a distant object.To obtain the distance, measure the width (Ton) of Echo pin. Time = Width of Echo pulse, in uS (micro second) Distance in centimeters = Time / 58 Distance in inches = Time / 148 Or you can utilize the speed of sound, which is 340m/s
The 3D design used as a support for mounting the sensors is shown below:
Software Design
Geographical Controller
Geographical Controller consists of GPS and Compass module. GPS module is used to track current position of car, find bearing angle of destination with respect to north and compass module used to know heading of car with respect to north. Difference between heading and bearing gives us turn angle which car have to take to reach destination from current position.
Hardware Design
Schematic
SparkFun Venus GPS with SMA Connector
SparkFun Venus GPS uses Skytraq VENUS634FLPx IC. The Venus638FLPx outputs standard NMEA-0183 or SkyTraq Binary sentences at a default rate of 9600 bps which is adjustable to 115200 bps, with update rates up to 20Hz. We configured this module with update rate of 10Hz and 38400 bps UART rate. Module outputs GGA, GSA, GSV, GLL, RMC, VTG, ZDA NMEA standard messages which can be configures to as per our requirements. We configured it to give only GGA messages.
GGA message format is shown below.
For configuring GPS modules to UART rate 38400 bps, 10Hz update rate and only GGA message at output, below binary commands are used.
HMC5883L
Software Design
The GPS communicates with the SJOne board through the UART and the Compass communicates with the SJOne board through the I2C
I2C Communication
The HMC5883L IC communicates to the SJOne Board through the I2C bus.
SJONE board -Master device
HMC5883L - Slave device
The I2C rate is controlled by the master and can be upto maximum 400 KHz. We have configured the rate as 100 KHz.
Master Transmitter Mode:
In this mode, the master writes to the slave registers.
The compass IC has a set of 8 bit registers to be initially configured for parameters such as device output rate, number of samples, device gain and operating mode. By identifying the device write address and register address, the values can be written by the SJONE board to the compass registers.
Master Receive Mode:
In this mode, the master reads from the slave registers.
The X,Y,Z registers of the compass can be then read by the SJOne board one by one knowing the device read address and register address.The register pointer will be incremented by 1 automatically after the current register has been successfully read.
Android Communication Bridge Controller
Hardware Design
The Communication bridge consists of establishing connection between car and the android phone which is established with the help of bluetooth module HC-05 connected to UART peripheral of SJOne Board. The UART pins on board are connected to bluetooth module in the manner shown in diagram. Once the connection is established between the car and the android phone and signals like 'Start','Stop' and 'Kill' are sent from android phone then they are received by the bluetooth and sent to SJOne board to be further broadcasted over CAN bus.
Software Design
Android Application
Software Design
Testing
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.
Accuracy of GPS Module
Accuracy of GPS module was tested by recording/logging coordinates received by module using LOG_INFO() function and plotting them on Google maps GPS Module Coordinates on Google Maps. GPS module was very much accurate we did not needed to calibrate it. It is observed that more number of satellite locks with module, greater the accuracy of coordinate readings.
Calibration of Compass
As any instrument has instrument error, so has the compass IC. The compass needs to be calibrated for accuracy. We undertook two levels of calibration.
1. Level 1 calibration was done without mounting the compass on car. The compass was rotated in its axis for 360 degrees and the error was identified for every 15 degrees (totally 24 zones) with the setup shown by the image in the left.
2. Level 2 calibration was done after mounting the compass on car.The car setup by itself had some tilt and we compensated it by means of adjusting the hardware mounting. Next, the motor’s EMI caused some magnetic deviation and the motor's influence was taken into account too. The car was rotated in its axis ( its axis being parallel to the compass axis) for 360 degrees with the deviation measured for every 15 degrees(totally 24 zones) with the setup depicted by the image in the right.
The deviation was not uniform for every zone. Using linear regression analysis technique, the relationship between the predictor variable - degrees and the response variable - radians was found in an ideal environment and the same was repeated several times for accuracy. The average of several such readings was taken as the final calibration value.
Motor and Feedback
The motor operation is initially tested for its accuracy with different direction and levels such as forward, reverse, left, right. After ensuring everything is as expected, we went for refining it. Later, with the speed sensor installed, the functioning of it and the control based on it has to be checked properly. For this, we have tested the car by running it over ramp-up, ramp-down, grassy and rough paths. Then we have refined it. Finally, we made sure that the car gets back to the required speed when it deviates from the same.
Technical Challenges
Configuring GPS Module
We faced difficulty in configuring GPS module to sending only $GGA messages, 10Hz Position update rate and updating baud rate to 38400. Initially we were trying to configure GPS module via writing program for SJ One board and we were unable to do it. Later on we completed configuring by connecting GPS module directly to serial port and using GPS Viewer software. Through it we can directly configure GPS module without worrying about binary messages and checksum calculation.
Compass and Calibration
1. Initially the compass was mounted and tested on breadboard with its upper face downwards as the connecting strips are on the upper side. This made the compass produce incorrect values.
2. While reading the registers in compass HMC5883L, only x and y register values are needed. Hence we tried to read only those registers from the device. But it so happened that z register is in between the x and y registers and the read pointer did not advance after the x register was read and remained in the z register. This led to compass producing constant values.
3. While calibrating, the compass should be rotated on a horizontal plane with its axis of rotation fixed. Shifting the axis may result in incorrect values.
4. Having a robust hardware that does not cause any or very less tilt, will reduce the efforts of calibration as HMC5883L IC is not tilt compensated.
5. Calibration should be done in an environment which does not have iron , magnetic particles etc as those may cause magnetic deviation. As the motor module influences the compass with the generated EMI, mount the compass far away from the motor and calibrate with the motor ON to take account of the EMI generated.
Motor Feedback
The major difficulty with motor speed feedback was getting enough number of pulses from the speed sensor in order to calculate the current speed. When we run at very low speeds, we get pulses as low as 2 0r 3 at even 10Hz. If the same value is multiplied by required factor(say 600 in 10Hz) to get the rpm, then we have a couple of issues.
i) Firstly, we cannot get intermediate speed values as we get only in multiples of the the factor which will be very high.
ii) Secondly, we may have some issues, at very low speeds, like we don't get a pulse every 100ms or 10ms, which means the motor is at rest but which actually is not.
Solution: Never try to implement in terms of "rpm". Instead go for "rps" or "m/s". This will eliminate the first issue. And to solve the second problem, we may think of aggregating the pulse count for a greater time interval. But this will lead to a delayed feedback which in turn leads to an undesired behavior. Hence we have a trade-off between the two.
Motor Control
1) The first hurdle one would face with the Motor control through an ESC is starting the motor. This requires an initialization pulse, which would have been sent by the transmitter earlier. We have to realize the required pattern or PWM value for the achieving this. 2) The second difficulty with the motor comes into picture when with backward movement of the car. Due to the presence of the ESC and the resudual momentum in forward direction, we cannot alter the direction of the motor suddenly. We have to manually discover the pattern required for this forward to reverse transition which takes a bit of time unless one is aware of it.
Conclusion
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?
Project Video
Upload a video of your project and post the link here.
Project Source Code
References
Acknowledgement
Any acknowledgement that you may wish to provide can be included here.
References Used
Appendix
You can list the references you used.