Difference between revisions of "S21: UTAH"

From Embedded Systems Learning Academy
Jump to: navigation, search
(Geographical Controller)
(Hardware Design)
Line 868: Line 868:
The geographical controller runs all the processing for compass data as well as GPS data. The purpose of the controller is to interface with the Adafruit Ultimate GPS Breakout using UART which provides accurate GPS data formatted in GPGGA. The controller utilizes I2C protocol to interface with the Adafruit Magnetometer with tilt compensation for the purpose of finding our heading and where the car needs to point in order to get closer to its destination. The Adafruit magnetometer was able to give us accurate data with a possible deviation of up to 3 degrees in any direction. This was possible by using a software filter to normalize our data and create a standard.  
The geographical controller runs all the processing for compass data as well as GPS data. The purpose of the controller is to interface with the Adafruit Ultimate GPS Breakout using UART which provides accurate GPS data formatted in GPGGA. The controller utilizes I2C protocol to interface with the Adafruit Magnetometer with tilt compensation for the purpose of finding our heading and where the car needs to point in order to get closer to its destination. The Adafruit magnetometer was able to give us accurate data with a possible deviation of up to 3 degrees in any direction. This was possible by using a software filter to normalize our data and create a standard.  
[[File:Geo Akash.png|750px|center|thumb|Geo Hardware Design]]
{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
{| class="wikitable" width="auto" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+Table 5. Geographical Node Pinout
|+Table 5. Geographical Node Pinout
Line 917: Line 918:
[[File:Geo Akash.png|750px|center|thumb|Geo Hardware Design]]
=== Software Design ===
=== Software Design ===

Revision as of 20:02, 28 May 2021

UTAH: Unit Tested to Avoid Hazards


The UTAH (Unit Testing to Avoid Hazards) project is a path finding and obstacle avoiding RC car. UTAH can interface with an Android application to get new coordinates to travel to, and will do so all while avoiding obstacles visible by ultrasonic sensors.

Objectives & Introduction

Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.


  • RC car can communicate with an Android application to:
    • Receive new coordinates to travel to
    • Send diagnostic information to the application
    • Emergency stop and start driving
  • RC car can travel to received coordinates in an efficient path while avoiding obstacles
  • RC car can maintain speed when driving on sloped ground
  • Design printed circuit board (PCB) to neatly connect all SJ2 boards
  • Design and 3D print sensor mounts for the ultrasonic sensors
  • Design a simple and intuitive user interface for the Android application
  • Design a DBC file


The UTAH RC car uses 4 SJ2 boards as nodes on the CAN bus

  1. Driver and LCD
  2. GEO and path finding
  3. Sensors and bridge app
  4. Motor

Need a top down photo of RC car

Team Members & Responsibilities

Akash Vachhani profilepic.jpg


  • Ameer Ali
    • Master Controller

Jonathan tran self pic.jpeg

  • Jonathan Tran Gitlab
    • Sensors Controller
  • Amritpal Sidhu
    • Motor Controller


  • Shreevats Gadhikar Gitlab'
    • Motor Controller


Description Color
Administrative Black
Sensor Cyan
Bluetooth & App Blue
Motor Magenta
Main Orange
Week# Start Date End Date Task Status
  • Read previous projects to understand what is expected and have some meaningful knowledge by first meeting. Assign roles.
  • Completed
  • Acquire parts: Canbus modules, GPS module, Ultrasonic module, Bluetooth module, Car frame, and LCD display
  • Conduct meeting: Discuss GitLab layout and expectation of each assigned role
  • Completed
  • Completed
  • Purchased RC car and batteries.
  • Research and finalize which ultrasonic sensor the project will use.
  • Purchased Bluetooth connector
  • Research math needed to determine distance between navigation points. Decide on distance algorithm
  • Research multiple navigation point algorithm(Djikstra's) to determine shortest path.
  • Create branch for motor controller driver. Create draft template API for motor controller.
  • Using previous projects, determine what works needs to be completed for main board. Bring findings to weekly meeting
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Research connection with Bluetooth from board to application. Decide between bluetooth connection or wifi connection by this day
  • Work on implementation of multiple navigation point algorithm to determine shortest path
  • Plan motor controller API and create basic software flow of API
  • Completed
  • Completed
  • Completed
  • Begin laying out hardware requirements for PCB on excel document. Include voltage and pinout requirements in excel document
  • Finish research on application building with android studio. Install android studio and necessary dependencies
  • Implement a simple application with a button and text
  • Start researching on Wheel encoder according to the requirement
  • Unit Test Direction Distance Calculation Module. Manual calculation of data should match module output
  • Begin coding and digesting adafruit Compass data. Print Compass data.
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Acquire sensor and interface sensors to SJ2 Board and receive raw data
  • Implement basic communication between board and app
  • Update Wiki with proper software diagrams for GPS and Compass data flow
  • Begin Mapping out pins used on all board
  • Complete a block diagram and a control scheme
  1. Top Level Driver Logic diagram
  2. Periodic Callback Functions Diagram
  • Create a basic Obstacle avoidance algorithm for Driver
  • Probe RC car to determine expected behavior of signals and install RPM sensor
  • Write motor controller modules and tests
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Discuss and construct DBC file
  • Create sensor API to parse raw data and convert into inches
  • Integrate google map features into app
  • Integration testing of motor controller logic
  • Create a Checkpoint Navigation algorithm for Driver
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Finish implementation of canbus between controllers and begin real world testing
  • 3D print sensor mounts, sensor guards, and draft sensor offset timing to deter sensor cross talk
  • Finish integrating wheel encoder and display speed on SJTwo Telemetry
  • Establish Communication between the LCD display and Master Board over I2C
  • Completed
  • Completed
  • Completed
  • Completed
  • Integrate Driver, Geo, Bridge sensor, and Motor nodes. Successful communication between all boards.
  • Implement Kill button on app for emergency stop
  • Analyze noise in sensor values and design a filter to mitigate the noise
  • Complete "Self Test" for motor test(DC motor moves forward and backwards and servo moves right - left)
  • Start working on PID control algorithm. Design bare skeleton for workflow
  • Create an algorithm to account for speed when the car is on an incline
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Begin to analysis real world tests from previous weeks implementation and perform fixes for issues faced
  • Ensure Canbus nodes are communicating correctly by verifying PCON data. Verify that timing for data is correct
  • Added CAN debug messages
  • Start working on the PCB, order the PCB and also purchase the required components
  • Integration testing with obstacle avoidance.
  1. Analyze possible blind spots and make adjustments to sensor placements.
  2. Analyze sensor response time and data while rc car is moving and make adjustments if needed.
  • Display relevant Motor and Checkpoint Information to the LCD.
  • Tuned and tested PID on RC Car (More refinement needed)
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Completed
  • Perform more real world tests and isolate bugs. Update issues for bugs find during real world test
  • Perform final bug fixes, as listed under issues, for all Canbus nodes.
  • Integrate all the parts on the PCB.
  • Completed
  • Completed
  • Completed
  • Update Wiki Report to reflect all changes and include final testing video
  • Perform final code changes and commit to master branch
  • Received manufactured PCB, installed, and integration tested
  • Refactored motor controller code and wrote much needed unit tests
  • Finished tuning PID and tested RC Car driving on slope
  • Incomplete
  • Incomplete
  • Completed
  • Completed
  • Completed
  • Update Wiki schedule and begin draft for individual controller documentation
  • Completed
  • Incomplete
  • Update Wiki individual controller and general documentation
  • Last minute bug fixes/refining
  • Waypoint algorithm integration and test
  • Last minute bug fixes/refining & code cleanup
  • In Progress
  • Completed
  • Completed
  • Completed
  • Completed
  • Incomplete
  • Incomplete

Parts List & Cost

Item# Part Description Vendor Qty Cost
1 Traxxas 1/10 Scale RC Short Truck Traxxas [1] 1 $239.99 + Tax
2 RPM Sensor & Mount Traxxas [2] 1 $19.00 + Tax
3 2S 7.4V 5000mAh LiPo Battery Pack Amazon [3] 2 $40.69 + Tax
4 Bluetooth Adapter Amazon [4] 1 $8.99 + Tax
5 Adafruit Ultimate GPS Breakout Adafruit [5] 1 $39.95
6 Adafruit Triple-axis Accelerometer+Magnetometer Adafruit [6] 1 $14.95
7 Deans Connector Amazon [7] 1 $8.99 + Tax
8 Pololu 5V Voltage Regulator Pololu [8] 1 $10.83
9 PCB JLCPCB [9] 1 $40.00

Printed Circuit Board

We started with a very basic design for our RC car on a breadboard. All the components were integrated on the breadboard for testing purposes.

Breadboard Wiring

We later had a PCB manufactured. In our design we minimized the use of surface mount components and additional passive components. We reused the CAN transceiver modules we all purchased and the only passive components on the board were the two 120Ω termination resistors needed at each end of the CAN bus. The remainder of the PCB used a combination of male and female pin headers to connect all components together. This design, plus a lot of thoroughness by Shreevats, made it so we only needed 1 revision.

PCB Schematic

PCB Layout showing traces (red are front side, blue are back side)
PCB Rendering front side

To overcome all the challenges which were faced on the breadboard we designed the PCB on EasyEDA. EasyEDA allows the creation and editing of schematic diagrams, and also the creation and editing of printed circuit board layouts and, optionally, the manufacture of printed circuit boards. So we implemented the custom PCB using EasyEDA Software in which we implemented all the four controller connections. The four controllers included Master Controller, Geo Controller, Sensor Controller, and Motor Controller. The communication of these four controllers is done via a CAN bus. The GPS and Compass are connected to the Geo controller. The four Matbotix Ultrasonic sensors and the Bluetooth module are connected to the sensor controller board, while the LCD and LEDs are connected to Master Controller. RPM sensor, DC motor, and Servo motor are connected to Motor Controller. Also, all four CAN Transceiver are connected to their respective board.

//Not completed (To be added more)

Using the EasyEDA we designed a 2 layer PCB. The dimension of the PCB was 12.5" * 4.5". The four controllers were placed at the four corners of the PCB while the other components were placed at the center.

//Not completed (To be added more)


The wiring on the breadboard succeed on the first attempt but later when we kept adding the components as per the requirements the wiring became a complete mess and was entangling everywhere due to which the car could not navigate properly. Every time the car collided, the wires used to get disconnected. So reconnecting the wires and debugging the hardware every time after the collision was the main challenge. So we decided to go with PCB.

Power Management

The main power came from a 7.4v Lipo battery. This 7.4v from the battery was given to ECS. ESC gave a power output of 6V. This 6V was given to the Pololu voltage regulator. We used 5V Step-Up/Step-Down Voltage Regulator S9V11F5 for powering our four controllers and their respective components. The S9V11F5 helps in switching step-up/step-down regulator efficiently to produces 5V from input voltages between 2 V and 16 V. Its ability to convert both higher and lower input voltages makes it useful for applications where the power supply voltage can vary greatly, it's suitable for application where we use a battery. The Pololu is a very compact (0.3″ × 0.45″) module and also has a typical efficiency of over 90% and can supply a typical output current of up to 1.5 A when the input voltage is around 5 V.

//Not completed (To be added more)

1. Calculating the power requirement for each device.
2. Using only one battery was a challenge.
3. Splitting the power to 3.3V, 5V, 6V from one battery to different components.
4. Finding the pitch and dimensions of each component and placing them in the correct place and orientation.
5. Finding the correct power IC which can serve all the requirements.
6. Routing the wires on the PCB.

CAN Communication

<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management etc.>

Our message IDs were chosen based upon an agreed priority scheme. We assigned high priority IDs to messages that controlled the movement of the car, followed by sensor and GEO messages, and lowest priority messages were for debug and status.

Debug and status messages were sent in the 1Hz, and a few in the 10Hz, callbacks. The sensor and driver boards send data at the fastest rate (20Hz), so receiving all messages is done at 20Hz as well.

Each board managed MIAs using the auto generated API. Each board received all messages in one function call, and the service MIA function would be executed if messages a board was expecting did not arrive. The increment and threshold values for MIA were in units of milliseconds, so it was easy to adjust threshold values if we wanted a MIA to occur earlier or later.

Hardware Design

<Show your CAN bus hardware design>

DBC File

DBC File Link


NS_ :



 SG_ APP_COMMAND : 0|2@1+ (1,0) [0|0] "" GEO,DRIVER
 SG_ DC_MOTOR_DRIVE_SPEED_sig : 0|8@1+ (0.1,-10) [-10|10] "kph" MOTOR
 SG_ SERVO_STEER_ANGLE_sig : 8|8@1+ (1,-45) [-45|45] "degrees" MOTOR

 SG_ SENSOR_SONARS_left : 0|10@1+ (1,0) [0|0] "inch" DRIVER
 SG_ SENSOR_SONARS_right : 10|10@1+ (1,0) [0|0] "inch" DRIVER
 SG_ SENSOR_SONARS_middle : 20|10@1+ (1,0) [0|0] "inch" DRIVER
 SG_ SENSOR_SONARS_rear : 30|10@1+ (1,0) [0|0] "inch" DRIVER

 SG_ DEST_LATITUDE : 0|32@1+ (0.000001,-90.000000) [-90|90] "Degrees" GEO
 SG_ DEST_LONGITUDE : 32|32@1+ (0.000001,-180.000000) [-180|180] "Degrees" GEO

 SG_ CURRENT_HEADING : 0|12@1+ (0.1,0) [0|359.9] "Degrees" DRIVER,SENSOR
 SG_ DESTINATION_HEADING: 12|12@1+ (0.1,0) [0|359.9] "Degrees" DRIVER,SENSOR
 SG_ DISTANCE : 24|17@1+ (0.01,0) [0|0] "Meters" DRIVER,SENSOR

 SG_ GPS_CURRENT_LAT : 0|32@1+ (0.000001,-90.000000) [-90|90] "degrees" DRIVER,SENSOR,MOTOR
 SG_ GPS_CURRENT_LONG : 32|32@1+ (0.000001,-180.000000) [-180|180] "degrees" DRIVER,SENSOR,MOTOR


 SG_ CURRENT_DEST_LATITUDE : 0|32@1+ (0.000001,-90.000000) [-90|90] "Degrees" DRIVER
 SG_ CURRENT_DEST_LONGITUDE : 32|32@1+ (0.000001,-180.000000) [-180|180] "Degrees" DRIVER

  SG_ RC_CAR_SPEED_sig : 0|8@1+ (0.1,-10) [-10|10] "kph" DRIVER,SENSOR

  SG_ SIGNED_REGISTER_VAL_MAG_X : 0|16@1+ (1.0,0) [-2048|2047] "GAUSSIAN" DRIVER,SENSOR
  SG_ SIGNED_REGISTER_VAL_MAG_Y : 16|16@1+ (1.0,0) [-2048|2047] "GAUSSIAN" DRIVER,SENSOR

 SG_ RECEIVED_DEST_LATITUDE : 0|32@1+ (0.000001,-90.000000) [-90|90] "Degrees" SENSOR
 SG_ RECEIVED_DEST_LONGITUDE : 32|32@1+ (0.000001,-180.000000) [-180|180] "Degrees" SENSOR



 SG_ DBG_CAN_RX_DROP_COUNT : 1|16@1+ (1,0) [0|0] "drops" DRIVER,GEO,MOTOR



  SG_ DBG_DC_MOTOR_CURRENT_PWM_sig: 0|8@1+ (0.1,0) [10|20] "duty percent" DRIVER
  SG_ DBG_SERVO_MOTOR_CURRENT_PWM_sig : 8|8@1+ (0.1,0) [10|20] "duty percent" DRIVER
  SG_ DBG_PID_OUTPUT_VALUE_sig : 16|8@1+ (0.1,0) [0|0] "kph" DRIVER
  SG_ DBG_MOTOR_SELF_TEST_sig : 24|1@1+ (1,0) [0|0] "TRUE_FALSE" DRIVER

 SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR

 SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR

 SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR

  SG_ MOTOR_HEARTBEAT_sig : 0|8@1+ (1,0) [0|255] "pulse" DRIVER

CM_ BU_ DRIVER "The driver controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor 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;


Sensor ECU

<Picture and link to Gitlab>

Hardware Design

The sensor of choice for UTAH, was the LV-MAXSonar-EZ1 MB1010. The LV-MAXSonar-EZ1 comes in five different models for the ultrasonic sensor. These models are the MB1000, MB1010, MB1020, MB1030, and MB1040. The models are based on the beam width of the sensor. MB1000 has the widest beam pattern where as MB1040 has the narrowest. It was decided that the MB1010 model will be better suited for object detection. If the beam pattern is too wide given the MB1000, there is a greater chance of cross talk between sensors. If the beam pattern is too narrow, there may be blind spots which must be accounted for. Thus, four LV-MAXSonar-EZ1 MB1010 sensors were used. Three sensors were placed in the front and one in the rear of the vehicle. It will be noted that the SJTWO board is configured to have three ADC channels. Thus to account for a fourth sensor, the DAC was configured to be an ADC channel. More of this configuration will be discussed in the software design.

Front view of the MB1010 LV-MAXSonar-EZ1
Rear view of the MB1010 LV-MAXSonar-EZ1 with pin labels
Sensor Hardware Design

Sensor ADC Output to Inches Conversion

To extract range readings from the MB1010, the "AN" pin which represents analog output was utilized. A range reading is commanded by triggering the "RX" pin high for 20us or more. The output analog voltage is based on a scaling factor of (Vcc/512) per inch. All four of the sensors were powered from the SJTWO board, thus a 3.3v VCC was supplied to each sensor. According to the LV-MaxSonar-EZ datasheet, with 3.3v source, the analog output was expected to be roughly 6.4mV/inch. However, when initially testing the output range readings, the output was completely inaccurate. It was soon found out that the ADC channels are configured at start up to have an internal pull up resistor. Disabling this pull up resistor will be discussed more in Software Design. Once this solution was resolved, the range readings were more accurate. The readings were tested by having multiple objects placed in front of each sensor and measuring the distance of the object to the sensors. Although the range readings were more accurate, it was found that the range readings did not necessarily follow the expected 6.4mV/inch. As a result, range readings were off by roughly +/- 5 inches. To account for this,....[To be continued]

Software Design

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

Technical Challenges

< List of problems and their detailed resolutions>

Motor ECU

<Picture and link to Gitlab>

Hardware Design

Motor hardware wiring

Motor hardware Design

Motor Controller includes the controlling of the DC motor, Servo motor, Electronic speed control (ESC), and the wheel encoder. The job of the motor controller is both to steer and spin the wheels in order to move the RC car to the target destination. The DC motor, servo motor, and ESC(Traxxas ESC XL-05) were provided with the Traxxas RC car. The wheel encoder was purchased separately from Traxxas's website. The job of the DC motor is to control the spinning of the rear 2 wheels through the utilization of ESC and wheel encoder whereas the job of the servo motor is to control the steering of the front 2 wheels.

Motor Board Pinout
SJ2 Board Pin Description
5V Input power
3.3V CAN transceiver power
PWM2 P2.1 DC Motor Speed Control
PWM5 P2.4 Servo Motor Control
CAP0 P2.6 Input Capture for RPM Sensor
CAN1 TX CAN Module Tx
CAN1 RX CAN Module Rx
GND Grounding

DC Motor and ESC

The DC motor and ESC were provided with RC car. The DC motor is controlled by the ESC using PWM signals which were provided by the motor controller board for forward, neutral, and reverse movements. The ESC is powered ON using a 7.4 LiPo battery. The ESC converts this 7.4V to 6V and provides input to DC Motor.

DC Motor

ESC wires Description Wire Color
Vout Output Power (6V) RED
PWM PWM input from SJ2-Board (P2.1) WHITE

The car can be operated at 100Hz in the following 3 modes :
Sport Mode (100% Forward, 100% Brakes, 100% Reverse)
Racing Mode (100% Forward, 100% Brakes, No Reverse)
Training Mode (50% Forward, 100% Brakes, 50% Reverse)

The PWM frequency for our Traxxas ESC needed to be 100Hz. An idle (motor stopped) duty cycle is 15%. The full duty cycle range is [10%, 20%], where [10%, 15%) is the reverse range, and (15%, 20%] is the forward range. We ended up limiting the duty cycle range to [13%, 17%] since the RC car had more power than we needed.

Servo Motor

Servo Motor

Servo Wires Description Wire Color
Vin Input Voltage (6V) RED
PWM PWM input from SJ2-Board (P2.4) WHITE

The PWM frequency for our Traxxas Servo motor also needed to be 100Hz. An idle (wheel's pointing forward) duty cycle is 15%. The full duty cycle range is [10%, 20%], where [10%, 15%) is the steer left range, and (15%, 20%] is the steer right.

Wheel Encoder

For speed sensing we purchased a Traxxas RPM sensor as it mounted nicely in the gearbox. The RPM sensor works by mounting a magnet to the spur gear and a hall effect sensor fixed to the gearbox. To get the revolutions per second we used Timer2 as an input capture.

Servo Motor

RPM Sensor Wires Description Wire Color
Vin Input Voltage (6V) RED
Sensor Output Input Capture to SJ2-Board (P2.6) WHITE

Software Design

The motor controller code modules consisted of 3 main parts, which are: 1. PWM drivers and motor logic, 2. RPM/speed sensor, 3. PID controller.

1. PWM drivers and motor logic

The PWM drivers were fairly easy to write since the SJ2 project provided an API for the low level function calls. Converting speed and angle values to duty cycle values was done by simply linearly mapping one onto the other. This worked fine for steering control, but due to varying grades the car needs to drive on, the PID is needed. The Traxxas ESC, as other students have discovered in the past, has safeguards to prevent damage to the motor by not allowing duty cycle to abruptly change from a forward signal to a reverse. The Traxxas transmitter uses a trigger for this, but as other students suggested, we used a state machine to transition into opposite directions. We found that going from reverse to forward simply requires stopping (15% duty cycle) the car first, while going from forward to reverse required sending the following signals: STOP, REVERSE, STOP, REVERSE. Since we did not consult with Traxxas, this logic was created through trial and error. Transitioning into the opposite direction might simply just require stopping first, and then delay until a speed is reached, then change directions. We had access to an oscilloscope, however we did not capture what actually happens to the DC motor duty cycle when the transmitter does the same transition.

We created a separate module that encapsulated the motor's drive logic, such as getting speed feedback to compute PID value, updating the DC motor and servo motor's PWM in a state machine, and doing the start up self test. Another feature we incorporated was to have the motor controller listen for a message from the Bridge/App, so we could easily start and stop the car remotely. This feature was very helpful in testing.

Later on we also added the feature to run the Traxxas ESC setup by pushing a push button at start up. You need to hold the ESC button when you turn on the car until the green light turns red, then push SW3 on the motor board to run the ESC setup. The setup is fairly simple, it puts the DC motor PWM in full forward (20%) for 3 seconds, full reverse (10%) for 3 seconds, then neutral (15%) for 3 seconds before returning a true for finishing. The function is called in a periodic and the counts are kept track of internally by the function. The 3 seconds was a guess, but it seemed to work fine.

2. RPM/speed sensor

To count the time interval between pulses the RPM sensor makes, we used one of the LPC's peripheral timers that allowed for an input capture feature. We configured the hardware registers such that a capture register is written the value of the timer count register when the input capture (pulse from RPM sensor) occurs. This required writing a low level API so that we could unit test the hardware reading and writing. An interrupt also triggers on a capture event to reset the timer counter, to make the value in the capture register easy to convert to revolutions per second. The circumference of the car's tire and spur gear ratio are needed to determine a scalar value to convert the revolutions per second to conventional speed units. Many students said the RPM sensor from Traxxas was inconsistent and unreliable for speed feedback. We thought that this might be because of how the sensor is measuring the speed of the spur gear and that the differential of the car might cause variation, however when the car goes in a straight line that should not be a problem. When we integration tested the software design with the PID using the above approach, the speed readings seemed stable enough for use with the PID.

3. PID controller

For situations where the DC motor needs to do more or less work (e.g. driving uphill or downhill) the linear mapping will not work. The proportional, integral, derivative (PID) controller is a widely used control mechanism to ensure a machine maintains a set point, and responds quickly and smoothly upon disturbances. In discrete time the integration becomes a summation and the derivative becomes a difference. The controller is based on an error from the set point, which is why the RPM sensor is needed to get feedback. The PID algorithm is fairly simple, as is tuning the gains. We found that the proportional and integral gains were enough to get the car to maintain speed.

The way we tuned the PID was to start off by only using the proportional controller at a unity gain. We had the car drive on level ground and tested at 3kph and 5kph drive speeds. We varied the proportional gain until we saw the car have a "stop and go" motion. Then we dropped the proportional gain in half and tested again with a low integral gain. We now started testing on ground with a grade to see if speed could be maintained. We varied the integral gain until we were satisfied with the DC motor's response to varying terrain.

Below is our design for the motor controller's periodic callbacks.

Periodic Callbacks Initialize:
  • Initialize:
    • CAN bus
    • DC motor PWM
    • Servo motor PWM
    • RPM sensor input capture
    • PID
    • Motor logic

Periodic Callbacks 1Hz
  • Reset CAN bus if bus goes off
    • Have LED indicate CAN bus running status
  • Transmit motor debug message
  • Transmit motor CAN status

Periodic Callbacks 10Hz
  • At 2Hz transmit motor speed
  • Update steering angle and drive speed
    • Run ESC setup once user pushes button (Optional, can be bypassed)
    • At board power up a self test routine is ran (Also optional, but usually ran)
    • After the self test, Driver & Bridge/App controller commands are followed

Periodic Callbacks 100Hz
  • At 20Hz receive all messages from CAN bus and update local motor data structure
motor_logic__run_once() flowchart
motor_logic__update_motor_state_once() flowchart (see code, or description above, for more details on state machine)

Technical Challenges

  • Getting the state machine right for the DC motor to transition between forward and reverse, and vice versa, took some experimentation. Luckily other student's reports were available for us to get hints on what we needed to do.
  • When first tuning the PID our boards were attached via jumper wires and breadboard on a piece of plexiglass. The plexiglass was not rigidly secured to the car either, which resulted in collisions with walls and wires becoming undone. All this led to more hardware issues and had us backtrack to get the PID tuned. Making sure the hardware is sound before doing full integration tests will save you time. This requires planning out the hardware early on, and preferably just getting a PCB manufactured.
  • We were having problems during integration testing where the motors would not run. It's hard to say what the solution was for certain, but slowing down the rate we updated the PWMs (from 20Hz to 10Hz) seemed to be it.
  • We damaged the ESC somehow and needed to purchase another. This cost us time and money. Make sure you don't accidentally short the ESC!
  • Some unit tests were not written until after integration testing. This goes against test driven development, but due to deadlines we had to make a choice. Had we thought out the use cases of our modules and wrote unit tests sooner, I'm sure we would have avoided some in the field debugging.
  • The code had to be redesigned for modularity and readability later on. Make sure to avoid software anti-patterns, like "blob," and use dependency injection to prevent tightly coupled code modules.
  • We damaged one of the LiPo batteries we purchased because we drained the voltage below 3V per cell. Luckily we had another LiPo for testing, but having a voltage sensor to indicate to the app the battery level could be a good idea.

Geographical Controller


<Picture and link to Gitlab>

Hardware Design

The geographical controller runs all the processing for compass data as well as GPS data. The purpose of the controller is to interface with the Adafruit Ultimate GPS Breakout using UART which provides accurate GPS data formatted in GPGGA. The controller utilizes I2C protocol to interface with the Adafruit Magnetometer with tilt compensation for the purpose of finding our heading and where the car needs to point in order to get closer to its destination. The Adafruit magnetometer was able to give us accurate data with a possible deviation of up to 3 degrees in any direction. This was possible by using a software filter to normalize our data and create a standard.

Geo Hardware Design
Table 5. Geographical Node Pinout
SJTwo Board GPS/Compass Module Description Protocol/Bus
P4.28 (TX3) RX Adafruit GPS Breakout UART 3
P4.29 (RX3) TX Adafruit GPS Breakout UART 3
P0.10 (SDA2) SDA Adafruit Magnetometer I2C 2
P0.10 (SCL2) SCL Adafruit Magnetometer I2C 2
P0.1 (SCL1) CAN transceiver (Tx) CAN transmit CAN
P0.0 (SDA1) CAN transceiver (Rx) CAN receive CAN
Vcc 3.3V Vcc Vcc
GND GND Ground

Software Design

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

Technical Challenges

< List of problems and their detailed resolutions>

Communication Bridge Controller & LCD


Hardware Design

The bridge controller and sensor controllers were merged together on one board. For the hardware pinout, view the schematic located in the sensor controller section.

The hardware for the controller is a very straight forward design. Connect the HC-05 Bluetooth module to UART out of the board. The phone used for testing purposes must have a Bluetooth Adapter for these purposes. For this reason, an emulated phone was unable to be used for anything except graphics and viewing purposes.

To configure the HC-05, a Raspberry Pi 4 was setup to terminal into the HC-05 over UART. This site was helpful in the setup: https://www.instructables.com/Modify-The-HC-05-Bluetooth-Module-Defaults-Using-A/. One note, a few sites showed the command for setting the baud rate to be +AT+BAUD=____. This was invalid for the HC-05 and requires the +AT_UART= Baud, stop, parity.

Software Design

Bridge Controller

To avoid mismatching data, a sort of semi brute force method was used for the messaging. All messages are decoded in the 10hz periodic every cycle. The Bluetooth messages are sent in chunks in the 10 Hz periodic to avoid the overlapping of the messages, sending groups of messages at one time. The grouping is as follows: Driver and motor messages, GEO, then Sensors. MIA checks for all messages is done in the 1 Hz periodic. This setup was extremely helpful for identifying if a board was flashed with the incorrect code or stopped sending messages that were supposed to be sent.


When the app first opens the Bluetooth socket that is created is checked if it is NULL, which it should be with startup. If this occurs the Bluetooth connection screen will be brought up and the user will need to tap a device to attempt a connection. If the connection fails, the screen will again be brought up. Once a connection is established with the Bridge Controller the main screen will be brought up. The first thing that can be seen is the Map. A few precautions were taken so nothing would happen to the map's camera when the user attempts to click on the map while the GPS is not sending accurate data. A blue pin is used to represent the car's current location once good data is being received. When this data is updated, this pin is moved. A default destination is used for the 10th street garage for some ease of testing and to accommodate camera repositioning. The camera is repositioned to the averaged of the destination and the current location. Once the desired destination is selected, the latitude and longitude of the selection will be displayed under the map. The car can be started by pressing the Send Coordinates button located at the bottom of the scroll window. This will send coordinates, truncated down to a float instead of a double, onto the can bus.

Technical Challenges

There were a few major problems encountered with the Application and Bluetooth.

The largest problem was actually sending data to the App in a timely manner. Converting all of the messages to strings to send through bluetooth was found to be too slow and would result in messages crossing over on top of one another. Even with the UART baud rate increased to the maximum speed of 115,200 for the HC-05, the messages would blur together at times. The easiest fix was to only populate the some of the messages in a given 10hz callback. Only two of the boards were able to be grouped together to send, motor and driver. The other controllers' messages were sent in one time slot.

Connecting to google maps was much easier than anticipated. The tutorial here: https://developers.google.com/maps/documentation/android-sdk/start, is a great way to add the map portion in.

Thinking about message format and structure early was key. Setting up with good modular design saved a lot of time after implemented and made the code much easier to read.

Master Module

<Picture and link to Gitlab>

Hardware Design

Master controller Hardware Design

Software Design

Driver logic UTAH.jpg

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

Technical Challenges

< List of problems and their detailed resolutions>

Mobile Application

<Picture and link to Gitlab>

Hardware Design

Software Design

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

Technical Challenges

< List of problems and their detailed resolutions>


<Organized summary of the project>

<What did you learn?>

Project Video

Project Source Code

Advise for Future Students

<Bullet points and discussion>