Difference between revisions of "S19: Run D.B.C"

As stated before, we used an Adafruit MTK3339 Ultimate GPS module. An external antenna was integrated, in order to help parse the GPS data more efficiently. The GPS module used UART, to communicate with the SJOne board. The baud rate for the UART interface had to be initialized twice in the code: 9600bps at first and then 57600bps. This was because the GPS set its baud rate to 9600bps by default, but we required a higher baud rate.

The GPS module came with a GPS lock, which allowed it to use satellite feedback to parse its location. This lock was indicated by an LED, which illuminated once every 15 seconds. If no lock was found then the LED illuminated once every 1-2 seconds. The parsing of data from the GPS was in terms of NMEA sentences, each of which had a specific functionality. Out of the several NMEA sentences, $GPRMC was used. It provided essential information, such as latitude and longitude coordinates. The $GPRMC sentence is separated by commas, which the user had to parse in order to get useful data out of the module. The strtok() function is used to parse data from the GPS module, with comma(,) as the delimiter.

Geographic Controller Schematic

Software Design

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

Technical Challenges

<Bullet or Headings of a module>

Bug Tracking

<Problem Summary> <Problem Resolution>

Bill Of Materials

MASTER CONTROLLER

<Picture and link to Gitlab>

Hardware Design

The master controller is primarily interfaced with the other controllers over CAN bus. The other main interface is control of the LCD display for debug data, which communicates over UART.

Software Design

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

• LCD display
• CAN read and send
• Navigation
  • obstacle avoidance
  • steer to checkpoint

Technical Challenges

<Bullet or Headings of a module>

Bug Tracking

<Problem Summary> <Problem Resolution>

Bill Of Materials

MOTOR CONTROLLER

<Picture and link to Gitlab>

Hardware Design

Software Design

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

Technical Challenges

<Bullet or Headings of a module>

• We had to change the PWM driver to hard code the sys_clock frequency. We found solution.

• Original encoder sourced is was designed to be a knob, not a motor encoder. The additional rotational resistance caused vibrations and resulted in it becoming disconnected from the motor shaft several times. The solution was to us a slightly more expensive encoder, designed for higher speed continuous operation on a motor.

Bug Tracking

<Problem Summary> <Problem Resolution>

Bill Of Materials

SENSOR CONTROLLER

Hardware Design

We put in a lot of thoughts on how sensors should be placed on the car. In order to facilitate easy adjustment of sensor direction, we incorporated circular grooves in the sensor bases so the mount left/right direction can be adjusted on the fly. The hinge of the sensor mount also allows sensors to be tiled up and down, together with the sensor mount, offering two degrees of freedom.

CAD Design

Picture on the left shows the hinge of the sensor guard can be adjusted to minimize the amount of interference between sensors.
Picture on the right shows the hinge of the sensor mount allows sensors to be tiled up and down.

Placement for the Ultrasonic Sensors

We realized that when the sensors are turned on, the left and right sensors output ultrasonic waves that can interfere that of the middle sensor, even though we purposefully place them in different iterations of the periodic tasks. However, by placing the middle sensor on a higher ground, interference decreases. Moreover, by attaching two guard pieces on the left/right sensors we can further minimize the amount of interference between sensors. The integrity of sensor readings was rigorously tested with the guards to make sure they don’t lead to inaccurate readings for left and right sensors.

Software Design

Flowchart

Timing Diagram

Technical Challenges

Sensor Interference

We saw a lot of interference between the front 3 sensors. We were able to overcome the issue with both hardware and software tweaks:

• Higher placement of middle ultrasonic sensor and interference guard for the left and right sensors

• Instead of leaving the RX pin of the sensors unconnected, which causes the sensors to output ultrasonic waves continuously, we toggle the RX pin to turn off sensor ranging and only allow wave output when we need it. The periodic callback function is also written in a way that staggers sensor trigger and sensor reading in a way to ensure sufficient time before ADC read.

Power Deficiency

At first, when the sensors are tested as an individual module, everything is fine. However, when the modules are integrated towards the end of the semester, suddenly they all start to output erroneous data. After many hours of troubleshooting we realized that our power supply was not enough to power everything on the car. We fixed it by having battery with higher power output.

HR-04 unstable reading

At first, our left and right sensors are two HC-SR04 modules from Ebay. However when we tested them during obstacle avoidance we realized that they have very narrow range and can sometimes not see what is in front of them. As a result we switched to more expensive, but reliable Maxbotix EZ line of sensors.

The ADC module can only read 3.3V

Our middle sensor was having fluctuating readings that were very difficult to filter. After hours of testing we realized that we are connecting it to 5V supply but uses the ADC of SJone board to read distance value. As the ADCs of SJone cannot read above 3.3V, this is the reason for the erroneous data and after we switched the sensor to 3.3V supply, the problem disappeared.

Bug Tracking

Slow car response to obstacle due to large queue size (running average)

During our first try at obstacle avoidance we found that the car reacts very slowly to obstacles, even though the sensor update rate is 10Hz. Later we found out that the reason is because of our queue implementation. We used to have a very large queue to calculate running average. This filters out spikes but also means when an obstacle is detected it takes very long time for the running average to be updated.

• Solution: Decrease the queue size and find median value instead of average to output to the master module.

Bill Of Materials

CONCLUSION

<Organized summary of the project>

<What did you learn?>

Project Video

Project Source Code

Advice for Future Students

<Bullet points and discussion>

Grading Criteria