Difference between revisions of "F16: Titans"

Parts List & Cost

DBC File Implementation

• The following is the DBC file of the project.

VERSION ""
NS_:
 NS_DESC_
 CM_
 BA_DEF_
 BA_
 VAL_
 CAT_DEF_
 CAT_
 FILTER
 BA_DEF_DEF_
 EV_DATA_
 ENVVAR_DATA_
 SGTYPE_
 SGTYPE_VAL_
 BA_DEF_SGTYPE_
 BA_SGTYPE_
 SIG_TYPE_REF_
 VAL_TABLE_
 SIG_GROUP_
 SIG_VALTYPE_
 SIGTYPE_VALTYPE_
 BO_TX_BU_
 BA_DEF_REL_
 BA_REL_
 BA_DEF_DEF_REL_
 BU_SG_REL_
 BU_EV_REL_
 BU_BO_REL_
 SG_MUL_VAL_
BS_:

BU_: DBG MASTER GPS MOTOR SENSOR APP

BO_ 1 APP_START_STOP: 1 APP
 SG_ APP_START_STOP_cmd : 0|8@1+ (1,0) [0|0] "COMMAND" MASTER

BO_ 16 SENSOR_DATA: 3 SENSOR 
 SG_ SENSOR_left_sensor : 0|8@1+ (1,0) [0|0] "Inches" MASTER,APP 
 SG_ SENSOR_middle_sensor : 8|8@1+ (1,0) [0|0] "Inches" MASTER,APP 
 SG_ SENSOR_right_sensor : 16|8@1+ (1,0) [0|0] "Inches" MASTER,APP

BO_ 32 MASTER_HB: 2 MASTER 
 SG_ MASTER_SPEED_cmd : 0|8@1+ (1,0) [0|0] "" SENSOR,MOTOR,GPS,APP
 SG_ MASTER_STEER_cmd : 8|8@1+ (1,0) [0|0] "" SENSOR,MOTOR,GPS,APP

BO_ 65 GPS_Data: 8 GPS
 SG_ GPS_READOUT_valid_bit : 0|1@1+ (1,0) [0|1] "" MASTER,MOTOR,APP
 SG_ GPS_READOUT_read_counter : 1|6@1+ (1,0) [0|60] "" MASTER,MOTOR,APP
 SG_ GPS_READOUT_latitude : 7|28@1+ (0.000001,-90.000000) [-90|90] "" MASTER,MOTOR,APP
 SG_ GPS_READOUT_longitude : 35|29@1+ (0.000001,-180.000000) [-180|180] "" MASTER,MOTOR,APP

BO_ 66 COMPASS_Data: 2 GPS
 SG_ COMPASS_Heading : 0|9@1+ (1,0) [0|0] "Degree" MASTER,APP,MOTOR 

BO_ 67 GEO_Header: 3 GPS
 SG_ GPS_ANGLE_degree : 0|12@1+ (0.1,-180) [-180.0|180.0] "Degree" MASTER,MOTOR,APP
 SG_ GPS_DISTANCE_meter : 12|12@1+ (0.1,0) [0.0|400.0] "Meters" MASTER,MOTOR,APP

BO_ 48 MOTOR_STATUS: 3 MOTOR
 SG_ MOTOR_STATUS_speed_mph : 0|16@1+ (0.001,0) [0|0] "mph" MASTER,APP,MOTOR

CM_ BU_ MASTER "The master controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BU_ APP "The communication bridge controller of car";
CM_ BU_ GPS "GPS and compass controller of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";
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_ 32 100;
BA_ "GenMsgCycleTime" BO_ 16 100;
BA_ "GenMsgCycleTime" BO_ 48 100;
BA_ "GenMsgCycleTime" BO_ 65 100;
BA_ "GenMsgCycleTime" BO_ 66 100;

Sensor Controller

Design & Implementation

The main purpose of the sensor controller is Obstacle avoidance and one of the straight forward way to achieve the goal is to use an Ultrasonic sensor.

Sensor controller being the “eye” of the project, lot of thoughts were put into deciding the right sensor to serve the purpose of obstacle avoidance. Considering the factors of reliability and cost, Maxbotix EZ0 ultrasonic sensor is chosen to be left and right sensors. EZ ‘0’ model is selected because it has the widest beam coverage of all the Maxbotix EZ series sensor models. Devantech SF05 ultrasonic sensor is selected for the middle sensor. A different model is used for middle sensor because of its different frequency, which avoids interference between sensors.

The sensors are mounted and tested at different angles so that the front three sensors cover a wide area, without leaving any dead or uncovered region.

Hardware Design

The sensors are interfaced using Port 2 GPIO pins of the microcontroller. The sensors require 5V power supply, which was provided from the main board’s supply. The trigger input to the sensors and the PWM output are interfaced to the GPIO pins as shown below in table. The pins for each sensor are chosen in such a way that it would not tangle each other while physically connecting them on the main board. CAN 1 of the SJOne board is connected to the CAN bus of the car which is also shown in the table below.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Motor & I/O Controller

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Geographical Controller

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

GPS Module: Readytosky Ublox NEO-M8N GPS Module

This GPS module uses UART serial communication interface. The refresh rate ranges from 1Hz up to 18Hz with a default baud rate of 9600bps. To achieve the desired refresh rate of 10Hz for our design, the baud rate had to be increased to 115200bps to accommodate for the demanded bandwidth from 10Hz refresh rate.

Specifications & Documentation: www.u-blox.com

GPS Connector Definition:

• GND,
• TX,data output
• RX,data intput
• VCC,2.7V-3.6V

Why choose u-blox GPS module?

There are several reasons to select this GPS module oppose to other types such as Sparkfun's popular Venus GPS. First, is the price. The u-blox GPS module can be purchased off amazon for about $35 with integrated antenna compared to the Venus for $50 with an additional ~$10-15 for the required external antenna. This brings up the next point and that has to do with the external antenna. Since the antenna's coaxial cable can range between 10 to 15 feet, it becomes a hassle trying to tuck it away on once GPS module is mounted on the RC car. Second point is the accuracy. The u-blox's data sheet claims have an accuracy of about 2 meters (Amazon.com seller claims 0.6 to 0.9 meter) compared to 2.5 meters on the Venus. Although these different GPS modules uses their own software to configure its settings, they all are identically configurable. This means it is a no-brainer to go for the u-blox GPS module.

Setting up u-blox GPS module:

To be able to use u-blox center software to configure the GPS module, either u-blox's developer kit can be purchased or a cheaper alternative choice would be to purchase a FTDI USB to Serial adapter module for about $5 from any convenient online retailer. The u-blox software can be downloaded free from u-blox's website. Once connection is establish between the GPS module and computer, the software provides great number of configurations to change and also a wide GPS map tools to play with. Despite all the fun features the software provides, there are a few important settings that needed to be changed to fit our design.

On default, the refresh rate is set at 1000ms, or 1Hz. This had to be changed to 100ms to be able to get a refresh rate of 10Hz. Next, for the best accuracy possible from this GPS, Navigation Mode needs to be changed to "Pedestrian". This settings ensure best accuracy below speed of 30 meters/second which our RC car is well under. Lastly, since we are only interested in GPRMC messages from our GPS module, u-blox software provided option to turn off all messages except for GPRMC. This helps tremendously when trying to capture reliable messages.

The Readytosky GPS module has a soldered-on little super capacitor that charges up once power is provided and then acts as a battery once power is removed. Although this super capacitor helps by providing power to the memory to keep GSP configuration settings saved as well as provide a warm or hot start (faster to acquire accurate GPS data), it was only able to power for a few hours after power is removed. Although the datasheet says the memory is flash, it kept resetting back to default once battery power is gone. This meant configuration settings had to be redone often. To remedy this problem, the super capacitor had to be removed and in its place, a 3.3V coin battery soldered on.

Interfacing with SJ-One Board:

Interfacing this GPS module to the SJ-One board was straight forward. Since the communication type is UART, TX from GPS is tied to RXD2 pin on SJ-One and RX from GPS is tied to TXD2 pin utilizing UART2 port. Since the refresh rate was configured to 10hz, the default 9600 baud rate was not sufficient enough. Baud rate on both GPS module and SJ-One board both had to be changed to 115200 baud rate. Although baud could have lower and worked just fine, 115200 posed no issue so it was ideally better to get the message sooner and have a longer time in between the next message to avoid cascading messages in the UART read buffer.

**See Hardware Design for wire diagram.**

Razor IMU - 9 Degrees of Freedom

The 9DOF Razor IMU incorporates three sensors - an ITG-3200 (MEMS triple-axis gyro), ADXL345 (triple-axis accelerometer), and HMC5883L (triple-axis magnetometer) - to output nine degrees of inertial measurement. The outputs of all sensors are processed by an on-board ATmega328 and output over a serial interface.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Testing & Technical Challenges

GPS Module

Communication Bridge Controller

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Here is the hardware block diagram of Communication Bridge Controller.

Hardware block diagram for Communication Bridge Module

Here is the hardware block diagram of Communication Bridge Controller. Here is the hardware block diagram of Communication Bridge Controller. Here is the hardware block diagram of Communication Bridge Controller.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Master Controller

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

My Issue #1

Discuss the issue and resolution.

Conclusion

Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Project Video

Upload a video of your project and post the link here.

Project Source Code

• GitLab Source Code Link

References

Acknowledgement

Any acknowledgement that you may wish to provide can be included here.

References Used

List any references used in project.

Appendix

You can list the references you used.