Difference between revisions of "S19: Run D.B.C"
Proj user10 (talk | contribs) (→Hardware Design) |
Proj user10 (talk | contribs) (→Hardware Design) |
||
| Line 1,003: | Line 1,003: | ||
=== <font color="EE82EE"> Hardware Design </font> === | === <font color="EE82EE"> Hardware Design </font> === | ||
| − | The motor board was responsible for both steering and spinning the wheels in order to move the car in a targeted direction. | + | The motor board was responsible for both steering and spinning the wheels in order to move the car in a targeted direction. <br> |
The front 2 wheels of the car handled the steering portion and it accomplished this with the utilization of the servo. <br> | The front 2 wheels of the car handled the steering portion and it accomplished this with the utilization of the servo. <br> | ||
| − | The servo was included with the RC we purchased and it was interfaced with 3 pins. These 3 pins consisted of: < | + | The servo was included with the RC we purchased and it was interfaced with 3 pins. <br> |
| − | < | + | These 3 pins consisted of: |
| + | <b> <br> | ||
1 pin for the power supply, which was powered by the battery that came with the RC car (as opposed to the same supply that other components on our PCB shared) <br> | 1 pin for the power supply, which was powered by the battery that came with the RC car (as opposed to the same supply that other components on our PCB shared) <br> | ||
1 pin for the ground signal <br> | 1 pin for the ground signal <br> | ||
1 pin for the PWM control signal <br> | 1 pin for the PWM control signal <br> | ||
| − | </b> | + | </b> <br> |
| + | |||
===== <font color="EE82EE"> '''''Speed Control Timing Diagrams''''' </font> ===== | ===== <font color="EE82EE"> '''''Speed Control Timing Diagrams''''' </font> ===== | ||
Revision as of 20:09, 22 May 2019
Contents
- 1 ABSTRACT
- 2 INTRODUCTION & OBJECTIVES
- 3 SCHEDULE
- 4 BILL OF MATERIALS (GENERAL PARTS)
- 5 HARDWARE INTEGRATION PCB
- 6 CAN NETWORK
- 7 ANDROID MOBILE APPLICATION
- 8 BRIDGE CONTROLLER
- 9 GEOGRAPHIC CONTROLLER
- 10 MASTER CONTROLLER
- 11 MOTOR CONTROLLER
- 12 SENSOR CONTROLLER
- 13 CONCLUSION
- 14 Grading Criteria
ABSTRACT
The RUN-D.B.C project, involves the design and construction of an autonomously navigating RC car. Development of the R.C car's subsystem modules will be divided amongst and performed by seven team members. Each team member will lead or significantly contribute to the development of at least one subsystem.
INTRODUCTION & OBJECTIVES
|
RC CAR OBJECTIVES | ||||
|---|---|---|---|---|
| ||||
|
TEAM OBJECTIVES | ||||
|---|---|---|---|---|
| ||||
|
CORE MODULES OF RC CAR | ||||
|---|---|---|---|---|
| ||||
|
PROJECT MANAGEMENT ADMINISTRATION ROLES | ||||
|---|---|---|---|---|
| ||||
|
TEAM MEMBERS & RESPONSIBILITIES | ||||
|---|---|---|---|---|
|
Team Members |
Administrative Roles |
Technical Roles | ||
|
|
| ||
|
| |||
|
|
| ||
|
| |||
|
| |||
|
| |||
|
| |||
SCHEDULE
|
TEAM MEETING DATES & DELIVERABLES | ||||
|---|---|---|---|---|
|
Week# |
Date Assigned |
Deliverables |
Status | |
| 1 | 2/16/19 |
|
| |
| 2 | 2/24/19 |
|
| |
| 3 | 3/3/19 |
|
| |
| 4 | 3/10/19 |
|
| |
| 5 | 3/17/19 |
|
| |
| 6 | 3/24/19 |
|
| |
| 7 | 3/31/19 |
|
| |
| 8 | 4/7/19 |
|
| |
| 9 | 4/14/19 |
|
| |
| 10 | 4/21/19 |
|
| |
| 11 | 4/28/19 |
|
| |
| 12 | 5/5/19 |
|
| |
| 13 | 5/12/19 |
|
| |
| 13 | 5/19/19 |
|
| |
| 14 | 5/22/19 |
|
| |
BILL OF MATERIALS (GENERAL PARTS)
|
MICRO-CONTROLLERS | ||||
|---|---|---|---|---|
|
PART NAME |
PART MODEL & SOURCE |
QUANTITY |
COST PER UNIT (USD) | |
|
|
|
| |
|
RC CAR | ||||
|---|---|---|---|---|
|
PART NAME |
PART MODEL & SOURCE |
QUANTITY |
COST PER UNIT (USD) | |
|
|
| ||
|
|
| ||
|
|
| ||
HARDWARE INTEGRATION PCB
Hardware Design
The hardware integration PCB was designed with two goals:
1. Minimize the footprint of the onboard electronics
2. Minimize the chances of wires disconnecting, during drives
To accomplish these goals, all controllers were directly connected to the board's 34 pin header arrays, while all sensors were connected to the board, using ribbon cables and locking connectors. The master controller's header pins were inverted and then connected to a header array on top of the PCB, while the other controllers were mounted to the bottom. This guaranteed secure power and signal transmission paths, throughout the system.
The board consisted of 4 layers:
Signal
3.3V
5.0V
GND
Technical Challenges
Design
- Balancing priorities between HW design and getting a working prototype
- Finalizing a PCB design, when some components and module designs are not nailed down
Assembly
- DB-9 connector for CAN dongle was wired backwards in the PCB design. Because there are several unused pins, we were able to just solder jumper wires to connect CAN HI and CAN LOW to the correct pins.
- Spacing for headers with clips were not accounted for properly in the design. two of them are very close. It's a tight fit, but it should work.
- Wireless antenna connector on master board not accounted for in footprint, it may have to be removed to avoid interference with one connector.
Bill Of Materials
|
HARDWARE INTEGRATION PCB | ||||
|---|---|---|---|---|
|
PART NAME |
PART MODEL |
QUANTITY |
COST PER UNIT (USD) | |
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
CAN NETWORK
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management etc.>
Hardware Design
<Show your CAN bus hardware design>
DBC File
<Gitlab link to your DBC file> <You can optionally use an inline image>
ANDROID MOBILE APPLICATION
Software Design
Development of the Android Mobile Application happened in two phases. The first involved setting up bluetooth communication between the HC-05 and the Android mobile phone, while the second involved integrating Google Maps into the application. Both phases presented unique technical challenges that we had to address.
Bluetooth Integration
Maintaining a bluetooth connection between the Android phone and the HC-05 module, proved to be more arduous that we expected. Luckily, Google provided extensive resources to help with the process, on the Android developer website (this might be the best starting point for future CMPE 243 app developers, or anyone else interested in developing an app like this.
1. Grant the phone permission to establish a bluetooth connection and access its location. We needed three to get started:
BLUETOOTH
BLUETOOTH ADMIN
ACCESS COARSE LOCATION
These permissions were included in the Application's manifest file.
Google Maps Integration
Technical Challenges
<Bullet or Headings of a module>
Bug Tracking
<Problem Summary> <Problem Resolution>
Bill Of Materials
|
ANDROID MOBILE APPLICATION | ||||
|---|---|---|---|---|
|
PART NAME |
PART MODEL |
QUANTITY |
COST PER UNIT (USD) | |
|
|
|
| |
BRIDGE CONTROLLER
Hardware Design
The Bridge controller acted as an interface between the Android mobile phone and the car. Its main purposes were to start and stop the car wirelessly and to send destination (latitude and longitude) coordinates to the geographic controller, for use with its pathfinding algorithm.
Our approach, involved pairing an HC-05 bluetooth transceiver with the Android mobile phone and then transmitting coordinates to and from the bridge controller using UART. Checkpoints along the path-to-goal, were transmitted over CAN, to the bridge, from the geographic controller.
Upon startup, 3.3V was supplied to the HC-05.
When the user clicked the "Discover" button the app, the Android mobile phone, initiated a pair and connect sequence, with the HC-05 (using its MAC address). Upon a successful pairing, the HC-05's LED blinks slowly as opposed to a few times a second (when unpaired).
The HC-05 used UART transmit and receive queues on the SJOne board, to store data, before transmitting it to the mobile app over bluetooth.
Bridge Controller Schematic
Software Design
Periodic Callback: Init
Upon startup, the bridge controller initiated both its UART and CAN peripherals. In order to communicate with the Android mobile phone over bluetooth, we had to use a baud rate of 9600bps. We set our transmit and receive queue sizes to 64 bytes, respectively. We also reset the CANbus, in order to ensure proper functionality.
Periodic Callback: 1Hz
In order to verify that the Bridge Controller's CAN transceiver was operational, we sent a heartbeat message every 1Hz, to the master controller. We used an integer value '0', for simplicity. If the bridge's CAN transceiver malfunctioned, the master controller illuminated the first (onboard) LED on itself (SJOne board). This allowed us to detect MIA modules quickly, without needing to connect to the Busmaster immediately.
We also checked the status of the CANbus every 1Hz and reset the bus if it was not operational. This was to ensure that a CAN glitch would not permanently compromise the bridge controller.
Periodic Callback: 10Hz
As stated before, the Bridge Controller acted as an interface between the Android Mobile phone and the car. Therefore we needed to transmit and receive coordinates and command from the phone, as well as to/from other modules on the car.
We checked the UART receive queue for START and STOP commands from the Android mobile phone. If one was received, then a CAN message was transmitted to the Master Controller, suggesting that it either apply or terminate power to the motor. For simplicity, we sent a character, '1' for START and '0' for STOP.
We also checked for essential navigation data from the Geographic Controller and Sensor Controller. We expected the car's starting coordinates (latitude and longitude), heading, deflection angle and distance to destination from the Geographic Controller. From the Sensor Controller, we expected feedback from the front, middle and rear distance sensors, as well as the infrared sensor mounted on the back of the car. This data was stored in a UART transmit queue and then transmitted to the Android mobile phone over bluetooth, every 2Hz. The Android application displayed feedback from the Geographic and Sensor controllers below its Google Map fragment.
Technical Challenges
UART Receive While Loop
The primary technical challenge that we encountered, while developing the Bridge Controller, occurred during a demo. In an effort to improve the delays between displaying bridge data on the Android phone, we tried nesting a UART receive statement in a while loop. Unfortunately this caused the Bridge Controller to continuously crash. We realized that the SJOne's UART receive indication LED, was constantly illuminated, as opposed to flickering 10 times a second (since we were receiving in the 10Hz periodic callback function. We changed the while loop to an if statement and the problem was solved.
Bill Of Materials
|
BRIDGE CONTROLLER | ||||
|---|---|---|---|---|
|
PART NAME |
PART MODEL |
QUANTITY |
COST PER UNIT (USD) | |
|
|
| ||
GEOGRAPHIC CONTROLLER
Hardware Design
The geographical controller, was responsible for providing the required directions, in order for the car to navigate from a fixed starting point, to a destination. the four primary feedback parameters, used by this module, were the latitude and longitude coordinates of the starting and ending locations, the heading (direction which the car is pointing) and the bearing angle (the angle between the heading of the car and the destination).
We employed an Adafruit MTK3339 Ultimate GPS module and the CMPS12 9DOF compass module, in order to obtain the heading and bearing angle.
The car's starting latitude and longitude coordinates, were calculated by the GPS and then transmitted over CAN to the bridge controller, which transmitted them to the Android phone, using bluetooth. Upon executing the RUN-D.B.C Android mobile application, the user was able to select a destination location, by placing a marker on the Google Map fragment. The app parsed the destination's latitude and longitude coordinates and then sent them to the bridge controller. This method allowed the geographic controller to use its pathfinding algorithm (Dikstra's algorithm) to calculate a path to goal, based on the starting location, destination and a series of pre-programmed checkpoints, along the path.
Geographic Controller Schematic
GPS Module
As stated before, we used an Adafruit MTK3339 Ultimate GPS module. The GPS, along with the compass, was responsible for calculating bearing angle and distance from destination checkpoints. 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: 9600 bps at first and then again at 57600 bps. This was because the Ultimate GPS module could only receive data at 9600 bps upon startup, but its operational baud rate was specified as 57600 bps.
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 was used to parse data from the GPS module, with comma(,) as the delimiter.
The $GPRMC sentence looks like this: $GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68
The below table explains what each of the datum in the GPRMC 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.
Essential GPS Data
Bearing Angle
The bearing angle is the angle between an object (in this case the car) and the nearest checkpoint, relative to true north.
Software Design
<List the code modules that are being called periodically.>
Technical Challenges
<Bullet or Headings of a module>
Bill Of Materials
|
GEOGRAPHIC CONTROLLER | ||||
|---|---|---|---|---|
|
PART NAME |
PART MODEL |
QUANTITY |
COST PER UNIT (USD) | |
|
|
| ||
|
|
| ||
MASTER CONTROLLER
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: The primary function of the master module is to process the geo and sensor data, and send steering and motor commands to the motor module.
- obstacle avoidance
- steer to checkpoint
Technical Challenges
- Quickly switching from reverse to forward "winds up" integral term of PI controller on motor module
- Solved by adding short (1 second) delay after reversing
Bug Tracking
<Problem Summary> <Problem Resolution>
Bill Of Materials
|
MASTER CONTROLLER | ||||
|---|---|---|---|---|
|
PART NAME |
PART MODEL |
QUANTITY |
COST PER UNIT (USD) | |
|
|
|
|
| |
MOTOR CONTROLLER
Hardware Design
The motor board was responsible for both steering and spinning the wheels in order to move the car in a targeted direction.
The front 2 wheels of the car handled the steering portion and it accomplished this with the utilization of the servo.
The servo was included with the RC we purchased and it was interfaced with 3 pins.
These 3 pins consisted of:
1 pin for the power supply, which was powered by the battery that came with the RC car (as opposed to the same supply that other components on our PCB shared)
1 pin for the ground signal
1 pin for the PWM control signal
Speed Control Timing Diagrams
Steering Control Timing Diagrams
Motor Controller Schematic
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.
Bill Of Materials
|
MOTOR CONTROLLER | ||||
|---|---|---|---|---|
|
PART NAME |
PART MODEL |
QUANTITY |
COST PER UNIT (USD) | |
|
|
|
|
| |
SENSOR CONTROLLER
Hardware Design
We gave a lot of through, regarding how and where sensors should be mounted to the car. In order to facilitate adjusting the directions of individual sensors, we incorporated circular grooves in the sensor bases. The hinge of the sensor mount also allowed sensors to be vertically adjusted Together with the sensor mount, this approach gave the sensor's two degrees of freedom.
Sensor Controller Schematic
CAD Design
The picture on the left shows that the hinge of the sensor guard can be adjusted to minimize the amount of interference between sensors.
The picture on the right shows the hinge of the sensor mount, allowing vertically adjustment.
Placement for the Ultrasonic Sensors
We realized that when the sensors were active, the left and right sensor ultrasonic wave output, sometimes interfered with the middle sensor, resulting in incorrect feedback. This occurred despite polling the sensors in separate periodic tasks. We discovered that, mounting the middle sensor on a higher surface than the left and right sensors decreased the interference substantially. Furthermore, by attaching two guard pieces on the left/right sensors (acting as shields), we further decreased the interference between sensors. We rigorously tested the integrity of sensor feedback with the guards in different positions, to ensure that they didn't introduce interference of their own (in certain positions).
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 toggled the RX pin, to turn off sensor ranging and only allow wave output when we needed it. The periodic callback function was also written in a way that staggered sensor triggering and reading, to allow sufficient time to process the ADC feedback.
Power Deficiency
At first, when the sensors were tested individually (as well as together on early iterations of the car), they performed to specifications. However, when other subsystems were integrated into the car, the sensor feedback fluctuated wildly. After many hours of troubleshooting, we realized that our 1A power supply was not enough to supply sufficient power to all systems on the car. We addressed the problem by using a power supply with a 3.5A output.
Unstable HR-04 Readings
At first, we used two HC-SR04 modules, as our left and right sensors. However when we tested them during obstacle avoidance we realized that their range was too narrow to reliably detect obstacles. As a result we switched to more expensive, but reliable Maxbotix EZ line of sensors.
ADC Supply Voltage
The middle sensor's also fluctuated wildly at times. After hours of testing we realized that our 5V power supply was distorting its feedback signal, due to the SJOne's ADC peripheral being powered by 3.3V. Applying a 3V power signal to the middle sensor corrected the issue.
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.
Decreasing the queue size and using the median value instead of the average value solved the issue.
Bill Of Materials
|
SENSOR CONTROLLER | ||||
|---|---|---|---|---|
|
PART NAME |
PART MODEL |
QUANTITY |
COST PER UNIT (USD) | |
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
|
|
| ||
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
- How well is Software & Hardware Design described?
- How well can this report be used to reproduce this project?
- Code Quality
- Overall Report Quality:
- Software Block Diagrams
- Hardware Block Diagrams
- Schematic Quality
- Quality of technical challenges and solutions adopted.
