Difference between revisions of "S21: (RC)^2"

Revision as of 15:18, 28 May 2021

(RC)²

(RC)² <Add Pictures of it here!>

Abstract

Team (RC)² built an RC car capable of navigating to a destination controlled by an Android application while avoiding obstacles that may be in its path. The RC car is composed of various nodes that each have a specific task such as reading sensor data, controlling the motor, and attaining compass values. These individual nodes communicate and share pertinent information regarding the car’s operation with each other over a CAN bus.

Introduction

The project was divided into five main components that were important to the RC car as a whole:

• Sensor Node
• Motor Node
• Geographic Controller
• Communication Bridge/OLED
• Driver Node

Team Members & Responsibilities

<Team Picture>

Gitlab Project Link - https://gitlab.com/rc-2/sjtwo-c

• Sensor
  • Huy - https://gitlab.com/vyhuy2004
  • Prabjyot - https://gitlab.com/PrabjyotObhi

• Motor
  • Jesse - https://gitlab.com/JessePhams
  • Michael - https://gitlab.com/mwmichaelwang

• Geographical
  • Brian - https://gitlab.com/Brian1234132
  • Arun - https://gitlab.com/arunhiremath92

• Communication Bridge Controller & LCD
  • Prabjyot - https://gitlab.com/PrabjyotObhi
  • Arun - https://gitlab.com/arunhiremath92

Schedule

Parts List & Cost

TODO: Check Drive and add to this table

Printed Circuit Board

CAN Communication

Priority Logic:

• Our two highest priority signals are DRIVE_STOP and DRIVE_START, and we prioritized stopping the car over starting the car as a matter of safety.
• GPS_DESTINATION_LOCATION is the next highest signal because we would need to have a valid location to be able to properly navigate the car.
• SONAR_VALUES has a priority right below GPS_DESTINATION_LOCATION because once the destination is set, the car would need to read sensor data to avoid potential obstacles.
• COMPASS_HEADING_DISTANCE would be the signal with a priority below the SONAR_VALUES signal as the car would need a proper heading in order to navigate to a destination.
• MOTOR_VALUE is the signal sending from Driver Node to the Motor Node to actuate the car
• The signals with the lowest priority are those that we used in our debugging process over Busmaster.

Missing-In-Action Management:

• Driver: stop the car when missing the Sensor information when the frame is missing for more than 500ms
• Motor: straighten the car out and stop the car
• Geo: <insert version>

Hardware Design

Our initial CAN bus was based on a breadboard that contained a lot of jumper/dupont wires. This design was sufficient for testing purposes as we worked to meet the in-class checkpoints; however, as we developed our RC car, we realized that a handful of connections were troublesome to the development of the car. As opposed to continuously rewiring and checking connections, we decided to invest time into PCB design to minimize connections and fix hardware issues. Below is a before and after comparison of our RC Car.

DBC File

Current 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 IO MOTOR SENSOR GEO BRIDGE


BO_ 101 DRIVE_STOP: 1 BRIDGE
 SG_ DRIVE_STOP : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 102 DRIVE_START: 1 BRIDGE
 SG_ DRIVE_START : 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 121 GPS_DESTINATION_LOCATION: 8 BRIDGE
 SG_ DEST_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "deg" GEO
 SG_ DEST_LONGITUDE : 28|29@1+ (0.000001,-180.000000) [-180|180] "deg" GEO

BO_ 131 SONAR_VALUES: 8 SENSOR 
 SG_ SONAR_VALUES_left : 0|8@1+ (1,0) [0|150] "cm" DRIVER 
 SG_ SONAR_VALUES_right : 8|8@1+ (1,0) [0|150] "cm" DRIVER 
 SG_ SONAR_VALUES_front : 16|8@1+ (1,0) [0|150] "cm" DRIVER 
 SG_ SONAR_VALUES_back : 24|8@1+ (1,0) [0|150] "cm" DRIVER

BO_ 141 COMPASS_HEADING_DISTANCE: 8 GEO
  SG_ HEADING : 0|12@1+ (0.1,0) [0|359.9] "deg" DRIVER,BRIDGE
  SG_ BEARING : 12|12@1+ (0.1,0) [0|359.9] "deg" DRIVER,BRIDGE
  SG_ DISTANCE : 24|17@1+ (0.01,0) [0|0] "m" DRIVER,BRIDGE 

BO_ 151 MOTOR_VALUES: 3 DRIVER
 SG_ MOTOR_VALUES_speed : 0|8@1+ (1,-25) [-25|25] "kph" MOTOR
 SG_ MOTOR_VALUES_steering : 8|6@1+ (0.1,-2.1) [-2.1|2.1] "deg" MOTOR

BO_ 161 MOTOR_VALUES_TO_DRIVER: 3 MOTOR
 SG_ MOTOR_VALUES_TO_DRIVER_speed : 0|8@1+ (1,-25) [-25|25] "kph" DRIVER

BO_ 171 GPS_DESTINATION_REACHED: 1 GEO
 SG_ DESTINATION_REACHED : 0|1@1+ (1,0) [0|1] "bool" DRIVER,BRIDGE

BO_ 181 GPS_RAW_DATA: 8 GEO
 SG_ CURR_LATITUDE : 0|28@1+ (0.000001,-90.000000) [-90|90] "deg" BRIDGE
 SG_ CURR_LONGITUDE : 28|29@1+ (0.000001,-180.000000) [-180|180] "deg" BRIDGE
 SG_ GPS_QUALITY : 57|2@1+ (1,0) [0|2] "val" BRIDGE

BO_ 182 COMPASS_ACCEL_RAW_DATA: 6 GEO
 SG_ ACCEL_X : 0|16@1+ (0.01,-162.01) [-162.01|162.01] "ms^2" BRIDGE
 SG_ ACCEL_Y : 16|16@1+ (0.01,-162.01) [-162.01|162.01] "ms^2" BRIDGE
 SG_ ACCEL_Z : 32|16@1+ (0.01,-162.01) [-162.01|162.01] "ms^2" BRIDGE

BO_ 183 COMPASS_MAG_RAW_DATA: 6 GEO
 SG_ MAG_X : 0|16@1+ (0.01,-162.01) [-162.01|162.01] "mT" BRIDGE
 SG_ MAG_Y : 16|16@1+ (0.01,-162.01) [-162.01|162.01] "mT" BRIDGE
 SG_ MAG_Z : 32|16@1+ (0.01,-162.01) [-162.01|162.01] "mT" BRIDGE

BO_ 191 DRIVER_HEARTBEAT: 1 DRIVER
 SG_ DRIVER_HEARTBEAT_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR, MOTOR, GEO

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_ 191 "Sync message used to synchronize the controllers";
CM_ SG_ 191 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";

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

Sensor ECU

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

Motor ECU

Motor Node GitLab Link

Connection of all four Motor modules to SJ2 Board

Hardware Design

The hardware design for the motor node requires four main components to be connected to the SJ2 Board:

1. CAN Transceiver

This module will be used to communicate with the Driver Node to receive the desired speed and steering angle through CAN communication protocol. This module will also be used to transmit the car's current speed to the Driver Node. The CAN transceiver will be powered by a +3.3V source with its Transmit Line (T_x) connected to GPIO Pin P0.1 and its Receive Line (R_x) connected to GPIO Pin P0.0.

RC Transmit Controller

2. RC Transmit Controller

Due to the Electronic Speed Controller (ESC) being completely resined into the RC Car's base, there was no direct method of controlling the provided ESC with the SJ2 Board. The team decided to control the ESC using the transmit controller by measuring the internal potentiometer's voltage signal line to the transmit circuit and replicating those voltage values with a Digital-to-Analog Converter (DAC). This transmit controller takes in two input lines to its ports:

• CON2 PORT

This port takes in one input, which controls the steering angle of the car. The voltage value for the steering to be straight was measured at +2.0V. Lower voltage values steer the car left and higher voltage values steer the car right. The voltage input to this port comes from the External DAC.

• CON3 PORT

This port takes in one input, which controls the speed of the car. The voltage value for the car to be stationary was measured at approximately +1.5V. Lower voltage values accelerated the car forward and higher voltage values accelerated the car backwards. The voltage input to this port comes from the SJ2 Board's DAC pin P0.26.

External DAC

3. External DAC

Since the SJ2 Board has only one DAC pin, which is used to control the motor speed, an additional external DAC is needed to control the car's servo motor for steering.

HC-020K Wheel Encoder

4. Wheel Encoder

This module is used by the motor node to measure the car's speed by keeping track of how many revolutions the rotary revolves around the sensor. The rotary contains twenty hole slits, so a full revolution will "tick" the sensor twenty times.

Software Design

The motor node is designed to receive a desired speed and a desired steering angle from the driver node. These values will be used to adjust the RC Car's motor speed and servo motor angle to align with those requested values.

There are four public functions that are provided in the motor node.

1. void motors__init(void)

This function is used by the periodic callback to initialize the required peripherals used to control the motor speed as well as the servo motor angle.

2. void motors__run(void)

This function is used by the periodic callback to set the motor speed and the servo motor angle. This public function will invoke two private functions, motors__speed_handler() which handles the motor speed of the car, and motors__steering_handler() which handles the steering angle of the car.

• motors__speed_handler()

This private function controls the RC Car's speed, which is calculated by measuring the circumference of the car's wheel and finding out how many times it rotates within a given time frame. Setting the time frame and obtaining the circumference of the wheel is trivial, however, obtaining the amount of rotations required additional effort. We used an HC-020K Wheel Encoder to measure how many times the wheel rotated around its axle and connected the +5V output to one of the SJ2's GPIO pins. This pin was then attached to an interrupt service, which incremented the static variable holding the number of times the wheel has rotated. The sample code to calculate the speed of the car is shown below.

    static int8_t motors__private_get_speed_kmh(void) {
      int8_t motor_speed = current_speed_kmh;
      uint64_t current_time_ms = sys_time__get_uptime_ms();
      uint64_t time_elapsed_ms = current_time_ms - wheel_encoder_previous_time_ms;

      if (time_elapsed_ms >= 100U) {
        wheel_encoder_previous_time_ms = current_time_ms;

        if (time_elapsed_ms > 0) {
          float number_of_wheel_cycles = (float)wheel_encoder_number_of_ticks / (float)WHEEL_ENCODER_TICKS_PER_CYCLE;
          float distance_travelled_cm = (float)(number_of_wheel_cycles * WHEEL_CIRCUMFERENCE_CM);

          motor_speed =
              (distance_travelled_cm / CENTIMETERS_IN_ONE_KILOMETER) / ((float)time_elapsed_ms / MILLISECONDS_IN_ONE_HOUR);

          wheel_encoder_number_of_ticks = 0U;

          if (MOTORS__DIRECTION_REVERSE == current_motor_direction) {
            motor_speed *= -1;
          }

        }
      }

    return motor_speed;
  }

• motors__steering_handler()

This private function controls the RC Car's steering angle.

The steering driver works in a similar way to how the motor driver works in the sense that it makes use of a digital to analog converter (DAC) to send signals to the motor transceiver to tell the car how much to steer. First, the motor node receives a CAN message through the CAN bus that contains a float value from within the range of -2.1 (full lock to the left) to 2.1 (full lock to the right). The steering driver then converts this float to an integer number used to write to the 12-bit DAC through I2C communication. Essentially, the range [-2.1, 2.1] which has 42 steps, is mapped to the range of [0, 4096] using the equation: (input + 2.1) * 10 * 4096 / 42.

3. void motors__set_speed_and_steering_values(dbc_MOTOR_VALUES_s *motor_values)

This function is used by the CAN Bus Message Handler to set the desired speed and steering angle. When the CAN Bus Message Handler module receives a CAN package, it will decode the motor values and call this function. This function is also used by the MIA handler as well to stop the RC Car if it doesn't receive any CAN messages from the driver node ten times in a 10Hz periodic callback.

4. dbc_MOTOR_VALUES_TO_DRIVER_s motors__get_motor_values(void)

This function is used by the CAN Bus Message Handler to transmit the current speed of the car.

Technical Challenges

• Electronic Speed Controller (ESC)

When opening the RC car, the team found that the ESC was fully resined into the car's base. This prevented the team from directly controlling the ESC, so the team decided to control the RC car's speed and steering through the RC car's remote transceiver. The remote transceiver was taken apart and the team discovered that the user controlled the speed and steering through the use of two potentiometers, which sent specific voltage values to the transceiver's circuit and sent those values to the ESC remotely via Bluetooth. The team developed an internal DAC driver and an external DAC driver to send controlled voltage values to the transceiver to simulate the potentiometer output values.

• Wheel Encoder Issues

During the integration of the wheel encoder, our team encountered various issues regarding its positioning on the car and its debouncing circuitry.

Due to the shape of the RC car's plastic base, it was difficult to find a position on the car to place the wheel encoder such that it could accurately read the amount of revolutions the rotary wheel has made. The encoder must be placed near the axle of the wheel, however, there was no platform large enough to fix the encoder onto. The team purchased a metal "L" bracket and fixated the bracket onto one of the base's thin plastic platforms. This bracket was used as a new platform to mount the wheel encoder onto for better positioning and reading accuracy.

Additionally, mounting the rotary wheel onto the axle was another issue. Initially, the rotary wheel had to be broken apart and crudely super-glued together. However, this solution resulted in a less accurate encoder reading due to the rotary being warped from the initial break. The team 3D printed a new rotary wheel in two separate pieces to resolve the warping issue from breaking it ourselves. This resulted in a more consistent, accurate encoder reading.

• Motor startup sequence

Initially, when starting up the car, the team faced an issue where although voltage values are being sent to accelerate the car, the car would remain stationary. The solution to this issue was found in the user manual. According to the RC Car's user manual, both the acceleration and the steering triggers must be neutral when powering on the car. This means that when starting up, both the motor and the servo motor must be set to specific voltage values. The team measured the potentiometer's voltage value outputs when the triggers were in a neutral position and used those voltage values when starting up.

Geographical Controller

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

Challenge: One of the largest challenges we had with the geo_node was processing the heading value to send over the CAN bus. This was an issue because the heading value would change drastically when the car itself would shake, and the car shakes quite a lot. This resulted in occasional sporadic heading values causing the car to behave chaotically.

Solution: The best solution to the heading resulting in sporadic values was to take an average of the heading values and use a certain threshold to determine whether or not to throw out a processed heading value. This solution of taking an average and using a threshold created a problem of going from 360 to 0 as the difference between these would never be within the threshold. We solved the issue by mapping our raw degree values to their sine values to allow the values to fit within the threshold.

Communication Bridge Controller & OLED

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

Master Module

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

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>

Conclusion

Conclusion <Organized summary of the project>

To conclude, (RC)^2 was a success and we are proud of the RC car. <write more>

<What did you learn?>

• CAN Communication Protocol
• Code modularization
• DBC Files
• Unit Test
• Debugging
• Mobile Application Design

<write more>

Project Video

Project Source Code

• Git Project Link: RC²

Advice for Future Students

<Bullet points and discussion>

Acknowledgement

• Arun's roommate?

=== References ===