Difference between revisions of "S20: Nimble"

Latest revision as of 04:45, 23 May 2020

Nimble Logo

Nimble Autonomous RC Car

Abstract

In this project, an autonomous vehicle framework for an RC car is presented using dedicated ECUs for motor control, on-board LCD display, steering control, sensor information handling, and communication bridging. A mobile application was also developed that allows for a user to set a destination, and receive updates on the RC car's position via a Bluetooth connection to the GPS unit. CAN communication between sensors and ECUs was defined via a DBC file. Code was developed using test-driven design principles in order to lower time spent debugging. Unit testing was performed using the CMock framework.

Introduction

The project was divided into these modules:

• Sensor node
• Motor node
• Driver node
• GPS node
• Bridge control node
• LCD node
• Mobile application

The objective was to create an autonomous vehicle that could navigate to a given GPS coordinate sent via a mobile application. The vehicle moves towards the target position Using a pre-compiled list of checkpoints, and handles obstacles along the way via its ultrasonic and infrared sensors. Updates on Nimble's position are sent to the mobile application via bluetooth.

Flow chart of RC car module interaction

Team Members & Responsibilities

• Tanmay Chandavarkar LinkedIn Gitlab
  
  • Sensor Module
  • RC Integration and testing
  • Wiki

• Yuming Cheng Gitlab
  
  • Motor Module
    • GPS Module
    • Driver Module (Master Module)
    • LCD display
    • RC Integration and testing
  • Wiki

• Ellis Makwana LinkedIn Gitlab
  
  • Sensor Module
  • Wiki

• Naeem Mannan Gitlab
  
  • Wiki
  • Mobile Application
  • Bridge Controller

• Francesco Vescio Gitlab
  
  • Wiki
  • Code Review

• Lawrence Wan LinkedIn Gitlab
  
  • GPS Module
  • Driver Module (Master Module)
    • Motor Module
    • LCD display
    • Sensor Module
    • Bridge Module
  • RC Integration and testing
  • Wiki

Team Deliverables Schedule

Parts List & Cost

Printed Circuit Board

Design and Architecture

The PCB made for the Project Nimble RC car was initially designed in EAGLE, however, due to the board size limitations, the PCB had to be designed using DipTrace instead. This design was the first and only iteration in designing the layout of the PCB. The design of the PCB was designed around the four SJTWO LPC4078 micro-controllers required for us to use for the project, the DRIVER, MOTOR, GEOGRAPHICAL, and BRIDGE/SENSOR nodes. The PCB layout consists of four through-hole "slots" where the controllers will be connected (with respect to the controllers' orientation and ports/pins) to the PCB. The power section includes a USB socket as well as a through-hole mount for a LM7805 regulator. Through-hole header pins are also included for the components needed for their respective controllers such as the sensors, LCD, GPS, Compass, etc.. LED circuits were added to provide visual information for the user to indicate the motor and servo motion states, as well as to indicate if a sensor has detected an object. Lastly, the design for the CAN bus includes the connections needed for power, RX/TX, and the CAN low and CAN high bus. The dimensions of the PCB are approximately 4 by 9 inches.

Fabrication

Fabrication of the PCB design was done by JLCPCB located in Hong Kong. The PCB was designed using 2-layers and lead-free coating. The fabrication was done relatively quickly, however, due to the COVID-19 outbreak, delivery of the PCB was delayed.

Challenges

Some challenges encountered when designing the PCB was the delay in pinout information needed to begin designing the PCB. It is advised to order parts early and determine what ports/pins are needed as soon as possible to begin designing and ordering the PCB. Another challenge was some issues with the files needed to be manufactured. Since the design had to be designed using DipTrace instead of EAGLE, exporting the necessary files needed to order for fabrication is slightly different than EAGLE.

CAN Communication

All the controllers on Nimble communicate with each other via CAN(control area network) bus with termination resistors. 120-ohm termination resistors avoid signal reflection. Can is basically a broadcast bus that operates on standard baud rates like 100K, 125K, 250K, 500K, or 1Mbps. It is based on half-duplex communication over a differential pair.

CAN communication is based on the priority of messages in case of bus arbitration. A lower ID message always has a higher priority. Nimble’s DBC is shown in the next section which is used to generate CAN messages

To detect modules that are missing in action due to error in reception, MIA is configured. It replaces the data with safe values when the communication cuts off. Below is an example snippet of code that configures CAN MIA for the driver controller which sets default values for data sent from the sensor, geographical, and motor controller. It also configures a mia threshold which is the amount of time that should pass before an MIA should occur and replace the values for its respective module data structure.

 const uint32_t dbc_mia_threshold_SENSOR_DATA = 10 * 100;
 const uint32_t dbc_mia_threshold_COMPASS = 10 * 100;
 const uint32_t dbc_mia_threshold_MOTOR_DATA = 10 * 100;
 
 const dbc_SENSOR_DATA_s dbc_mia_replacement_SENSOR_DATA = {};
 
 const dbc_COMPASS_s dbc_mia_replacement_COMPASS = {};
 
 const dbc_MOTOR_DATA_s dbc_mia_replacement_MOTOR_DATA = {};

Hardware Design

Overall diagram of CAN

Overall diagram of CAN - With other correspondence devices on Controller

DBC File

Shown below is the DBC implementation for this project.

VERSION ""

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_: DBG DRIVER IO MOTOR SENSOR BRIDGE GPS COMPASS CMP

BO_ 150 MOTOR_CMD: 3 DRIVER
 SG_ MOTOR_CMD_STEERING : 0|8@1+ (1,-2) [-2|2] "" MOTOR 
 SG_ MOTOR_CMD_SPEED : 8|8@1+ (1,-25) [-25|25] "" MOTOR

BO_ 151 MOTOR_DATA: 4 MOTOR
 SG_ MOTOR_DATA_RPM: 0|32@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_DATA: 8 BRIDGE
 SG_ SENSOR_SONARS_left : 0|16@1+ (1,0) [0|0] "cms" DRIVER
 SG_ SENSOR_SONARS_mid : 16|16@1+ (1,0) [0|0] "cms" DRIVER
 SG_ SENSOR_SONARS_right : 32|16@1+ (1,0) [0|0] "cms" DRIVER
 SG_ SENSOR_IR_rear : 48|16@1+ (1,0) [0|0] "cms" DRIVER

BO_ 300 GPS_DESTINATION_INFO: 8 BRIDGE
SG_ GPS_DESTINATION_LAT : 0|32@1+ (0.000001,-90.000000) [-90|90] "degrees" DRIVER,GPS,MOTOR
SG_ GPS_DESTINATION_LONG : 32|32@1+ (0.000001,-180.000000) [-180|180] "degrees" DRIVER,GPS,MOTOR

BO_ 301 GPS_CURRENT_INFO: 8 GPS
SG_ GPS_CURRENT_LAT : 0|32@1+ (0.000001,-90.000000) [-90|90] "degrees" DRIVER,BRIDGE,MOTOR
SG_ GPS_CURRENT_LONG : 32|32@1+ (0.000001,-180.000000) [-180|180] "degrees" DRIVER,BRIDGE,MOTOR

BO_ 302 COMPASS: 6 GPS 
 SG_ CMP_DEST_BEARING : 0|16@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE,MOTOR
 SG_ CMP_CURRENT_HEADING : 16|16@1+ (0.1,0) [0|359.9] "degrees" DRIVER,BRIDGE,MOTOR
 SG_ CMP_DISTANCE : 32|16@1+ (0.01,0) [0|0] "meters" DRIVER,BRIDGE 
   
BO_ 105 SENSOR_DEBUG: 1 BRIDGE
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_sensor_init : 1|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_sensor_data : 2|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_bus_off : 3|1@1+ (1,0) [0|0] "" DBG
 
BO_ 106 MOTOR_DEBUG: 6 MOTOR
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG,DRIVER
 SG_ IO_DEBUG_bus_off : 1|1@1+ (1,0) [0|0] "" DBG,DRIVER
 SG_ IO_DEBUG_Steering : 2|8@1+ (1,-2) [-2|2] "" DBG,DRIVER
 SG_ IO_DEBUG_RPM : 10|32@1+ (1,0) [0|0] "" DBG,DRIVER
 
BO_ 107 DRIVER_DEBUG: 1 DRIVER
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_bus_off : 1|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_DRIVER : 3|1@1+ (1,0) [0|0] "" DBG

BO_ 108 GPS_DEBUG: 1 GPS
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_bus_off : 2|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_GPS : 3|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_Compass : 5|1@1+ (1,0) [0|0] "" DBG

BO_ 109 BRIDGE_DEBUG: 1 BRIDGE
 SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_bus_off : 2|1@1+ (1,0) [0|0] "" DBG
 SG_ IO_DEBUG_Bridge : 4|1@1+ (1,0) [0|0] "" DBG 

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ BRIDGE "The bridge controller of the car";
CM_ BU_ GPS    "The GPS controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

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_ 100 1000;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;

Busmaster

To monitor the messages being sent on the CAN-BUS, a PCAN dongle which Preet lent each group was used to connect to the CAN Bus and monitor messages being sent. The software used to monitor and analyze the messages sent on the CAN bus was Busmaster. An image of the busmaster message window and a signal graph is shown below.

Busmaster Message Window showing the message received on the PCAN dongle

Busmaster signal graph displaying middle, left, right, and rear sensor message data

Sensor ECU

Sensor node Gitlab

The sensor and bridge controller consists of sensor module that is responsible for object detection. Nimble uses ultrasonic sensors to achieve this task. As the name suggests, an ultrasonic sensor emits ultrasonic signal or beam from its head, and on encountering an object, returns back. This technique is better known as echolocation as we used sound signals to do so. The distance of the object is calculated based on the output and this ensures object detection. The distance measured is continuously passed on to driver node through can transceiver. The driver controller further processes the distance values of all the sensors on nimble and acts in accordance with the values to achieve obstacle avoidance.

Hardware Design

We have embedded 4 sensors on Nimble. We have arranged 3 LV-MaxSonar-EZ series Maxbotix ultrasonic sensors in the front section of the car; one at right, one at left and one in the center. The fourth Ultrasonic sensor is placed at the rear end of the car. These sensors provide very short to long-range detection. It provides sonar range information from 6-inches out to 254-inches with 1-inch resolution.

sensor and SJTWO connection description

Pin specification of Ultrasonic sensors

A maxbotix sensor gives out 3 types of output- analog, RS232, and Pulse width. We have used analog output and hence, utilized on-board analog to digital converters- ADC2 (P0.25), ADC3 (P0.26), ADC4 (P1.30), and ADC5 (P1.31). To trigger all the four ultrasonic sensors, we used P0.6, P0.7, P0.8 and P0.9 of SJTWO board. The analog output is converted to digital and transmitted to the driver controller. The converted adc distance data is passed to driver by Can transceiver. P0.0 is used as CAN RX and P0.1 as CAN TX on the Sensor module.

Hardware Interface

Sensors are interfaced with combination of GPIO, ADC Pins on SJTWo board. Below is the descriptive pin layout:

Software Design

The sensor implementation is done in 100Hz callback function, part of the periodic callbacks module. To give an overview, all the sensors are triggered at once and then given a minimum buffer time of 30ms for the outbound signal to bounce back and get detected, thereby giving us the raw distance readings. These readings are then processed inside a buffer to send the minimum value over CAN at 20Hz. As we have used Analog output, we used the available onboard ADCs with a few changes to the ADC driver implemented by Preet. The SJTWO board has 4 ADC pins available, with P0.26, which can be configured as both an ADC and a DAC. So we configured P0.26, that is ADC3 channel into the code and modified the ADC driver accordingly. The ADC readings are in the form of raw voltage and hence are converted to distances in centimetres. To get the most accurate distance value of each sensor, we used a buffer that gives out the minimum distance reading at 20Hz. This distance is sent over CAN to the Driver Node which further processes these distances and triggers the motors accordingly. The flowchart below shows the implementation of our Sensor controller.

flowchart of sensor controller's operation

A. Initialization:

1. Initialization of sensors: As we are using onboard ADC to get voltage, we first initialize all the ADCs (ADC2, ADC 3, ADC 4, ADC 5). We then configured IOCON registers to set up all the ADCs, according to the LPC40xx datasheet.

2. Initialized Buffer and can.

B. Triggering the sensors:

1. Configured available SJTWO GPIO pins, to be connected to the sensor’s RX pin, as GPIO output. These pins will serve as trigger pins to the sensors.

2. The sensors are triggered in at 20Hz inside the 100Hz function. To do so, the trigger pin is set for 30ms and the reset.

C. Read sensor values:

We are using ADC values to obtain the distance. All the values are in the form of analog voltage and represents the number of steps in terms of voltage level. To get real voltage value from raw, it is multiplied by the ADC voltage and divided by voltage scaling defined by voltage level powering the sensors (here 3.3 V) and manufacturing scaling (Vcc/512). The distance values obtained are stored in the Circular buffer module. All the sensors have an individual buffer that collects the distance values and get the minimum of all the values.

D. CAN transmission:

The lowest distance in 'cm' of all the sensors is sent to driver controller over CAN bus. We have used CAN1 to achieve this task. The driver then coordinates the movement according to the distance value.

Technical Challenges

• Issue 1: Unreliable reading when the whole RC car is being powered by one single portable battery. IR sensor, which was to mounted as the rear sensor wasn't receiving enough power to work reliably.
  • Solution: We ended up switching the IR sensor to another ultrasonic sensor, which works even at 3.3V, in order to make the rear readings reliable.
• Issue 2: Interference between the sensors was a major issue, wherein an obstacle on the right would make both the Right and Middle sensors to read low values.
  • Future work: The best possible solution would be print sensor mounts in advance, after deciding upon the sensors to be used. This will ease the process of testing the RC car.

Motor ECU

Our Motor Controller node is responsible to control the DC and Servo motor from the RC car, and additional RPM sensor measurement to get the RPM value from each rotation so we can have control to the speed or our RC car. The motor controller logic the steering and speed will be calculated within the Driver Node Controller through the CAN bus messages. Then, the Motor Controller node will output the feedback of RPM value for the Driver node to display the RPM value through CAN bus to the Driver module. The Motor controller node will also use this RPM feedback from the sensor to maintaining the speed making sure that the car is under certain threshold of RPM value, so it won't become too fast or too slow. The CAN message function will be constantly called at 10Hz of the periodic callbacks, while the speed check for the RPM value will be call every 500 ms.

Motor node Gitlab

Hardware Design

The hardware interface details of MOTOR Module with SJOne board are given above:

Overall outlook in RC car

Overall circuit