Difference between revisions of "S20: Bucephalus"

Schedule

Parts List & Cost

Hardware Integration: Printed Circuit Board

We Initially started with a very basic design of mounting all the hardware on a cardboard sheet for our first round of Integrated hardware testing.

First Prototype Board

Challenges: The wires were an entire mess and the car could not navigate properly due to the wiring issues as all the wires were entangling and a few had connectivity issues. Hence we decided to go for a basic dot matrix Design before finalizing our final PCB Design as a Prototype board for testing if anything goes haywire.

The Prototype Board just before the actual PCB board was created on a dot matrix PCB along with all the hardware components for the Intermediate Integrated testing phase is as follows:

Prototype board 1

Prototype board 2

Prototype board 3

1) To avoid all the above challenges We designed the custom PCB using EasyEDA in which we implemented connections for all the controller modules(SJTwo Board LPC4078) all communicating/sending data via CAN bus. The data is sent by individual sensors to the respective controllers. GPS and Compass are connected to Geographical Controller. RPM sensor, DC and Servo Motors are connected to Motor Controller.
2) Ultrasonic sensors are connected to Bridge and Sensor Controller. LCD is connected to Driver Controller. Bluetooth is connected to Bridge and Sensor Controller. CAN Bus is implemented using CAN Transceivers SN65HVD230 terminated by 120 Ohms; with PCAN for monitoring CAN Debug Messages and Data. Some Components need 5V while some sensors worked on 3.3V power supply. Also it was difficult to use separate USB's to power up all boards.Hence we used CorpCo breadboard power supply 3.3V/5V.
3) PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 with the lead time of 1 week. We implemented 2 layers of PCB with most of the parts in top layer GPS sensor and Compass sensor. We implemented rectangular header connector for SJTwo boards, RPM sensor, DC & Servo Motor on the bottom layer. There were 2 iterations of this board.
4) Challenges: We also need to change the header for LCD since it was having different pitch.

Designing:

Top Layer development

Bottom Layer development

After Delivery:

Top Layer development

Bottom Layer development

CAN Communication

CAN Communication is used to communicate between all the boards and it requires the bus to be terminated using two 120 Ohm resistors. CAN is a very deterministic broadcast bus. Based on the .dbc file, each module will transmit only selected messages. Receiving of the messages is enabled by filtering. The module can be configured to receive all messages or receive selected messages. Given below are features of CAN bus:

• Standard baud rate of 100K, 125K, 250K, 500k or 1M
• Differential Pair - Half-duplex

Working of CAN bus

A CAN frame has the following data:

• 4 bits for Data Length Code
• Remote Transmission Request
• ID extend bit
• Message ID (11 bit or 29 bit)

For CAN we require a transceiver(unlike) other BUSes. This transceiver converts the Rx and Tx lines to a single differential pair. where Logic 1( recessive) is represented by a ZERO volt difference and Logic 0(dominant) is represented by 2V difference.

Arbitration happens in can bus to make sure no two nodes are transmitting at the same time. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.

To make sure that a node does not put a lot of consecutive 1s or 0s together Bit Stuffing is done, where the CAN HW stuffs extra bits to improve CAN-BUS integrity. Our project's overall design is described below.

Hardware Design

We used the full CAN mode, to do hardware filtering and storage of messages. All the 4 boards Driver, GEO, Sensor and Bridge and Motor board communicate with each other over can messages. We connected a play and plug Waveshare CAN Transceivers Board for CAN Communication with our SjTwo Boards. This Board works on 3.3V and connects to the CAN Rx and CAN Tx Pins of the SjTwo Board. This Board then converts the signal to CAN High and CAN Low signal. This board itself has terminating resistors, thus when we connect 5 of them in one bus we bypass the terminating resistors present on the board itself and just use 120 ohms of terminating resistor at each end. This board has TI Chip installed on it and works flawlessly when interfaced with SjTwoboards.

CAN Interface

CAN Communication Table

The table indicates the messages based on the transmitter.

DBC File

DBC File

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 MOTOR SENSOR_BRIDGE GEO

BO_ 101 CAR_ACTION: 1 SENSOR_BRIDGE
 SG_ CAR_ACTION_cmd : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 200 SENSOR_USONARS: 5 SENSOR_BRIDGE
 SG_ SENSOR_USONARS_left : 0|10@1+ (1,0) [0|0] "cm" DRIVER
 SG_ SENSOR_USONARS_right : 10|10@1+ (1,0) [0|0] "cm" DRIVER
 SG_ SENSOR_USONARS_front : 20|10@1+ (1,0) [0|0] "cm" DRIVER
 SG_ SENSOR_USONARS_back : 30|10@1+ (1,0) [0|0] "cm" DRIVER

BO_ 300 DRIVER_STEER_SPEED: 2 DRIVER
 SG_ DRIVER_STEER_direction : 0|8@1- (1,0) [-2|2] "" MOTOR, SENSOR_BRIDGE
 SG_ DRIVER_STEER_move_speed: 8|8@1- (1,0) [-10|10] "" MOTOR, SENSOR_BRIDGE

BO_ 401 GEO_COMPASS: 6 GEO
 SG_ GEO_COMPASS_current_heading : 0|16@1+ (1E-002,0) [0|360.01] "degree" DRIVER, SENSOR_BRIDGE
 SG_ GEO_COMPASS_desitination_heading : 16|16@1+ (1E-002,0) [0|360.01] "degree" DRIVER, SENSOR_BRIDGE
 SG_ GEO_COMPASS_distance: 32|16@1+ (1E-002,0) [0.01|255.01] "m" DRIVER, SENSOR_BRIDGE

BO_ 500 BRIDGE_GPS: 8 SENSOR_BRIDGE
 SG_ BRIDGE_GPS_latitude : 0|32@1- (1E-006,-90.0) [-90.0|90.0] "" GEO
 SG_ BRIDGE_GPS_longitude : 32|32@1- (1E-006,-180.0) [-180.0|180.0] "" GEO

BO_ 600 MOTOR_SPEED: 4 MOTOR
 SG_ MOTOR_SPEED_info : 0|16@1- (0.01,-30.01) [-30.01|30.01] "mph" DRIVER, SENSOR_BRIDGE
 SG_ MOTOR_SPEED_pwm : 16|16@1+ (0.01, 0) [0.01|20.01] "pwm" DRIVER, SENSOR_BRIDGE

BO_ 700 TEST_BUTTON: 1 SENSOR_BRIDGE
 SG_ TEST_BUTTON_press : 0|8@1+ (1,0) [0|0] "" MOTOR

BO_ 800 HEADLIGHT: 1 SENSOR_BRIDGE
 SG_ HEADLIGHT_SWITCH : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 BATTERY: 1 DRIVER
 SG_ BATTERY_PERCENTAGE : 0|8@1+ (1,0) [0|100] "percent" SENSOR_BRIDGE 


CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR_BRIDGE "The sensor and bridge controller of the car";
CM_ BU_ GEO "The geo 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_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 300 DRIVER_STEER_direction "DRIVER_STEER_direction";


VAL_ 300 DRIVER_STEER_direction -2 "DRIVER_STEER_direction_HARD_LEFT" -1 "DRIVER_STEER_direction_SOFT_LEFT" 0 "DRIVER_STEER_direction_STRAIGHT" 1 "DRIVER_STEER_direction_SOFT_RIGHT" 2 "DRIVER_STEER_direction_HARD_RIGHT" ;

Technical Challenges

Negative Floating point numbers was not supported by auto code generator

The auto code generator only supported positive floating-point numbers, so we added a negative offset equivalent to the minimum negative value to propagate the negative values.

""Auto-generated code used to generate double constants instead of float constants""

We modified the auto generator script to generate the float constants in place of double constant. As double constant were not supported by hardware that would increase the complexity of code.

Bridge and Sensor Controller: Bluetooth Module

Control signals from the android application were transmitted to the car using Bluetooth. From the bridge and sensor board, debug information (decoded CAN messages) were transmitted to the android application in real-time.

Hardware Design

HC-05 module is an easy to use Bluetooth SPP (Serial Port Protocol) module, designed for wireless serial connection setup. It works on 2.4GHz radio transceiver frequency. The HC05 module has two operating modes - AT mode and User mode. In order to enter AT mode the manual switch on the board must be pressed for about 4 seconds. The LED display sequence on the board changes indicating successful entry to AT mode. Using AT commands various factors such as baud rate, auto-pairing, security features can be configured.

Most commonly used AT commands –

• AT+VERSION – Get module version number
• AT+ADDR – Module address. Save the slave address for paring with the master module
• AT+ROLE – 0 indicates slave module and 1 indicates Master module.
• AT+PSWD – Set password for the module using this AT command.
• AT+UART – Select the device baud rate from 9600,19200,38400,57600,115200,230400,460800
• AT+BIND – Bind Bluetooth address

Once the desired configurations are set, reset the module to switch back to User mode.

Hardware Features -

• Low Power Operation - 1.8 to 3.6V I/O
• UART interface with programmable baud rate
• Programmable stop and parity bits
• Auto - pairing with last connected device

Pin Connections -

Source: https://components101.com

Software Design

Flowchart

Software Design Flow -
1) Initialize UART
2) Check the control signals in buffer and send appropriate CAN message
3) Send debug information to the application

Configure the GPIO pin functionality to UART using the gpio_construct_with_function API. Set the baud rate and the Queue size. The queue size should be set by calculating the periodic callback frequency and the speed at which data is being received and dequeued from the buffer. The baud rate of the UART set in SJ2 should be equal to the baud rate in HC05 board. The control signal data is continuously being received and stored in the UART queue created. Every 10hz (100ms), the data stored in the queue is removed and stored in the circular buffer. A valid data check is made and if valid data is present in the circular buffer, we check if any valid control signal is present in the buffer. The valid format for the GPS co-ordinate begins with the pattern ‘*GPS’ and ends with ‘#’. Once the GPS string is extracted successfully from the buffer, an API call is made to extract the correct latitude and longitude from the string. Similarly, all the other control signals have a valid format. Once a control signal is detected we extract the signal from the buffer, set a flag and send the respective CAN message to other boards. When the CAN message is sent it is important to erase that message from the buffer to avoid any unnecessary action in the next periodic callback. Using the sl_string library, the message was removed from the buffer and the rear index was adjusted based on the length of the signal. In the 10hz periodic callback function, debug information was also being sent in real-time to the android application. On the bridge and sensor board, all the CAN messages from other board were decoded. A list of all the debug information sent to the application is given below.

List of debug information sent to the android application –

 Ping Status
 Car Action
 Motor Speed
 Motor Speed PWM
 Ultrasonic left
 Ultrasonic right
 Ultrasonic back
 Ultrasonic front
 Geo compass current heading
 Geo compass destination heading
 Geo compass compass distance
 Driver Steer Speed
 Driver Steer Direction
 Headlight
 Test Button
 GPS Latitude
 GPS Longitude
 Battery Percentage

Technical Challenges

Creating Dynamic Buffer

From the android application the sensor board was receiving multiple control signals such as START, STOP, HON, HOFF, MTEST and GPS co-ordinates. The order in which these control signals were sent from the android application was not static. Hence it was necessary to create a dynamic circular buffer algorithm that will handle this scenario. Once a particular control signal was detected, the appropriate CAN message was sent and the signal was erased from the buffer to avoid unnecessary action in the next periodic callback. Changing the front index of the buffer once the signal was erased and moving other data present in the buffer was a difficult task. This was solved by getting the start index of the control message in the buffer, finding the size of the signal in bytes and overwriting that signal with other data present in the buffer from that particular start index using APIs from the sl_string library.

Bridge and Sensor Controller: Sensors

The sensor part of the bridge and sensor controller board is responsible for receiving the sensor readings, converting them to centimeters, and then sending them to the driver controller board over CAN. A total of four Maxbotix MaxSonar HRLV-EZ0 ultrasonic sensors are connected to the bridge and sensor controller; three in front and one in back.

Bridge and Sensor Controller Diagram

We decided to use four ultrasonic sensors due to their relatively easy setup process, ranging capabilities, and reliability. We considered using lidar, but these sensors rely on additional factors such as lighting conditions. We specifically chose Maxbotix’s more expensive MaxSonar line because of their greater accuracy over their standard counterparts. The MaxSonar sensors have internal filtering to greatly reduce the amount of external noise affecting your sensor readings, making your readings far more reliable. The MaxSonar sensors also include an on-board temperature sensor to automatically adjust the speed of sound value based on the temperature of the environment the sensors are being used in. This means the sensor readings will stay consistent regardless of the weather and time of day (night time is much cooler than during the day).

Maxbotix offers ultrasonic sensors with different beam widths, and we chose their EZ0 sensors because they have the widest beam. Initially we thought this was a good idea because wider beams means an increased detection zone and less blind spots (width-wise). Please refer to the Technical Challenges section for details as to why we don’t recommend getting the widest possible beam for all four sensors.

MaxBotix MB1003 HRLV MaxSonar EZ0 Sensor

Hardware Design

The ultrasonic sensors are powered using +5V, and connected to the SJtwo board’s ADC pins. There are only 3 available exclusively ADC pins on the SJtwo board, and so we changed the DAC pin to ADC mode in our ADC driver since we needed a total of 4 ADC pins. We left the RX pin of each sensor unconnected, and so each sensor ranges continuously and independently of one another. We don’t recommend doing this because the sensor beams interfere with each other when firing at the same time, but due to implementation issues, we weren’t able to use the RX pin approach. Please refer to the Technical Challenges section for details as to what problems we encountered when using the RX pin, and how we resolved the interference problems as a result of not using the RX pin.

Bridge and Sensor Controller Schematic

Sensor Operating Voltage

The specific sensors we chose have an operating voltage requirement of +2.5V to +5.5V. Shown below from the MaxBotix datasheets is the detection pattern based on three different operating voltages. The detection zone decreases slightly as the operating voltage is decreased.

Ultrasonic Sensor Beam Pattern

Additionally, the strength of the sound wave generated by the ultrasonic sensor decreases as the operating voltage decreases. A weaker sound wave means less sound “bouncing” back to the sensor, which can result in obstacles not getting detected, especially with softer surfaces like people and small plants, or thinner objects like railed gates or metal pipe handrails. We encountered this problem when using an operating voltage of 3.3V. Even though the distance the sensors could detect when powered with 3.3V was perfectly sufficient for our application, the sensors wouldn’t consistently detect softer and thinner obstacles (mainly people and thin pipes/rails). Choosing an operating voltage of 5V drastically improved the detection abilities of the sensors. The sensors consistently detected people, thin pipes sticking out of the ground, thin railed gates, metal pipe handrails, and plants that were at or above the mounting height of the sensors.

Sensor Mounts and Shields

In order to secure the sensors to the car chassis, we 3D printed sensor mounts for all four of the ultrasonic sensors. The sensor mounts are adjustable so that the nozzle of the sensor can be adjusted upward or downward. It was extremely helpful to have adjustable mounts because it took quite a bit of testing and trial and error to find the angle that the sensor nozzle needed to be tilted upward in order to detect correctly. If the sensor nozzle wasn’t pointed up high enough, the sensors would detect the road as an obstacle. We placed screws inside the mounting base hole to ensure the mount wouldn’t tilt out of position, and screwed the sensor into the mount to keep it from falling out or jiggling around. Shown below is the sensor mount design in CAD software.

Sensor Mount in CAD Software

Once 3D printed, the two pieces of the mount are fit together.

Printed Sensor Mount

In addition to sensor mounts, we put adjustable sensor shields onto the car chassis in order to prevent beam interference between the left, right, and front sensors. When all sensors are firing, sometimes one of them would detect another sensor’s beam, resulting in a false reading. Adding shields greatly reduced the occurrence of a sensor detecting another sensor’s beam, and reduced the severity to which it affected the reading.

Unfortunately, due to the Coronavirus situation we did not have access to a 3D printer and were unable to print custom designed sensor shields (the sensor mounts were 3D printed before the Coronavirus shelter-in-place happened). To make shields, we cut rectangular pieces of cardboard (yellow cardboard for aesthetics) and hot glued them each to a popsicle stick. We drilled slits into some pvc pipe and placed the popsicle stick end of the shield inside. Screws were used to tighten down the popsicle stick and keep the shield in place. The pipe pieces were hot glued to plastic bottle caps, which were then screwed into the car chassis acrylic sheet. The shields can be adjusted left or right by twisting the bottle cap screwed to the acrylic sheet, and can be adjusted up or down by pushing up or pulling down on the popsicle stick end of the shield. The adjustable sensor shields and mounts on the car chassis are shown below.

Sensor Mounts and Shields on Car Chassis

Placement on Chassis

All four ultrasonic sensors were placed in their mounts, and then the bottom of the mount was hot glued to the acrylic sheet mounted on the car chassis. The placement of the sensors was an important decision to make because placing them too close together or not angling the left and right sensors outward enough resulted in beam interference.

A trial and error approach was taken to find the best sensor placement configuration for the left, right, and front sensors. The sensors were taped to the edge of a desk and the readings were observed to see if the values were stable or if the beams were interfering with each other. The testing setup used to determine the best sensor placement configuration can be seen below.

Ultrasonic Sensor Placement Testing Setup

Through testing, it was determined that angling the left and right sensors outward at about 45 degrees, and placing them as far apart as possible on the acrylic sheet produced good results. The front and back sensors were centered on the acrylic sheet.

Ultrasonic Sensor Placement on Acrylic Sheet

Software Design

The software design of the sensor modules consisted of the following ordered steps.

Sensor Software Design Steps

The flowchart below is for a single sensor between the initialization step, and the send CAN message step. The three in-between steps are done a total of four times (for each sensor). To keep things clean and easy to understand, the flowchart only shows the steps for a single sensor.

Single Sensor Flowchart

Initializing the Sensors

Some initialization and ADC driver modifications were required in order to get our sensors up and running. First, we wanted to use the analog out pin to receive data from all four sensors due to the simplicity of this interface. Since the Sjtwo board only has 3 available header pins with ADC functionality, we read the user manual for the LPC4058 [insert reference to user manual?] in order to see if any other available header pins had ADC capabilities. Shown below is Table 86 in the user manual, which lists all pins that have ADC functionality. Comparing this table with our SJtwo board, we found that ADC channel 3 located on P0[26] (labeled as DAC on SJtwo board) could be used as our fourth ADC pin.

Table 86 in LPC4058 User Manual

We modified the existing ADC driver in order to add support for P0[26] as an ADC pin. An enumeration for ADC channel 3 was added to adc.h, and ADC channel 3 was added to the “channel check” if statement in adc.c’s adc__get_adc_value(...) function. These modifications are shown below.

adc.h Modification

adc.c Modification in adc__get_adc_value(...)

In order to begin reading values from the sensors, all ADC pins must be set to “Analog Mode”. Looking at Table 85 in the LPC4058 user manual, we can see that upon reset, all ADC pins are in “Digital Mode”.

Part of Table 85 in LPC4058 User Manual

The SJtwo board’s ADC pins will not work if they are not set to “Analog Mode”, and so this code had to be added to the existing ADC driver since it was missing. We did the following IOCON register bit 7 clearing for all ADC pins inside the adc__initialize(...) function.

Adc.c Modification in adc_initialize(...).png

Once the modifications to the existing ADC driver had been made, we called adc__initialize(...) in our periodic_callbacks_initialize(...) function in order to perform the initialization of our ADC interface.

Converting to Centimeters

The raw ADC values read from each sensor aren’t inherently meaningful, and so they must be converted to centimeters in order to gauge the distance of obstacles. In order to perform the conversion, we sampled and recorded a sensor’s raw ADC values with obstacles placed at distances ranging from 0cm to 120cm in increments of 10cm. We decided to stop at 120cm because the process of collecting the sensor’s data was very time consuming and our maximum threshold value was 110cm, so there was no need to go farther. Shown below are the measurements gathered for our particular sensor model. It should be noted that the sensors produce a range of values when detecting an obstacle at a given distance, and so we averaged the values to obtain the most accurate results.

Ultrasonic Sensor Measurements

The values were plotted in a distance (Y-axis) versus ADC value (X-axis) graph, and a curve fit was performed in order to generate distance as a function of an ADC value. We used an application called Logger Pro because of its ability to automatically generate a curve fit for your data set.

Ultrasonic Sensor Distance vs. ADC Graph

We implemented the curve fit function generated by Logger Pro into code in order to convert our sensor’s ADC values to centimeters right after they were read from their respective ADC channel.

Filtering

Occasionally, the sensors will report incorrect values due to internal or external noise. Getting sensors that are more expensive usually decreases the number of times this happens, but even one incorrect reading can be a problem. For example, a sensor reading may incorrectly dip below the threshold and detect an obstacle even when there is none. Or worse, an obstacle may be within the threshold range but the sensor reading doesn’t reflect an obstacle being detected. Both of these scenarios can be avoided by filtering the sensor values before sending them to the driver controller over CAN.

The problem we were facing before filtering was the following; when setting up an obstacle in front of a sensor a certain distance away, 80cm for example, we monitored the sensor values to make sure all the readings were within a couple centimeters of 80cm. We noticed that occasionally, the output sensor readings would look something like “...80, 81, 80, 79, 82, 80, 45, 80, 78, 83, 81, 80, 79, 80…”. The sudden drop to 45 is clearly an incorrect reading because the obstacle remained at a constant 80cm away the entire time.

We considered several different filtering algorithms such as Mean, Median, Mode, and Kalman Filter. The Kalman Filter is very complex and so we didn’t feel the need to use it since other simpler options would work just as well for our application. The Mean Filter was completely out of the question because it averages the values. We want to remove the incorrect value, not incorporate it into the filtered value. The Median Filter requires the input values to be sorted in ascending order, which increases the run time and may cause us to run past our time slot in the 50Hz periodic callback function. Ultimately, we decided to use the Mode Filter because of its simplicity, short run time, and doesn’t require input values to be sorted. Choosing a filtering algorithm that has a short run time was one of the most important considerations because the sensors are running in a fast periodic callback function.

We implemented our own Mode Filter algorithm that took a number of input sensor values that have been converted to centimeters, finds the mode (most frequently occurring value) of the values, and then returns the mode as the filtered value. Through testing, we found that using an input size of 10 values to the mode filter was perfectly sufficient. A list of possible input values and the mode filter output can be seen below to better illustrate how our mode filter implementation works.

Mode Filter Output

A corner-case that we needed to address was the possibility of multiple modes. This case can be seen in lines 2, 3, and 5 in the table above. We chose to return the mode that was most recent in order to reflect the most recent changes in sensor values. Take line 5 for example; all values occur exactly twice, which means there are five modes. The mode returned is 69 because it is the most recent mode.