Difference between revisions of "S22: Firebolt"
Proj user9 (talk | contribs) (→Geographical And Bridge Controller) |
Proj user9 (talk | contribs) (→Hardware Design) |
||
| Line 718: | Line 718: | ||
=== Hardware Design === | === Hardware Design === | ||
The Driver Node has one peripheral connected to it and that is the LCD screen. | The Driver Node has one peripheral connected to it and that is the LCD screen. | ||
| − | |||
| − | |||
| − | |||
=== Software Design === | === Software Design === | ||
Revision as of 15:14, 20 March 2022
Contents
FireBolt RC Car
Abstract
The Firebolt project is a path finding and obstacle avoiding RC car. The RC Car 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
Objectives
- 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
Introduction
The Firebolt RC car uses 4 SJ2 boards as nodes on the CAN bus
- Driver and LCD
- GEO and path finding
- Sensors and bridge app
- Motor
Team Members & Responsibilities
- Geographical Controller
- Master Controller
- Android Application Developer
- Communication Bridge Controller
- Master Controller
- Sensors Controller
- Hardware Integration
- PCB Designing
Schedule
| Week# | Start Date | End Date | Task | Actual Completion | Status |
|---|---|---|---|---|---|
| 1
02/28 to 03/06 Start of Phase 1 |
|
|
|
|
|
| 2
03/07 to 03/13 |
|
|
|
|
|
| 3
03/14 to 03/20 |
|
|
|
|
|
| 4
03/21 to 03/27 |
|
|
|
|
|
| 5
03/28 to 04/03 End of Phase 1 |
|
|
|
|
|
| 6
04/04 to 04/10 Start of Phase 2 |
|
|
|
|
|
| 7
04/11 to 04/17 |
|
|
|
|
|
| 8
04/18 to 04/24 End of Phase 2 |
|
|
|
|
|
| 9
04/25 to 05/01 Start of Phase 3 |
|
|
|
|
|
| 10
05/02 to 05/10 |
|
|
|
|
|
| 11
05/11 to 05/15 End of Phase 3 |
|
|
|
|
|
| 1
02/28 to 03/06 Start of Phase 1 |
|
|
|
|
|
Parts List & Cost
| Item# | Part Desciption | Vendor | Qty | Cost |
|---|---|---|---|---|
| 1 | RC Car | Traxxas [1] | 1 | $250.00 |
| 2 | CAN Transceivers MCP2551-I/P | Comimark [2] | 5 | $7.00 |
| 3 | Ultrasonic Sensors | Max Botix[3] | 5 | $150.00 |
| 4 | GPS and Antenna | Adafruit[4] | 1 | $60.00 |
| 5 | HC05 bluetooth RF Transreceiver | HiLetgo[5] | 1 | $12.59 |
| 6 | Triple-axis Accelerometer | Adafruit[6] | 1 | $21.40 |
| 7 | Traxxas RPM Sensor | Traxxas[7] | 1 | $12 |
| 8 | Discrete Electronic Components | Generic[8] | 1 | $28.75 |
| 9 | Buck-Boost Voltage Regulator | Generic[9] | 1 | $11.99 |
| 10 | Traxxas Telemetry Trigger magnet & holder | Traxxas[10] | 1 | $6.35 |
| 11 | Acrylic Sheet | Tap Plastic | 1 | $12 |
| 12 | Battery | Amazon[11] | 1 | $26.99 |
| 13 | Traxxas Battery and Charger | Amazon[12] | 1 | $55.94 |
Printed Circuit Board
PCB Schematic
PCB Design
CAN Communication
We use controller area network to broadcast data between the 4 nodes. All nodes are connected to each other through a physically conventional two wire bus. The wires are a twisted pair with 120 Ω resistors at each ends of the bus. 1s and 0s are transmitted as CAN High(0V difference) and Can Low(2v difference). A CAN frame has the following contents:
- Data Length Code (4bits)
- Remote Transmission Request.
- ID extend bit.
- Message ID (11 bit or 29 bit)
- Data bytes( depends on DLC)
- CRC
Arbitration: No two nodes will transmit at the same time because if arbitration. A lower Message-ID has a Higher priority on the CAN bus since 0 is the dominant bit.
Bit Stuffing: CAN bus stuffs extra bits when a long chain of multiple 1's or 0's occur to improve CAN integrity.
| Sr. No | Message ID | Message function | Receivers |
|---|---|---|---|
| Driver Controller | |||
| 1 | 300 | speed and steering direction for the motor. | Motor |
| 2 | 310 | Destination reached | Sensor |
| Sensor Controller | |||
| 1 | 200 | Sensor sonars from front, back, left ,right sensor | Driver |
| Motor Controller | |||
| 8 | 700 | motor speed, motor direction | Driver |
| Geo and Bridge Controller | |||
| 1 | 400 | Bearing, Heading and Distance | Driver |
| Debug messages | |||
| 1 | 851 | Driver Debug | SENSOR,MOTOR,GEO_AND_BRIDGE |
| 1 | 811 | Motor Debug | SENSOR,MOTOR,GEO_AND_BRIDGE |
| 1 | 801 | Sensor Debug | SENSOR,MOTOR,GEO_AND_BRIDGE |
Hardware Design
DBC File
Sensor ECU
Hardware Design
Sensor Controller Schematic
Board Pin Connections
Sensors are interfaced with combination of GPIO, ADC Pins on SJTWo board. Below is the descriptive pin layout:
Software Design
The sensor node mainly does two activity viz. 1) Read sensor values, 2) Transmit obstacle distance over CAN bus. Both of these activities happen in a 20Hz periodic callback.
1. Read Sensor Values
2. Transmit obstacle distance over CAN bus:
Technical Challenges
Neighboring Sensor Interference:
Frequent noisy measurements:
Motor ECU
Hardware Design
The motor node(SJ-2) interfaces primarily interfaces with:
All these three components have 3 pins each. The functionalities of these pins are mentioned in the table below.
Software Design
Technical Challenges
Geographical And Bridge Controller
Hardware Design
Software Design
The GEO controller is divided into 5 parts.
Technical Challenges
Driver Node
https://gitlab.com/nimit.patel/roadster/-/tree/Main/Driver_Node
Hardware Design
The Driver Node has one peripheral connected to it and that is the LCD screen.
Software Design
The driver node controls the logic of steering the car in the right direction based on the data received from the Sensor and Geo Nodes. The following flowchart describes that process.
- Driver Node Flow Chart
In case there are obstacles in the path where the car wants to move to, the following obstacle avoid logic would kick in.
- Driver Node Obstacle Avoidance Logic
The work in the Driver Node is done using two different periodic tasks. Here is a description of those periodic tasks and what they do.
- 1 Hz Loop:
- Transmit debug messages over the CAN bus
- Transmit messages on the LCD
- Transmit destination reached flag over the CAN Bus
- 20 Hz Loop:
- Receive Sensor Data
- Receive Geo Data
- Process and Transmit Data(Motor Direction and Speed) to Motor Node
- LCD Interface
The LCD interface on the Driver is used to print some important information about the car. This is what it prints.
- Car Speed
- Distance from the Destination
- Car State (Car Stopped from the App, Car Moving, Destination Reached)
Technical Challenges
- The Driver Node did not have much hardware interfaced on it apart from LCD. So from the hardware side there were no technical challenges. On the software front as well there were not many challenges as unit tests helped debug most of the issues then and there.
- We initially used GLCD which was configured via GPIOs and it was working perfectly. Hence we created our PCB as per this LCD. But, while testing our car with various speeds and PID logic, it got toppled and damaged the LCD. So, we had to change to SJ Valley LCD, which was configured via the UART interface, at the last moment. So, we used the same location on the PCB to place the LCD and soldered wires below PCB. Hence, this correction was not visible on our end product.
Mobile Application
Gitlab We created a lightweight mobile app to navigate our car, It can communicate with the car via Bluetooth and is capable of sending Destination co-ordinates along with checkpoints. Receive and Update live location on Google Maps, send Start, Stop and Clear commands, Receive and Display Debug Data.
User Interface
The app has minimal buttons on the same screen as Google Maps View to confirm the cars current state and location before sending the commands.
connect_Btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
listPairedDevices(v);
}
});
clear.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
try {
if(!state) {
mConnectedThread.write("--,\n");
mMap.clear();
checkpoints.clear();
sending_status.setText("Waiting");
}
else{
Toast.makeText(getApplicationContext(),"Stop the car First",Toast.LENGTH_SHORT).show();
}
}
catch (Exception e)
{
Toast.makeText(getApplicationContext(),"Connect to Roadster First",Toast.LENGTH_SHORT).show();
}
}
});
stop.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
try {
mConnectedThread.write("!!,\n");
state=false;
move_camera=false;
car_status.setText(" stopped");
}
catch (Exception e)
{
Toast.makeText(getApplicationContext(),"Connect to Roadster First",Toast.LENGTH_SHORT).show();
}
}
});
start.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
try {
mConnectedThread.write("##,\n");
state=true;
move_camera=true;
car_status.setText(" started");
}
catch (Exception e)
{
Toast.makeText(getApplicationContext(),"Connect to Roadster First",Toast.LENGTH_SHORT).show();
}
}
});
send_cpts.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
try {
sending_status.setText("....");
for(int i=0;i<checkpoints.size();i++) {
String cpt="GPS,"+checkpoints.get(i).latitude+","+checkpoints.get(i).longitude+"\n";
mConnectedThread.write(cpt);
}
sending_status.setText("Sent");
}
catch (Exception e)
{
Toast.makeText(getApplicationContext(),"Connect to Roadster First",Toast.LENGTH_SHORT).show();
}
}
});
Software Design
This app has mainly two activities, The main activity and maps activity.
Maps Activity
Bluetooth/WIFI
Technical Challenges
Conclusion
Project Video
Project Source Code
Advise for Future Students
Acknowledgement
References
http://socialledge.com/sjsu/index.php/Industrial_Application_using_CAN_Bus
