Difference between revisions of "F17: Optimus"

Parts List & Cost

The Project bill of materials is as listed in the table below.

CAN Communication

System Nodes : MASTER , MOTOR , BLE , SENSOR , 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

• Sneha Shahi
  
• Sarvesh Harhare
  

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

Software Design and Implementation

Design & Implementation

Hardware Interface

Software Design

Testing & Technical Challenges

Motor Controller

Group Members

• Shilpa Srinivasan
  

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

• 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

• Ankita Singhal
  
• Sukriti Choudhary
  

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.

• 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

• Gitlab Code Link

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