Difference between revisions of "S20: Bucephalus"

<BR/>

<BR/>

3) System hardware communication using PCB Design. <BR/>

3) System hardware communication using PCB Design. <BR/>

'''The project is divided into six main modules:'''

'''The project is divided into six main modules:'''

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"

|- style="vertical-align: top;"  

|- style="vertical-align: top;"  

|}

|}

[[File:Cmpe243_s20_project_architecture.png|thumb|center|800px| Project Overview]]

[[File:Cmpe243_s20_project_architecture.png|thumb|center|800px| Project Overview]]

'''Bucephalous GitLab - [https://gitlab.com/bucephalus/sjtwo-c/-/tree/master]'''

'''Bucephalous GitLab - [https://gitlab.com/bucephalus/sjtwo-c/-/tree/master]'''

* Completed

* Completed

* Completed

* Completed

|-

|-

|}

|}

|-

|-

! scope="row"| 2

! scope="row"| 2

| 1

| 1

|-

|-

! scope="row"| 3

! scope="row"| 3

| Battery Charger

| Battery Charger

| 1

| 1

|-

|-

! scope="row"| 4

! scope="row"| 4

| Tap Plastics Acrylic Sheet

| Tap Plastics Acrylic Sheet

| 1

| 1

|-

|-

! scope="row"| 5

! scope="row"| 5

| Ultrasonic Sensors

| Ultrasonic Sensors

| 4

| 4

|-

|-

! scope="row"| 6

! scope="row"| 6

| GPS Module

| GPS Module

| 1

| 1

|-

|-

! scope="row"| 7

! scope="row"| 7

| GPS Antenna

| GPS Antenna

| 1

| 1

|-

|-

! scope="row"| 8

! scope="row"| 8

| 1

| 1

|-

|-

! scope="row"| 9

! scope="row"| 9

| UART LCD Display

| UART LCD Display

| 1

| 1

|-

|-

! scope="row"| 10

! scope="row"| 10

| Bluetooth Module

| Bluetooth Module

| 1

| 1

|-

|-

! scope="row"| 11

! scope="row"| 11

| CAN Transceivers SN65HVD230DR

| CAN Transceivers SN65HVD230DR

|-

|-

! scope="row"| 12

! scope="row"| 12

|-

|-

! scope="row"| 13

! scope="row"| 13

| 1

| 1

|-

|-

! scope="row"| 14

! scope="row"| 14

| Sensor Mounts

| Sensor Mounts

| 4

| 4

|-

|-

|}

|}

<BR/>

<BR/>

<br/>

<br/>

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.  

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.  

[[File:Car_Chassis_Initial.jpg|thumb|350px|caption|center|First Prototype Board]]<BR/>

[[File:Car_Chassis_Initial.jpg|thumb|350px|caption|center|First Prototype Board]]<BR/>

<br>

<br>

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.

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.

<br/>

<br/>

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

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

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

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

<br><br><br>

<br><br><br>

{| style="margin-left: auto; margin-right: auto; border: none;"

{| style="margin-left: auto; margin-right: auto; border: none;"

|[[File:TopLayer.png|Left|500px|thumb|Top Layer development]]

|[[File:TopLayer.png|Left|500px|thumb|Top Layer development]]

|

|

|}

|}

{| style="margin-left: auto; margin-right: auto; border: none;"

{| style="margin-left: auto; margin-right: auto; border: none;"

|[[File:after_delivery_top.jpg|Left|240px|thumb|Top Layer development]]

|[[File:after_delivery_top.jpg|Left|240px|thumb|Top Layer development]]

== CAN Communication ==

== CAN Communication ==

=== Hardware Design ===

=== Hardware Design ===

=== DBC File ===

=== DBC File ===

[https://gitlab.com/bucephalus/sjtwo-c/-/blob/dev/integrate/dbc/project.dbc  DBC File ]

[https://gitlab.com/bucephalus/sjtwo-c/-/blob/dev/integrate/dbc/project.dbc  DBC File ]

<syntaxhighlight lang="c">

<syntaxhighlight lang="c">

VERSION ""

VERSION ""

BS_:

BS_:

CM_ BU_ DRIVER "The driver controller driving the car";

CM_ BU_ DRIVER "The driver controller driving the car";

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

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

CM_ BO_ 100 "Sync message used to synchronize the controllers";

CM_ BO_ 100 "Sync message used to synchronize the controllers";

CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver";

BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";

</syntaxhighlight>

</syntaxhighlight>

<HR>

<HR>

<BR/>

<BR/>

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.  

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.  

• AT+VERSION – Get module version number

• AT+VERSION – Get module version number

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

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

• Low Power Operation - 1.8 to 3.6V I/O

• Low Power Operation - 1.8 to 3.6V I/O

'''Pin Connections -'''  

'''Pin Connections -'''  

</center>

</center>

[[File:Screenshot 2020-05-22 at 5.19.09 PM.png|thumb|500px|caption|center|Flowchart]]

[[File:Screenshot 2020-05-22 at 5.19.09 PM.png|thumb|500px|caption|center|Flowchart]]

<br> 1) Initialize UART  

<br> 1) Initialize UART  

<br> 2) Check the control signals in buffer and send appropriate CAN message

<br> 2) Check the control signals in buffer and send appropriate CAN message

'''Creating Dynamic Buffer'''

'''Creating Dynamic Buffer'''

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

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

[[File:MaxBotix_MB1003_HRLV_MaxSonar_EZ0_Sensor.png|center|300px|thumb|MaxBotix MB1003 HRLV MaxSonar EZ0 Sensor]]

[[File:MaxBotix_MB1003_HRLV_MaxSonar_EZ0_Sensor.png|center|300px|thumb|MaxBotix MB1003 HRLV MaxSonar EZ0 Sensor]]

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.

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.

====Sensor Operating Voltage====

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

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.  

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.  

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.  

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.  

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.  

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

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

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.  

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.  

====Placement on Chassis====

====Placement on Chassis====

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.  

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.  

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.  

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.  

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

The software design of the sensor modules consisted of the following ordered 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.  

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.  

====Initializing the Sensors====

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

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.  

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.  

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.  

[[File:Adc.h Modification.png|center|300px|thumb|adc.h Modification]]

[[File:Adc.h Modification.png|center|300px|thumb|adc.h Modification]]

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

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

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.

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.

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.  

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.  

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.  

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.  

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.  

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.  

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.  

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.  

As for the actual implementation of the Mode Filter, we based it off of the Counting Sort algorithm’s “bucket storing method” with some modifications in order to make the runtime O(n), with n being the input data size (10 in our case). There is no need to sort the values for our Mode Filter, and so the sorting part of the Counting Sort algorithm is completely omitted. The idea of storing the occurence of each value in an array element number equal to the current sensor value (in centimeters) is the only idea we used from the Counting Sort algorithm. An example of how our Mode Filter works can be seen below.  

As for the actual implementation of the Mode Filter, we based it off of the Counting Sort algorithm’s “bucket storing method” with some modifications in order to make the runtime O(n), with n being the input data size (10 in our case). There is no need to sort the values for our Mode Filter, and so the sorting part of the Counting Sort algorithm is completely omitted. The idea of storing the occurence of each value in an array element number equal to the current sensor value (in centimeters) is the only idea we used from the Counting Sort algorithm. An example of how our Mode Filter works can be seen below.  

The size of the array inside the Mode Filter algorithm is specifically set to 600 elements. The array needs to have element numbers for every possible sensor value (in centimeters). Our sensor values range is from 0 to 500 centimeters and so we added an extra 100 just for safety, which gives us a total of 600 array elements. This is the reason we chose to convert our sensor values to centimeters before passing them as input into the Mode Filter. If we were to pass the raw sensor values into the filter, we would need an array with around 4096 elements (SJtwo board’s ADC is 12-bit, so 2^12 = 4096).

The size of the array inside the Mode Filter algorithm is specifically set to 600 elements. The array needs to have element numbers for every possible sensor value (in centimeters). Our sensor values range is from 0 to 500 centimeters and so we added an extra 100 just for safety, which gives us a total of 600 array elements. This is the reason we chose to convert our sensor values to centimeters before passing them as input into the Mode Filter. If we were to pass the raw sensor values into the filter, we would need an array with around 4096 elements (SJtwo board’s ADC is 12-bit, so 2^12 = 4096).

====ADC====

====ADC====

<BR/>

<BR/>

The Motor Controller SJ2-Board is mainly responsible for RC-Car’s steering and speed to move the car towards the destination. The RC-Car we are using is 2 Wheel Drive which means the front wheels are used for steering which is controlled by servo motor and the rear wheels are used for car’s forward and reverse movements which are controlled by DC Motor through ESC.

The Motor Controller SJ2-Board is mainly responsible for RC-Car’s steering and speed to move the car towards the destination. The RC-Car we are using is 2 Wheel Drive which means the front wheels are used for steering which is controlled by servo motor and the rear wheels are used for car’s forward and reverse movements which are controlled by DC Motor through ESC.

[[File:Motor_Module_Schematic.PNG|thumb|800px|caption|center|]]<BR/>

[[File:Motor_Module_Schematic.PNG|thumb|800px|caption|center|]]<BR/>

|}

|}

The servo motor we used is Traxxas 2075 which was provided with the car and it is responsible for steering the car. It takes the 6V power directly from ESC. The servo motor is controlled directly from the SJ2 micro-controller board. The PWM signal fed to the servo motor is of frequency 100Hz. Based on the duty cycle of the signal sent to the servo, it rotates in the left / right direction. 10% - 20% duty cycle for left. 15% duty cycle for straight. 15%-20% duty cycle for right.

The servo motor we used is Traxxas 2075 which was provided with the car and it is responsible for steering the car. It takes the 6V power directly from ESC. The servo motor is controlled directly from the SJ2 micro-controller board. The PWM signal fed to the servo motor is of frequency 100Hz. Based on the duty cycle of the signal sent to the servo, it rotates in the left / right direction. 10% - 20% duty cycle for left. 15% duty cycle for straight. 15%-20% duty cycle for right.

[[File:ServoMotor.jpg|center|300px|thumb|Traxxas Servo]]

[[File:ServoMotor.jpg|center|300px|thumb|Traxxas Servo]]

There are two parts to the RPM sensor - one is the trigger magnet and the other is the sensor. The RPM sensor is used as an input to maintain a constant speed of the vehicle. The sensor mounts on the inside of the gear cover, the trigger magnet mounts on the DC motor shaft. The gear cover and motor shaft need to be removed using the toolkit provided along with the RC car. The procedure is similar to this video, but note that the car used in the video is a 4WD RC car by Traxxas. We made use of the trigger magnet attached to the spur gear to trigger a pulse on the sensor for every rotation of the spur gear. These pulses are then read by the SJ2 board to calculate rotations in a second and later convert it to RPM and MPH. The RPM sensor has 3 wires, the white wire is the output wire that provides the pulses to the SJ2 Board, and the other wires are Supply(6V) and GND. We also used a Pull Down 1K Resistor between Supply and RPM output wires.

There are two parts to the RPM sensor - one is the trigger magnet and the other is the sensor. The RPM sensor is used as an input to maintain a constant speed of the vehicle. The sensor mounts on the inside of the gear cover, the trigger magnet mounts on the DC motor shaft. The gear cover and motor shaft need to be removed using the toolkit provided along with the RC car. The procedure is similar to this video, but note that the car used in the video is a 4WD RC car by Traxxas. We made use of the trigger magnet attached to the spur gear to trigger a pulse on the sensor for every rotation of the spur gear. These pulses are then read by the SJ2 board to calculate rotations in a second and later convert it to RPM and MPH. The RPM sensor has 3 wires, the white wire is the output wire that provides the pulses to the SJ2 Board, and the other wires are Supply(6V) and GND. We also used a Pull Down 1K Resistor between Supply and RPM output wires.

|}

|}

Periodic Init: CAN, PWM(Servo and Motor), and Interrupts(RPM Sensor and Test button) were initialized in this function.

Periodic Init: CAN, PWM(Servo and Motor), and Interrupts(RPM Sensor and Test button) were initialized in this function.

[[File:Periodic_Callbacks_Flowchart.PNG|center|700px|thumb|Periodic Callbacks Flowchart]]

[[File:Periodic_Callbacks_Flowchart.PNG|center|700px|thumb|Periodic Callbacks Flowchart]]

The PWM signal fed to the servo motor is of frequency 100Hz. The motor controller receives steer controls from the driver controller and it sends corresponding PWM value to the servo motor.

The PWM signal fed to the servo motor is of frequency 100Hz. The motor controller receives steer controls from the driver controller and it sends corresponding PWM value to the servo motor.

[[File:Steering_Flowchart.PNG|center|400px|thumb|Servo Flowchart]]

[[File:Steering_Flowchart.PNG|center|400px|thumb|Servo Flowchart]]

The PWM signal fed to the DC motor is of frequency 100Hz. The motor controller receives speed controls from the driver controller and it sends corresponding PWM value to the ESC which controls the DC motor.

The PWM signal fed to the DC motor is of frequency 100Hz. The motor controller receives speed controls from the driver controller and it sends corresponding PWM value to the ESC which controls the DC motor.

[[File:DC_Motor_Flowchart.PNG|center|400px|thumb|DC Motor Flowchart]]

[[File:DC_Motor_Flowchart.PNG|center|400px|thumb|DC Motor Flowchart]]

RPM Sensor gives one pulse for each wheel rotation and the software calculates speed in mph using the no. of rotations. We are re-calculating the speed, every 500ms to maintain the speed of the motor while the car is going uphill or downhill.

RPM Sensor gives one pulse for each wheel rotation and the software calculates speed in mph using the no. of rotations. We are re-calculating the speed, every 500ms to maintain the speed of the motor while the car is going uphill or downhill.

[[File:RPM_Sensor_Flowchart.PNG|center|400px|thumb|Speed Control Flowchart]]

[[File:RPM_Sensor_Flowchart.PNG|center|400px|thumb|Speed Control Flowchart]]

==== Car Reverse Movement ====

==== Car Reverse Movement ====

Solution: We checked the code and were giving the correct PWM values for the car to go reverse but the car wouldn’t do it sometimes. Then, we read the ESC manual and figured out that the wheels need to stop before giving the reverse command. For us, using these Commands (FULL REVERSE and STOP) before giving reverse PWM values for the reverse movement worked well. Also, we had to use current speed in combination with these FULL REVERSE commands to make sure that these reverse commands are given only when the car is moving forward.

Solution: We checked the code and were giving the correct PWM values for the car to go reverse but the car wouldn’t do it sometimes. Then, we read the ESC manual and figured out that the wheels need to stop before giving the reverse command. For us, using these Commands (FULL REVERSE and STOP) before giving reverse PWM values for the reverse movement worked well. Also, we had to use current speed in combination with these FULL REVERSE commands to make sure that these reverse commands are given only when the car is moving forward.

Problem: The car would move too fast while downhill even though the feedback loop for the speed control is reducing the PWM.

Problem: The car would move too fast while downhill even though the feedback loop for the speed control is reducing the PWM.

<BR/>

<BR/>

The geographical controller is responsible for providing the required destination heading angle(destination direction) and the destination distance using compass, GPS sensors for the car to reach destination.

The geographical controller is responsible for providing the required destination heading angle(destination direction) and the destination distance using compass, GPS sensors for the car to reach destination.

[[File:Geo_pin_connection_cropped.png|thumb|center|600px|GEO Board Block Diagram]]

[[File:Geo_pin_connection_cropped.png|thumb|center|600px|GEO Board Block Diagram]]

[[File:geo_pin_connect.PNG|thumb|center|600px|GEO Board Hardware Pin Connections]]

[[File:geo_pin_connect.PNG|thumb|center|600px|GEO Board Hardware Pin Connections]]

<br>

<br>

<br>

<br>

The below table explains what each of the datum in the GPGGA sentence stands for:

The below table explains what each of the datum in the GPGGA sentence stands for:

The first 6 fields in the NMEA sentence are the most important ones. If field 4 said ‘N’, we checked the data in field 3 which had the latitude. Likewise, if field 6 said ‘W’, we check the data in field 5 which contained the longitude. It is important to note that the longitude and latitude data are in the form degree-minute-seconds instead of true decimal. If not properly converted, they could have offset the location readings by miles.

The first 6 fields in the NMEA sentence are the most important ones. If field 4 said ‘N’, we checked the data in field 3 which had the latitude. Likewise, if field 6 said ‘W’, we check the data in field 5 which contained the longitude. It is important to note that the longitude and latitude data are in the form degree-minute-seconds instead of true decimal. If not properly converted, they could have offset the location readings by miles.

Compass heading is read by initiating the I2C read operation, and by passing the compass address (0xC0) and the register address (0x2). These values, along with the temporary array must be passed in a single I2C read operation. An example of the code snippet is as below:

Compass heading is read by initiating the I2C read operation, and by passing the compass address (0xC0) and the register address (0x2). These values, along with the temporary array must be passed in a single I2C read operation. An example of the code snippet is as below:

The calibration level is checked to see how well the compass is calibrated. The 8-bit value resides in register 0x1E according to the diagram below:

The calibration level is checked to see how well the compass is calibrated. The 8-bit value resides in register 0x1E according to the diagram below:

When each of the 2-bit calibration value is 0, this means the specific field is not calibrated, a value of 3 means the field is fully calibrated. This is done by performing an I2C read operation, whilst reading the 0xC0 and the 0x1E registers, to determine if it’s calibrated or not. The code snippet looks as below:

When each of the 2-bit calibration value is 0, this means the specific field is not calibrated, a value of 3 means the field is fully calibrated. This is done by performing an I2C read operation, whilst reading the 0xC0 and the 0x1E registers, to determine if it’s calibrated or not. The code snippet looks as below:

   }

   }

     deflection -= 360;

     deflection -= 360;

     deflection += 360;

     deflection += 360;

The complete flowchart for the geo module is shown below. We broke all the tasks in two iterations of the 10Hz function because if we do them in one iteration, we get the task overrun error. Therefore, the gps update rate is 5Hz.

The complete flowchart for the geo module is shown below. We broke all the tasks in two iterations of the 10Hz function because if we do them in one iteration, we get the task overrun error. Therefore, the gps update rate is 5Hz.

=== <font color="0000FF"> Technical Challenges </font> ===

=== <font color="0000FF"> Technical Challenges </font> ===

<HR>

<HR>

<BR/>

<BR/>

The Driver module is the brain of our autonomous car. It takes input from the Sensor and Geological controller to compute the direction of travel and sends the driving signal to the motor controller. It communicates with other modules via the CAN bus using CAN transceiver.

The Driver module is the brain of our autonomous car. It takes input from the Sensor and Geological controller to compute the direction of travel and sends the driving signal to the motor controller. It communicates with other modules via the CAN bus using CAN transceiver.

[[File:CMPE243_S20_Driver_Interface.png|thumb|center|800px|Master Block Diagram]]

[[File:CMPE243_S20_Driver_Interface.png|thumb|center|800px|Master Block Diagram]]

{|

{|

[[File:CMPE_243_S20_driver_schematic.png|thumb|left|450px|<center>Driver Schematic Block Diagram</center>]]

[[File:CMPE_243_S20_driver_schematic.png|thumb|left|450px|<center>Driver Schematic Block Diagram</center>]]

|}

|}

* The Driver control module is the brain of the Self-driving car as it takes all the critical driving decisions based on messages from the other control modules like Sensor, Geo and sends the message to the Motor control module for driving the car.

* The Driver control module is the brain of the Self-driving car as it takes all the critical driving decisions based on messages from the other control modules like Sensor, Geo and sends the message to the Motor control module for driving the car.

* The Driver Board receives CAN message from Geological board which includes the current heading angle of the car, destination heading angle of the car, and distance to the destination.

* The Driver Board receives CAN message from Geological board which includes the current heading angle of the car, destination heading angle of the car, and distance to the destination.

[[File: Cmpe243_s20_driver_algo.png |thumb|center|800px| Driving Algorithm]]

[[File: Cmpe243_s20_driver_algo.png |thumb|center|800px| Driving Algorithm]]

* '''Car Not Detecting Obstacle Fast Enough'''

* '''Car Not Detecting Obstacle Fast Enough'''

Additonally we adjusted the threshold by calculating the distance car can travel based on time required to read the obstacle data and time required for car to take action based on the obstacle.

Additonally we adjusted the threshold by calculating the distance car can travel based on time required to read the obstacle data and time required for car to take action based on the obstacle.

* '''Multiple decisions needed to be taken'''

* '''Multiple decisions needed to be taken'''

<BR/>

<BR/>

Gitlab Link <https://gitlab.com/bucephalus/bucephalus-android-app>

Gitlab Link <https://gitlab.com/bucephalus/bucephalus-android-app>

The Android Application evolved as we added one module per week as the course progressed. I started with understanding the Google Maps and how to use it in an Application, later on developed bluetooth code and finally introduced the state machine to selectively disable certain functions as to handle the bugs on a button being pressed when it was not supposed to be pressed. The implementation of the Android App was completed in a single Activity, we just had another Activity for the splash screen to display the logo.

The Android Application evolved as we added one module per week as the course progressed. I started with understanding the Google Maps and how to use it in an Application, later on developed bluetooth code and finally introduced the state machine to selectively disable certain functions as to handle the bugs on a button being pressed when it was not supposed to be pressed. The implementation of the Android App was completed in a single Activity, we just had another Activity for the splash screen to display the logo.

[[File:Flowchart-Android.png|thumb|center|User Interface State Machine]]

[[File:Flowchart-Android.png|thumb|center|User Interface State Machine]]

We kept the user interface as minimal as possible, with an extra feature of turning ON/OFF the headlights of the car. The UI had few TextFields, Google Maps and Buttons. In order to decrease minimise the use of Buttons, I decided to use the same button for Set Destination and Start by using a State Machine to change the functionality of Button.

We kept the user interface as minimal as possible, with an extra feature of turning ON/OFF the headlights of the car. The UI had few TextFields, Google Maps and Buttons. In order to decrease minimise the use of Buttons, I decided to use the same button for Set Destination and Start by using a State Machine to change the functionality of Button.

     @Override

     @Override

                 }

                 }

             }

             }

         }

         }

             }

             }

                 try {

                 try {

                 } catch (Exception e) {

                 } catch (Exception e) {

                 }

                 }

                 }

                 }

             }

             }