Difference between revisions of "S19: CANT Bus"

From Embedded Systems Learning Academy
Jump to: navigation, search
(→‎Motor)
(→‎Software Design)
Line 385: Line 385:
 
* Initializes CAN, servo PWM (50Hz), motor driver board PWM (100Hz), interrupt for hall sensor, and speed calibration<br>
 
* Initializes CAN, servo PWM (50Hz), motor driver board PWM (100Hz), interrupt for hall sensor, and speed calibration<br>
 
'''1Hz Task'''  
 
'''1Hz Task'''  
−
* Used to check the state of CAN. If it's off, LED 1 turns off to indicate that bus is off.<br>
+
* Used to check the state of CAN and reset.<br>
 
'''10Hz Task'''
 
'''10Hz Task'''
−
* Sets PID controller target and feedback values
+
* Receive CAN message for Motor Control
−
* Sets the direction of the motor based on control values
+
* Send Motor Status
−
* Converts motor RPM to duty cycle using with the exponential moving average value
+
* Send Motor Speed
−
* Sends feedback to control (speed and direction) <br>
 
−
'''100 Hz Task'''
 
−
* Receives CAN messages from control and sensors. Control provides speed, direction, and steering angle. We use the sensors data to display it on the LCD display.
 
−
|}
 
  
 
{| class="wikitable"
 
{| class="wikitable"

Revision as of 20:06, 22 May 2019

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.

Project Title

[C]ompile [A]nother [N]on-[T]rivial Bus

Abstract

Design and implement an autonomous car to navigate to a destined location chosen by the user using a phone application. The user will set gps coordinates via an Android application while the current location is processed. The RC car should be able to use these coordinates to navigate itself to the destined location avoiding obstacles and providing useful data on the way. Several objectives need to be completed in order for the RC car to function properly: integrate proximity sensors, gps, compass, lcd screen, motor driver board, esp32 communication, hall sensor, and overall integration in order for the RC car to be able to determine where it is, the speed it's going, and the environment around it to successfully navigate to the final destination.

Introduction

The purpose of this project was to convert a RC car into a self driving vehicle that can navigate itself to a destination sent via an Android mobile app. To achieve this, the project was divided into 7 modules: Avoidance, Motor, Master Driver, Localize, Comms, and Android Application. In order to complete these modules basic knowledge of I2C, UART, SPI, and CAN bus protocols, gpio control, PWM control, phone application development, and pathing algorithms. The Avoidance module contains 8 IR sensors that allow the car to see the world around it. This module finds objects and measures the distance between it and the object. Motor controls a brushed motor which drives the car at various speeds and a servo to turn the car. In addition, Motor also contains a hall effect sensor that keeps track of the cars speed. Localize tells the car where it is in relation to where it needs to go. It contains a GPS and Compass to provide current coordinates and heading. Comms houses the wireless device that talks to the the mobile app as well as an LCD display to show various car data such as speed and destination. The mobile app is where the user can enter GPS coordinates as a destination point, or alter the current destination with a way-point. Lastly, the Driver receives the data from all modules and decides how the car shall react.

Team Members & Responsibilities

  • Kevin Chan
    • IR sensors (Proximity), Compass (Localize), GPS(Localize), Code Review
  • Khrysta Finch
    • Chassis, Driver (Driver), LCD display (Comms), Schematic, Telemetry (Comms)
  • Andrew Javier
    • Hall Sensor (Motor), Wireless communications via esp32(Comms), GPS (Localize), Chassis
  • Aaron Lee
    • GPS (Localize), Pathing Algorithm (Comms)
  • Jonathan Rojas
    • Motor (Motor), Servo (Motor), Motor driver board (Motor), hall sensor (Motor), Cable Management, Chassis
  • Vijay Vanapalli
    • GPS (Localize), Wireless communications via esp32(Comms), Mobile app (Comms)
  • Nelson Wong
    • Team Leader, Driver (Driver), Telemetry (Comms), PCB/Schematic, Chassis, Mobile App (Comms), Power, Code Review


Source Code

Gitlab Project Link


Modules

  • Comms
    • Andrew Javier
    • Vijay Vanapalli
    • Khrysta Finch
  • Android Application
    • Vijay Vanapalli
  • Testing Team
    • Kevin Chan
    • Nelson Wong


Schedule

Show a simple table or figures that show your scheduled as planned before you started working on the project. Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals. The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.

Week# Start Date End Date Task Description Status Completion Date
1 3/4 3/10
  • Strategize approach
  • Determine tasks
  • Assign tasks
  • Draft architecture
 Complete
2 3/11 3/17
  • Finalize architecture
  • Order parts
  • Begin electrical schematic and PCB design
3 3/18 3/24
  • Finalize electrical schematic and PCB design
  • Begin code design per subsystem (must include UT!)
4 3/25 3/31
  • Continued code design and editing
  • Begin app dev
  • Order PCB
5 4/1 4/7
  • Hardware assembly
  • Code review
6 4/8 4/14
  • App dev complete
  • Continue HW assembly
  • Begin outdoor testing
7 4/15 4/21
  • Review, Revise, Retest
8 4/22 4/28
  • Review, Revise, Retest
  • Code lock at end of the week
9 4/29 5/5
  • To be determined
10 5/6 5/12
  • To be determined

Parts List & Cost

Item# Part Desciption Vendor Qty Cost
1 RC Car Traxxas 1 $250.00
2 CAN Transceivers MCP2551-I/P Microchip [1] 8 Free Samples

Printed Circuit Board

<Picture and information, including links to your PCB>

PCB and Schematic

CAN Communication

CAN BUS Messages

VERSION "0.1.0"

BU_: MASTER SENSOR MOTORIO GEO APP

BO_ 101 MOTOR_CMD: 2 DRIVER 

SG_ MOTOR_CMD_steer : 0|3@1+ (1,-1) [-1|1] "degrees" MOTOR
SG_ MOTOR_CMD_drive : 8|4@1+ (1,-2) [-2|5] "" MOTOR

BO_ 200 AVOIDANCE_LIDAR: 8 AVOIDANCE 

SG_ LIDAR_f_right : 0|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_f_middle : 8|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_f_left : 16|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_b_right : 24|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_b_middle : 32|8@1+ (1,0) [0|0] "cm" DRIVER
SG_ LIDAR_b_left : 40|8@1+ (1,0) [0|0] "cm" DRIVER

BO_ 301 LOCALIZE_IMU: 8 LOCALIZE 

SG_ IMU_STATUS : 0|8@1+ (1,0) [0|0] "" DRIVER,COMMS
SG_ IMU_COMPASS : 8|12@1+ (0.1,0) [0|360.0] "degrees" DRIVER,COMMS

BO_ 500 SET_WAYPOINT: 8 COMMS 

SG_ SET_WAYPOINT_LAT : 0|24@1+ (0.000001,37.000000 
[37.000000|38.000000] "degrees" DRIVER
SG_ SET_WAYPOINT_LONG : 24|24@1- (0.000001,-122.000000) 
[-122.000000|-121.000000] "degrees" DRIVER

CM_ BU_ DRIVER "The Driver controller of the car";

CM_ BU_ MOTOR "The motor controller of the car";

CM_ BU_ AVOIDANCE "The avoidance controller of the car";

CM_ BU_ LOCALIZE "The localize controller of the car";

CM_ BU_ COMMS "The Bluetooth/App controller of the car";



Hardware Design

<Show your CAN bus hardware design>

CAN Communication

243.dbc 

VERSION "1.0"

NS_ :
    BA_
    BA_DEF_
    BA_DEF_DEF_
    BA_DEF_DEF_REL_
    BA_DEF_REL_
    BA_DEF_SGTYPE_
    BA_REL_
    BA_SGTYPE_
    BO_TX_BU_
    BU_BO_REL_
    BU_EV_REL_
    BU_SG_REL_
    CAT_
    CAT_DEF_
    CM_
    ENVVAR_DATA_
    EV_DATA_
    FILTER
    NS_DESC_
    SGTYPE_
    SGTYPE_VAL_
    SG_MUL_VAL_
    SIGTYPE_VALTYPE_
    SIG_GROUP_
    SIG_TYPE_REF_
    SIG_VALTYPE_
    VAL_
    VAL_TABLE_
BS_:
BU_: COMMS DRIVER LOCALIZE MOTOR AVOIDANCE
BO_ 10 KILL_MOTOR: 1 DRIVER
 SG_ KILL_MOTOR_cmd : 0|8@1+ (1,0) [0|0] "" MOTOR,COMMS
 
BO_ 11 KILL_MOTOR_REMOTE: 1 COMMS
 SG_ KILL_MOTOR_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER 
 
BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
 SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" LOCALIZE,COMMS,AVOIDANCE,MOTOR 

BO_ 101 MOTOR_CMD: 2 DRIVER
 SG_ MOTOR_CMD_steer : 0|6@1+ (1,-30) [-30|30] "degrees" MOTOR
 SG_ MOTOR_CMD_drive : 8|7@1+ (1,0) [0|100] "" MOTOR

BO_ 200 AVOIDANCE_LIDAR: 8 AVOIDANCE
 SG_ LIDAR_f_right : 0|8@1+ (1,0) [0|0] "cm" DRIVER
 SG_ LIDAR_f_middle : 8|8@1+ (1,0) [0|0] "cm" DRIVER
 SG_ LIDAR_f_left : 16|8@1+ (1,0) [0|0] "cm" DRIVER
 SG_ LIDAR_b_right : 24|8@1+ (1,0) [0|0] "cm" DRIVER
 SG_ LIDAR_b_middle : 32|8@1+ (1,0) [0|0] "cm" DRIVER
 SG_ LIDAR_b_left : 40|8@1+ (1,0) [0|0] "cm" DRIVER

BO_ 300 LOCALIZE_GPS: 8 LOCALIZE
 SG_ GPS_STATUS : 0|8@1+ (1,0) [0|0] "" DRIVER,COMMS
 SG_ GPS_TX_LATITUDE : 8|24@1+ (0.000001,37.000000) [37.000000|38.000000] "degrees" DRIVER,COMMS
 SG_ GPS_TX_LONGITUDE : 32|24@1- (0.000001,-122.000000) [-122.000000|-121.000000] "degrees" DRIVER,COMMS

BO_ 301 LOCALIZE_IMU: 8 LOCALIZE
 SG_ IMU_STATUS : 0|8@1+ (1,0) [0|0] "" DRIVER,COMMS
 SG_ IMU_COMPASS : 8|12@1+ (0.1,0) [0|360.0] "degrees" DRIVER,COMMS
 
BO_ 302 SPEED: 8 LOCALIZE
 SG_ SPEED_kph : 0|16@1- (0.001,0) [-5|10] "kph" COMMS,DRIVER
 
BO_ 400 MOTOR_STATUS: 1 MOTOR
 SG_ MOTOR_STATUS_data : 0|8@1+ (1,0) [0|0] "" COMMS,DRIVER
 
BO_ 500 SET_WAYPOINT: 8 COMMS
 SG_ SET_WAYPOINT_LAT : 0|24@1+ (0.000001,37.000000) [37.000000|38.000000] "degrees" DRIVER
 SG_ SET_WAYPOINT_LONG : 24|24@1- (0.000001,-122.000000) [-122.000000|-121.000000] "degrees" DRIVER

BO_ 501 SET_STATUS: 1 COMMS
 SG_ SET_STATUS_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ LOCALIZE "The localization controller of the car";
CM_ BU_ AVOIDANCE "The collision avoidance controller of the car";
CM_ BU_ COMMS "The wireless comms and telemetry controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ BO_ 501 "0: stop, 1: ready, 2: navigate, 3: skip/next"
BA_DEF_ "BusType" STRING ;
BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
BA_DEF_ SG_ "FieldType" STRING ;
BA_DEF_DEF_ "BusType" "CAN";
BA_DEF_DEF_ "FieldType" "";
BA_DEF_DEF_ "GenMsgCycleTime" 0;
BA_ "GenMsgCycleTime" BO_ 500 100;
BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 101 100;
BA_ "GenMsgCycleTime" BO_ 400 100;
BA_ "GenMsgCycleTime" BO_ 200 100;
BA_ "FieldType" SG_ 500 DBC_TEST1_enum "DBC_TEST1_enum";
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
VAL_ 500 DBC_TEST1_enum 2 "DBC_TEST1_enum_val_two" 1 "DBC_TEST1_enum_val_one" ;
VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;

Proximity ECU

<Picture and link to Gitlab>

Hardware Design

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Unreliable sonor sensors

<Problem Summary> <Problem Resolution>


Motor ECU

Figure X: Architecture of Motor Controller

Hardware Design

Software Design

Motor

| Periodic Init

  • Initializes CAN, servo PWM (50Hz), motor driver board PWM (100Hz), interrupt for hall sensor, and speed calibration

1Hz Task

  • Used to check the state of CAN and reset.

10Hz Task

  • Receive CAN message for Motor Control
  • Send Motor Status
  • Send Motor Speed

Technical Challenges

<Bullet or Headings of a module>

Unreliable Servo Motors

<Problem Summary> <Problem Resolution>


Localize ECU

Figure X: Geographic Controller

Hardware Design

The geographical/localization controller (SJOne board) was connected to a compass and GPS module.

Figure X: MPU-9255 Block Diagram

The compass that we are using for this project is an MPU-9255 which consist of an accelerometer, gyrometer, and three-axis magnetometer. For our purpose, only the magnetometer is used to find the direction of where the car is facing, which connects to the geographical controller via I2C. As you can see in the block diagram from this module, we will only need to connect to the AUX_DA (EDA) and AUX_CL (ECL), from the compass, to the SDA2 and SCL2, respectively. The connections to the auxiliary ports of this module will bypass the accelerometer and gyrometer completely.

The GPS module that was selected was a Ublox Neo-6M module. The GPS communicates with the geographical controller via UART.

Software Design

For the compass, the get_data() modules is being called periodically in the c_periodic_callbacks file in the 100 Hz function. We want the sensor data to be sent to the CAN bus at a 20 Hz frequency, which is implemented by using an if-statement and a modulo 5 on the count variable which results to updated sensor value at 20 Hz: if(count % 5 == 1){}

The get_data() function will return a structure called 'compass_t'. In this structure, it groups three data values for the heading of the compass, the x and y-raw value of the magnetic flux density as a signed 16-bit integer and the calculated heading, which returns as a float. When calling the get_data() functions, it retrieves the X and Y-raw values of the magnetic flux density and then calculates the heading as shown in the diagram below.

Figure X: Compass Heading Calculation Flow

Technical Challenges

  • Initial Communication with Device
    • When referring to the datasheet for the MPU-9255 magnetometer, the connections of the SJ One board was originally connected from the SCL2 and SDA2 to MPU-9255's SCL and SDA pins, respectively. When trying to read the magnetometer data from the specified X and Y MSB/LSB registers, no values were being returned. This had to do with a Pass-by mode that needed to be configured when initializing the accelerometer/gyrometer/magneotmeter. By revieewing the block diagram of the MPU-9255, we saw that it is possible to ignore the accelerometer and gyrometer altogether. So the compass data was accessed by connecting to the ECL and EDA pins on the breakout board instead.
    • For the compass [3], the data sheet stated that the I2C device address is 0x0C. When trying to read the 'Who Am I' register at address 0x00 using I2C, this was used to see that the communication was working properly between both devices. It should return a 0x48 in response. However, we were not able to get any data being read from the register. Using the terminal command 'i2c discover', the device address of the magnetometer was found to be 0x18 instead which is 0x0C << 1.
  • Single Measurement of Compass
    • When initializing the compass/magnetometer, we check the "Who Am I" register to make sure that the device is communicating properly with the geographical controller. Then, it is set to a continuous measurement mode by setting one of the bits in the control register. After doing this, the expected behavior was that X and Y raw values of the magnetometer would be read continuously. However that was not the case because when we tried accessing the register for a new measurement, it would read the same value as before. The solution for this problem was to initiate a soft reset after every measurement is made. After the soft reset, we would have to re-initiate the compass again.
  • Heading of Compass
    • For finding the degrees values with the compass with respect to North, there was a problem where the degrees was not being calculated properly for quadrants two and three. Using arc tangent to calculate the heading value, this only works within the domain of -pi/2 to +pi/2, which is for quadrant 1 and 4. To solve this problem, a different logic was applied where it was based with respect to the WEST and SOUTH poles. After figuring this out, the compass was able to rotate and change as expected for quadrants 2 and 3. The get_heading() function is implemented as shown in Figure X: Compass heading calculation Flow.


<Bullet or Headings of a module>

Unreliable GPS lock

<Problem Summary> <Problem Resolution>


Comms ECU & LCD

<Picture and link to Gitlab>

Hardware Design

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Insane Bug

<Problem Summary> <Problem Resolution>


Driver Module

<Picture and link to Gitlab>

Hardware Design

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Improper Unit Testing

<Problem Summary> <Problem Resolution>


Mobile Application

<Picture and link to Gitlab>

Hardware Design

Software Design

<List the code modules that are being called periodically.>

Technical Challenges

<Bullet or Headings of a module>

Wifi Link Reliability

<Problem Summary> <Problem Resolution>


Conclusion

<Organized summary of the project>

<What did you learn?>

Project Video

Project Source Code

https://gitlab.com/cant-bus/cant-bus

Advise for Future Students

<Bullet points and discussion>

Acknowledgement

References

[1] MPU-9255 Data Sheet

[2] MPU-9255 Register Map

[3] Magnetometer Data Sheet

Retrieved from "http://socialledge.com/sjsu/index.php?title=S19:_CANT_Bus&oldid=53819"