F17: Optimus

From Embedded Systems Learning Academy
Revision as of 02:15, 16 December 2017 by Proj user5 (talk | contribs) (Sensor and I/O)

Jump to: navigation, search

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]
  • Geographical Controller:
    • [ Sneha]
    • [ Sarvesh]
  • Master Controller:
    • [ Unnikrishnan]
    • [ Revathy]
    • [ Kripanand]
  • Motor Controller
    • [ Unnikrishnan]
    • [ Rajul]
  • Sensor and I/O Controller:
    • [ Sushma]
    • [ Supradeep]
    • [ Harshitha]

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
  • Decide roles for each team member
  • Read FY16 project reports and understand requirements
  • Setup Gitlab project readme
  • Ordered CAN Tranceivers and get R/C car
  • Team roles are decided and module owners are assigned
  • Gitlab project is set
  • Ordered CAN tranceivers and got R/C Car
Complete.
2 9/30/2017
  • Design software architecture for each module and design signal interfaces between modules
  • Setup Wiki Project Report template
  • Design Hardware layout of system components
  • Create component checklist and order required components for individual modules.
  • Setup Gitlab project code for each modules
  • Overall project requirements are understood
  • Wiki Project report setup is done
  • Odered components for Geo controller module
  • Initial commit of project base is done
Complete
3 10/14/2017
  • Major Feature: Implement Free run mode
    • Implement heartbeat messages and initial system bootup sync between modules
    • Interface the RPLidar to SJOne board via UART
    • Achieve basic communication such as obtaining the device and health info.
    • Study of Android Toolkit for Bluetooth Adapter connections and APIs
    • Study of HC-05 Bluetooth Module
    • Creating APIs for Start/ STOP button requests to write to output-Stream buffers
    • Creating RFComm SPP Connection socket and the rest of UI for basic operation of Pairing, Connection
    • Checking the AT Command sequence for Bluetooth Operation and Pairing
    • Automating the AT Command sequence for Bluetooth HC-05 operation and Android App
    • Run Motors via commands from SJOne Automatically
    • Order the RPM sensor module for the Drive Controller
    • Design and Order PCB
  • Major Feature: Implemented Free run mode
    • Added hearbeat messages from all controllers to master in can_db and implemented the handling functions in master controller
    • Implemented speed steer command CAN msg transmission and handling in Master controller. Master-Drive integration phase-I
    • Interfaced RPLidar to SJOne board and achieved basic communication via UART. Started obtaining data as well.
    • Android:Android API for Bluetooth Adapter connections studied.
    • Android:Learning of AT Command sequence for Bluetooth Operation and Pairing done.
    • Android:Created Start/Stop API's for button requests to be Sent to HC-05 IC.
    • Android:Basic Pairing Operation Working.
    • Motor: ESC Traxxas XL-5 (Electronic Speed Control) interfaced to SJOne board
    • Tested and identified duty cycles for different speeds required; Callibration and testing of ESC is over exteral switch at P0.1
    • Ordered RPM sensor
Complete
4 10/21/2017
  • Major Feature: Implement Basic Obstacle Avoidance in Free-run mode
    • Add all modules CAN messages to DBC file
    • Test steer and speed CAN commands between Master and Motor
    • Implement Obstacle avoidance algorithm
    • Obtain data from the lidar and process the data i.e. decide on the format in which the data has to be sent to the master
    • Write unit test cases for the lidar.
    • Interface compass module to SJOne board and calibrate the errors
    • find the heading and bearing angle based on mocked checkpoint
    • Test and verify GPS module outdoor to receive valid data and check for errors
    • Calibrate the GPS module error
    • Design and implement the DRIVE_CONTROLLER STEER/SPEED interface with Master (TDD)
    • Install the new RPM sensor module for the Drive Controller
    • Operating motors based on the CAN messages from the Master
  • Major Feature: Implemented Free-run mode w/o obstacle avoidance
    • Added all modules basic CAN messages in can_db
    • Implemented interface files in master controller to handle CAN messages from all nodes to master
    • Implemented Master-Drive controller Integration
    • Implemented Master-Bluetooth controller integration
    • Added all modules basic CAN messages in can_db
    • GPS integrated to SJONE board
    • Added all modules basic CAN messages in can_db
    • Wrote unit test cases for the LIDAR.
    • Wrote logic for dividing the information obtained from the lidar into sectors and tracks.
    • MASTER_SPEED_STEER_CMD was defined to use 8-bits for speed control (neutral, forward, and reverse); 9-bits for steer control (straight, left, and right)
    • Designed glue code: DriveManager and hardware interface code: DriveController using TDD (test code in _MOTOR/_cgreen_test/)
    • Got the Traxxas #6520 RPM sensor; installed the same with the slipper clutch; Observed the RPM sensor trigger over an oscilloscope and found the minimum distance of magnet to RPM sensor is not achievable with the stock slipper clutch. Ordered Traxxas #6878 new slipper clutch and ball-bearings
    • Master - Drive Controller Interface implemented and tested over CAN; Check "drive" terminal command on Master controller
complete
5 10/28/2017
  • Major Feature: Implement maneuvering in Master controller
    • Implement maneuvering algorithm to drive steering angle of the servo
    • Implement maneuvering algorithm to control ESC speed
    • Test and validate the information obtained from the sensor.
    • Send the Lidar data and heartbeat over CAN.
    • LIDAR should be fully working.
    • Identify the basic speed(s) at which the car shall move; the min, max and normal forward speeds, and the min and normal reverse speeds
    • Interface the RPM sensor over ADC and validate the readings
    • Writing PID Algorithm for Motor Control
    • Calibrating PID constants according to the Motors
    • Testing the Bluetooth Range and multiple pairing option to establish security of the Master device
    • Testing the accuracy of GPS while moving
    • Made the code modular and added the wrapper function for all the important modules
    • Worked on android app which will dump the lattitude and longitude information for checkpoints
    • Test the accuracy of GPS while moving
    • Get the code review done and do the testing after that
    • Worked on the Android app that will dump the checkpoints into a file
    • Finish PCB design and place order
  • Major Feature: Implemented maneuvering in Master-Geo controller
  • Major Feature: Implemented Basic Obstacle Avoidance in Free-run mode
    • Implement maneuvering algorithm in android app is moved to next week schedule
    • Implemented maneuvering algorithm in Master to drive steering angle of the servo
    • Implement maneuvering algorithm in Master to control ESC speed
    • Unit Testing obstacle avoidance algorithm
    • Tested and validated the sensor data by plotting graphs in an EXCEL sheet.
    • Sending the obstacle information and heartbeat over CAN.
    • LIDAR fully working and sending obstacle information.
    • Identified basic speeds, slow, normal, and turbo for forward and reverse
    • Interfaced the RPM sensor over GPIO and validated; but the clutch gear with magnet was far apart from the RPM Sensor
    • Wrote the PID code keeping future integration in mind; Have pushed the code
    • Failed to use RPM sensor - new clutch gear also did not work (magnet is too far away - validated with Oscilloscope); Have to consider using IR sensor for feedback
    • Android:Tested successfully individual and multiple Device pairing.
    • Android:Android app updated with Navigation and Drawer Modules with Detecting NAV points.
    • Tested the accuracy of GPS while moving
    • Made the GPS and compass code modular and checked the functionaity after the changes
    • Worked on the Android app that will dump the checkpoints into a file
    • Completed PCB Design
Complete
6 11/07/2017
  • Major Feature: Implement maneuvering with mocked GEO checkpoints
    • Collect mock checkpoints using the Android Data Collector application
    • Collect mock checkpoints using the GEO module and compare for any discrepancies
    • Identify I/O on-board Display information; Currenly identified are documented below:
    • Health status like GPS Lock status, etc.
    • Identify hardware to check battery-status and procure the same; update PCB as well
    • Display bluetooth pairing status
    • Test on-board I/O module for bluetooth pairing status
    • In case RPM installation/usage fail, Identify new mechanism for feedback and order components; Update PCB as well to include new hardware
    • Implement simple feature additions on steer control to handle reverse; basically steering rear-left and rear-right has to be practically implemented on motor/drive controller
    • Receive GEO Controller's Turning-angle message and compute target steer
    • Use GEO Controller's distance to next-checkpoint information to compute target speed
    • Mock checkpoint navigation testing using different possible obstacle heights and forms possible
    • Identify advertisement messages on the DBC file and add documentation in Wiki; Currently identified advertisements: a) current GEO location, b) SENSOR radar map
    • Shall define the BLE Controller to android message structure and message generation-intervals (classify on-demand advertisements and periodic advertisements)
    • Implement marker for current location display - which is an on-demand advertisement
    • Implement feature for the user to enter destination - a Google Map View shall be shown to the user to confirm route from source(current car location) to destination
    • Android app (once on the new device) shall download the entire offline map information of the SJSU campus and store it on a SQLite database
  • Major Feature: Implemented maneuvering with mocked GEO checkpoints
    • Provided Mock checkpoints and used the heading and bearing angle logic to get the turning angle
    • Collected mock checkpoints and check for the error with different places
    • Interfaced the Sparkfun Seven segment display with the SJOne Board.
    • Implemented interface method to receive GEO Controller's Turning-angle message and set target steer
    • Target speed is not changed between checkpoints.So geo feedback for distance to destination is not used in design
    • Destination Reached flag is tracked to stop the car on reaching destination
    • Checkpoint Id CAN signal is processed by Master to start the car once destination is selected
    • Android:Implemented Marker for current position Display.
    • Android:User entry for setting up destination on MAP done.
    • RPM Installation failed, but could get auxiliary hardware (motor pinion) from local shop and get it working
    • Implemented basic motor feedback using hall sensor (RPM sensor); tested working on ramps
    • Steer left and right on reverse now follows natural order; Could not finish literal reverse-left and reverse-right implementation; Moved this task forward; Had to test and implement motor feedback this week
    • Defined the BLE Controller messages to android in JSON message structure and message generation-intervals (classify on-demand advertisements and periodic advertisements)
    • On Demand Advertisement- Current Marker Location
    • Draggable Destination Marker for final destination and intermittent checkpoint transmission to GEO from Android via BLE
    • Marking the checkpoints with HUE_BLUE color to do better tracking of the navigation.
    • Added multi state BT options and Added restrictions on buttons like NAV usage dependency on BT Connection, Powerup button dependency on NAV setup before actually powering the car.
Complete
7 11/14/2017
  • Major Feature: Implementing maneuvering with Android app supplied GEO checkpoints with on-board I/O
    • Use mock data from file to compute: a) Heading b) Bearing -> use Haversine's algorithm to compute turning angle
    • Advertise distance to the next checkpoint (again using Haversine's algorithm)
    • Save the proper checkpoints for one route (Clark's to SU) to SDCARD on GEO Controller
    • Implement system start/stop triggers from different use cases
    • Turning angle offset of -10,10 is added to take right / left turn
    • Implement the battery-status DBC Message advertisement
    • Indicate checkpoint proximity using backlight indicators
    • Create 2 CAN messages for Disgnostic and I/O data to transmit it to BLE module
    • Receive the diagnostic CAN message and decode to transmit it to Android App
    • [Android I/O:] Design Android app views for visualizing Diagnostic and I/O data
    • Test and validate success/fail cases for on-board I/O display information(as defined above)
    • Update PWM pulses to match MASTER's target speed with proper feedback from the identified feedback-mechanism
    • Identify PID constants kp, ki, kd and evaluate performance against the basic feedback implementation
    • Finalize feedback algorithm and fine-tuning
  • Major Feature: Implemented maneuvering with Android app supplied GEO checkpoints with on-board I/O
    • [Geo:] Implemented mock data from file to compute: a) Heading b) Bearing -> used Haversine's algorithm to compute turning angle
    • [Geo:] Advertised distance to the next checkpoint (again using Haversine's algorithm)
    • [Geo:] Saving the checkpoints in SDCARD on GEO Controller
    • battery-status is optional feature. Planning for later
    • Indicate checkpoint proximity using backlight indicators
    • [BLE:] Created CAN messages for Telemetry data from all modules to BLe to send to Android
    • [BLE:] Received Telemetry messages are transmitted to Android App
    • [Android I/O:] Android app views created for visualizing Telemetry data
    • Test and validate success/fail cases for on-board I/O display information
    • Update PWM pulses to match MASTER's target speed with proper feedback from the identified feedback-mechanism
    • Finalize feedback algorithm and fine-tuning
Complete.
8 11/21/2017
  • Major Feature: Complete maneuvering implementation with Android app and Android I/O
    • [Android I/O:] Implement display of Sensor Obstacle Information on a RADAR map
    • [Android I/O:] Dynamically update car's Current location on the map's route path
    • [Android I/O:] BT Auto Connection and Pairing implemented
    • [Android I/O:] Health information from BLE Controller, namely battery, GPS lock status, and motor speed shall be updated
    • [Android I/O:] BT Auto connect implementation and re-connection on disconnection.
    • Test achievable target speeds with different possible obstacle heights and forms possible, and ground conditions
  • Major Feature: Completed maneuvering implementation with Android app
    • [Android I/O:] Sensor obstacle LIDAR information has been updated on the app
    • [Android I/O:] Dynamic update of Car's current location and intermittent checkpoints implemented.
    • [Android I/O:] Health information from BLE Controller, namely GPS lock status, and motor speed has been updated on the Dashboard of the app.
    • [Android I/O:] Completed BT Auto connect implementation and re-connection on disconnection.
Complete.
9 11/28/2017
  • Major Feature: Full feature integration test
    • Execute the test plan created above [Planned for 11/14] (check Testing documentation in Wiki)
    • Execute the test plan created above [Planned for 11/14]; Phase 1: Test all identified cases for ground-conditions (grass, inclines, etc)
    • Execute the test plan created above [Planned for 11/14]; Phase 2: Test all identified cases for GPS routes and obstacle forms
  • Major Feature: Full feature integration test
    • Integration testing with all controllers and Android App to select routes and send checkpoints from App to Ble.
Complete.
10 12/5/2017
  • Major Feature: Full feature integration test
    • Execute the test plan created above [Planned for 11/14]; Phase 3: Test all identified cases for speed levels and on-board I/O validation
    • Execute the test plan created above [Planned for 11/14]; Phase 4: Test all identified cases for [Android I/O] validation
  • Major Feature: Full feature integration test
    • Integration testing with Android App with Debug view/Dash board with sensor and GPS data
Complete
11 12/12/2017
  • Major Feature: Full feature integration test
    • Execute the test plan created above [Planned for 11/14]; Phase 5: Test all identified cases for desired Turbo mode(s)
  • Update Wiki Complete Report
  • Major Feature: Full feature integration test
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:


Hardware Schematic

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

Motor Hardware Schematics
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
DC Motor
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.

Servo Motor
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.





Digital Oscilloscope readings for the motors

Hall-Effect Principle.
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.

Flowchart.
Speed Feedback Implementation.

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.


Interface with the CAN Hardware

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.

Master Controller Execution Flow

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.


Free Run Mode Flow Chart

Navigation mode

  • 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.


Navigation Mode Flow Chart

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.


Ribbon Breakout
Ribbon Cable

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