Embedded Systems Learning Academy - User contributions [en]

F16: Autonomous Nautical System

2016-12-22T03:11:17Z

146 user3: /* Software Design */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

<syntaxhighlight lang="c++" line>

class navigation_task : public scheduler_task
{
public:
navigation_task(uint8_t priority); ///< Constructor
datalog dl, dl2;

bool run(void *p)
{
xSemaphoreGive(xSemaphoreGPS);
xQueueReceive(printtoSDcard, &dl, 1000);
xSemaphoreGive(xSemaphoreTemp);
xQueueReceive(printtoSDcard, &dl2, 1000);
dl.temp = dl2.temp;
string s= "";
s += dl.time +','+dl.latitude +','+ dl.dirNS + ',' + dl.longitude + ',' + dl.dirEW + ',' + dl.temp + '\n';
char s2 [35] = {0};
for(int temp = 0; temp < 35 || temp < s.length(); temp++)
s2[temp] = s.at(temp);
Storage::append("1:log.txt", &s2 , 35, 0);
return true;
}
bool init()
{
return true;
}
private:

};

</syntaxhighlight>

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

=== PWM and Compass ===
1. Initialize UART3

2. Set up PWM port and refresh rate

3. Send byte containing 0x13 to Compass

4. Read both bytes in receiving holding register

5. Calculate the duty cycle percent

6. Set PWM duty cycle

=== Analog/Digital Converter and SPI ===

{|
|[[File:Tempreadings.jpg | thumb|400px|left| Fig. 2 Output for the temperature sensor]]
|1. Initialize SPI

2. CS the device

3. Send 0x01 0x80 0x00 as byte transfers

4. Run ThermometerRead() with retrieved value
|-
|[[File:SPI-ADconvert.jpg | thumb|400px|left| Fig. 3 Schematic for A/D converter]]
|}

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]
[[File:Servogif-2.gif |thumb|400px|center| Fig. 9 Servo movement is proportional to the compass direction]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point for treating as a unit under test. Before, during, and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long the FIFO runs the list of running out of space for storing
items so an interrupt is used for sensing when data populates the queue.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction to Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
N/A

F16: Autonomous Nautical System

2016-12-22T02:13:17Z

146 user3: /* Analog/Digital Converter and SPI */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

=== PWM and Compass ===
1. Initialize UART3

2. Set up PWM port and refresh rate

3. Send byte containing 0x13 to Compass

4. Read both bytes in receiving holding register

5. Calculate the duty cycle percent

6. Set PWM duty cycle

=== Analog/Digital Converter and SPI ===

{|
|[[File:Tempreadings.jpg | thumb|400px|left| Fig. 2 Output for the temperature sensor]]
|1. Initialize SPI

2. CS the device

3. Send 0x01 0x80 0x00 as byte transfers

4. Run ThermometerRead() with retrieved value
|-
|[[File:SPI-ADconvert.jpg | thumb|400px|left| Fig. 3 Schematic for A/D converter]]
|}

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]
[[File:Servogif-2.gif |thumb|400px|center| Fig. 9 Servo movement is proportional to the compass direction]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point for treating as a unit under test. Before, during, and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long the FIFO runs the list of running out of space for storing
items so an interrupt is used for sensing when data populates the queue.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction to Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
N/A

F16: Autonomous Nautical System

2016-12-22T00:42:53Z

146 user3: /* Analog/Digital Converter and SPI */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

=== PWM and Compass ===
1. Initialize UART3

2. Set up PWM port and refresh rate

3. Send byte containing 0x13 to Compass

4. Read both bytes in receiving holding register

5. Calculate the duty cycle percent

6. Set PWM duty cycle

=== Analog/Digital Converter and SPI ===
1. Initialize SPI

2. CS the device

3. Send 0x01 0x80 0x00 as byte transfers

4. Run ThermometerRead() with retrieved value

[[File:Tempreadings.jpg | thumb|400px|left| Fig. 2 Output for the temperature sensor]]]
[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]
[[File:Servogif-2.gif |thumb|400px|center| Fig. 9 Servo movement is proportional to the compass direction]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point for treating as a unit under test. Before, during, and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long the FIFO runs the list of running out of space for storing
items so an interrupt is used for sensing when data populates the queue.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction to Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
N/A

F16: Autonomous Nautical System

2016-12-22T00:42:27Z

146 user3: /* Analog/Digital Converter and SPI */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

=== PWM and Compass ===
1. Initialize UART3

2. Set up PWM port and refresh rate

3. Send byte containing 0x13 to Compass

4. Read both bytes in receiving holding register

5. Calculate the duty cycle percent

6. Set PWM duty cycle

=== Analog/Digital Converter and SPI ===
1. Initialize SPI

2. CS the device

3. Send 0x01 0x80 0x00 as byte transfers

4. Run ThermometerRead() with retrieved value

[[File:Tempreadings.jpg | thumb|400px|center| Fig. 2 Output for the temperature sensor]]]
[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]
[[File:Servogif-2.gif |thumb|400px|center| Fig. 9 Servo movement is proportional to the compass direction]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point for treating as a unit under test. Before, during, and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long the FIFO runs the list of running out of space for storing
items so an interrupt is used for sensing when data populates the queue.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction to Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
N/A

F16: Autonomous Nautical System

2016-12-22T00:39:35Z

146 user3: /* GPS Issue #3 */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

=== PWM and Compass ===
1. Initialize UART3

2. Set up PWM port and refresh rate

3. Send byte containing 0x13 to Compass

4. Read both bytes in receiving holding register

5. Calculate the duty cycle percent

6. Set PWM duty cycle

=== Analog/Digital Converter and SPI ===
1. Initialize SPI

2. CS the device

3. Send 0x01 0x80 0x00 as byte transfers

4. Run ThermometerRead() with retrieved value

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]
[[File:Servogif-2.gif |thumb|400px|center| Fig. 9 Servo movement is proportional to the compass direction]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point for treating as a unit under test. Before, during, and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long the FIFO runs the list of running out of space for storing
items so an interrupt is used for sensing when data populates the queue.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction to Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
N/A

F16: Autonomous Nautical System

2016-12-21T23:54:10Z

146 user3: /* Acknowledgement */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

=== PWM and Compass ===
1. Initialize UART3

2. Set up PWM port and refresh rate

3. Send byte containing 0x13 to Compass

4. Read both bytes in receiving holding register

5. Calculate the duty cycle percent

6. Set PWM duty cycle

=== Analog/Digital Converter and SPI ===
1. Initialize SPI

2. CS the device

3. Send 0x01 0x80 0x00 as byte transfers

4. Run ThermometerRead() with retrieved value

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]
[[File:Servogif-2.gif |thumb|400px|center| Fig. 9 Servo movement is proportional to the compass direction]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point for treating as a unit under test. Before, during, and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction to Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
N/A

F16: Autonomous Nautical System

2016-12-21T23:52:50Z

146 user3: /* Testing & Technical Challenges */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

=== PWM and Compass ===
1. Initialize UART3

2. Set up PWM port and refresh rate

3. Send byte containing 0x13 to Compass

4. Read both bytes in receiving holding register

5. Calculate the duty cycle percent

6. Set PWM duty cycle

=== Analog/Digital Converter and SPI ===
1. Initialize SPI

2. CS the device

3. Send 0x01 0x80 0x00 as byte transfers

4. Run ThermometerRead() with retrieved value

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]
[[File:Servogif-2.gif |thumb|400px|center| Fig. 9 Servo movement is proportional to the compass direction]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point for treating as a unit under test. Before, during, and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
N/A

F16: Autonomous Nautical System

2016-12-21T15:04:58Z

146 user3: /* Implementation */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

=== PWM and Compass ===
1. Initialize UART3

2. Set up PWM port and refresh rate

3. Send byte containing 0x13 to Compass

4. Read both bytes in receiving holding register

5. Calculate the duty cycle percent

6. Set PWM duty cycle

=== Analog/Digital Converter and SPI ===
1. Initialize SPI

2. CS the device

3. Send 0x01 0x80 0x00 as byte transfers

4. Run ThermometerRead() with retrieved value

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]
[[File:Servogif-2.gif |thumb|400px|center| Fig. 9 Servo movement is proportional to the compass direction]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T14:43:24Z

146 user3: /* Implementation */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

=== PWM and Compass ===
1. Initialize UART3

2. Set up PWM port and refresh rate

3. Send byte containing 0x13 to Compass

4. Read both bytes in receiving holding register

5. Calculate the duty cycle percent

6. Set PWM duty cycle

=== Analog/Digital Converter and SPI ===

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]
[[File:Servogif-2.gif |thumb|400px|center| Fig. 9 Servo movement is proportional to the compass direction]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T14:05:42Z

146 user3: /* References Used */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

[https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf MCP3004 A/D converter Datasheet]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T13:57:29Z

146 user3: /* Hardware Interface */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

[[File:Communication_diagram.JPG | 350px | thumb | center | Fig 8. Peripheral Communication Layout]]

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T13:35:51Z

146 user3: /* Testing & Technical Challenges */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

[[File:Gps_map.jpg | 300px |thumb|center| Fig 6. Expected longitude and latitude for testing]]

[[File:Gpscapture.JPG | 300px |thumb|center| Fig 7. Actual longitude and latitude coordinates at testing site]]

Solution:
Following extensive research there is the possibility of configuring known reference geographical locations with the X,Y,Z and (longitude,latitude) coordinate that the GPS module is preloaded with for comparing to. However this did not help as much as making sure we used the WAAS feature which allows the GPS to get feedback from federal ground references for calculating how off satellites are in their pinning a location.

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T13:06:38Z

146 user3: /* Schedule */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

Solution:

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T13:05:26Z

146 user3: /* Schedule */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued
by a remote control for steering
and speed throttling. Decode
these signals over time to identify
which values produce what kind of
effect to the driving system.
| Completed
Using a logic analyzer did not work
the way we planned. An oscilloscope
was used but only to prove that this
was not necessary since the motor and
servo reacts to PWM as any other motor
or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing
the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together
using navigation task.
| Completed
Debug the steering and motor control
commands issued by the state of the
navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed
information and use all task outputs
in the navigation task.
| In Progress
Buggy and needs to check for invalid
information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| In Progress
Clean up exceptions in the land demo program
|-}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

Solution:

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T13:02:59Z

146 user3: /* Hardware Interface */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued by a remote
control for steering and speed throttling. Decode
these signals over time to identify which values produce
what kind of effect to the driving system.
| Completed
Using a logic analyzer did not work the way we planned
An oscilloscope was used but only to prove that this
was not necessary since the motor and servo reacts to
PWM as any other motor or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together using navigation task.
| Completed
Debug the steering and motor control commands issued
by the state of the navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed information and use
all task outputs in the navigation task
| Completed
Buggy and needs to check for invalid information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| Completed
Clean up exceptions in the land demo program
|-}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===
Communicating between the compass and GPS module support UART however would not be able to use the same TX and RX since there is no protection from connecting outputs from these devices. This form of communication is asynchronous which means the unidirectional data lines can be flooded with data to a particular device and does not require addressing to occur through those lines.

==== GPS ====
Extra considerations had to be noted for software driver which handles data to the microcontroller from the sensor. As the 16-byte receiving FIFO
is flooded with bytes to be read an interrupt is needed to clear the FIFO of it's items and store them in a safe place. This is necessary in order to completely read a message which on average is 70 characters or bytes long.

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

Solution:

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T12:52:21Z

146 user3: /* Project Video */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued by a remote
control for steering and speed throttling. Decode
these signals over time to identify which values produce
what kind of effect to the driving system.
| Completed
Using a logic analyzer did not work the way we planned
An oscilloscope was used but only to prove that this
was not necessary since the motor and servo reacts to
PWM as any other motor or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together using navigation task.
| Completed
Debug the steering and motor control commands issued
by the state of the navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed information and use
all task outputs in the navigation task
| Completed
Buggy and needs to check for invalid information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| Completed
Clean up exceptions in the land demo program
|-}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===

=== PWM ===

=== ADC ===

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

Solution:

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[[https://www.youtube.com/watch?v=VUk6K8lpmnQ Video Proof of Concept]]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T12:44:08Z

146 user3: /* Conclusion */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued by a remote
control for steering and speed throttling. Decode
these signals over time to identify which values produce
what kind of effect to the driving system.
| Completed
Using a logic analyzer did not work the way we planned
An oscilloscope was used but only to prove that this
was not necessary since the motor and servo reacts to
PWM as any other motor or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together using navigation task.
| Completed
Debug the steering and motor control commands issued
by the state of the navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed information and use
all task outputs in the navigation task
| Completed
Buggy and needs to check for invalid information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| Completed
Clean up exceptions in the land demo program
|-}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===

=== PWM ===

=== ADC ===

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

Solution:

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== Conclusion ==
This project provided several lessons in the values of through unit testing of each of our tasks, and integration testing of all the parts. Complications arose during the formation of our final higher level navigation task which analyzes the readings from our sensors to send commands for the system to reach the same starting GPS location.

From an organizational standpoint if more effort was taken to separate our initialization of our peripherals and our few operations for each sensor the unit testing would be more effective at catching bugs. As we observed in our issues during testing data was invalid which can hinder the pools of data being collected.

=== Project Video ===
[https://www.youtube.com/watch?v=VUk6K8lpmnQ]

=== Project Source Code ===
* [https://github.com/angeeeeelh/cmpe-146-demo-fall2016/ Github Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T12:10:50Z

146 user3: /* Acknowledgement */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued by a remote
control for steering and speed throttling. Decode
these signals over time to identify which values produce
what kind of effect to the driving system.
| Completed
Using a logic analyzer did not work the way we planned
An oscilloscope was used but only to prove that this
was not necessary since the motor and servo reacts to
PWM as any other motor or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together using navigation task.
| Completed
Debug the steering and motor control commands issued
by the state of the navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed information and use
all task outputs in the navigation task
| Completed
Buggy and needs to check for invalid information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| Completed
Clean up exceptions in the land demo program
|-}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===

=== PWM ===

=== ADC ===

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

Solution:

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== 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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
Acknowledgements for code and lab instruction is for Preetpal Kang.

In addition, theory of embedded microcontroller design is for Prof. Haluk Ozmek.

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T12:06:20Z

146 user3: /* Objectives & Introduction */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Peripheral goals include
* Logging to SD card using SPI
* Analog to Digital Converter reading of Temperature sensor
* Reading and controlling GPS using UART
* Reading compass measurements using UART

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control, compass, AD converting, Navigation Algorithm
* Fayek Wahhab
Servo control, compass, power management
* Abraham Carrillo
Motor Control, power management, logging to SD card

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued by a remote
control for steering and speed throttling. Decode
these signals over time to identify which values produce
what kind of effect to the driving system.
| Completed
Using a logic analyzer did not work the way we planned
An oscilloscope was used but only to prove that this
was not necessary since the motor and servo reacts to
PWM as any other motor or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together using navigation task.
| Completed
Debug the steering and motor control commands issued
by the state of the navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed information and use
all task outputs in the navigation task
| Completed
Buggy and needs to check for invalid information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| Completed
Clean up exceptions in the land demo program
|-}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===

=== PWM ===

=== ADC ===

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

Solution:

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== 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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

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

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T11:45:49Z

146 user3: /* Software Design */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control
* Fayek Wahhab
Servo control
* Abraham Carrillo
Motor Control

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued by a remote
control for steering and speed throttling. Decode
these signals over time to identify which values produce
what kind of effect to the driving system.
| Completed
Using a logic analyzer did not work the way we planned
An oscilloscope was used but only to prove that this
was not necessary since the motor and servo reacts to
PWM as any other motor or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together using navigation task.
| Completed
Debug the steering and motor control commands issued
by the state of the navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed information and use
all task outputs in the navigation task
| Completed
Buggy and needs to check for invalid information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| Completed
Clean up exceptions in the land demo program
|-}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===

=== PWM ===

=== ADC ===

== Software Design ==
Building tasks dedicated for controlling each sensor is the first step to our design approach.

* GPS_task
* Compass_task

A few tasks are used to schedule and communicate data between the tasks would be the following edited libraries.

* Terminal Task
* Navigation Algorithm

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

Solution:

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== 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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

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

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T11:38:28Z

146 user3: /* SPI */

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


= Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) =

== Abstract ==
Constructing an autonomous navigation system responsive to GPS and Tilt Compass feedback to form and track trajectories to a given location. Low power, and observant system.

== Objectives & Introduction ==
Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

=== Team Members & Responsibilities ===
* Angel Hernandez-Perez
GPS control
* Fayek Wahhab
Servo control
* Abraham Carrillo
Motor Control

== Schedule ==

Table 1. Schedule
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Tasks
! scope="col"| Actual
|-
! scope="row"| 1
| 10/8
| Decide on boat hull based on the amount of devices
we planned to us.
Purchased motor, servo, and battery accordingly
| Completed
Brushed DC motor powered by Electronic
Speed controller was purchased.
|-
! scope="row"| 2
| 11/4
| Intercept the pwm signals issued by a remote
control for steering and speed throttling. Decode
these signals over time to identify which values produce
what kind of effect to the driving system.
| Completed
Using a logic analyzer did not work the way we planned
An oscilloscope was used but only to prove that this
was not necessary since the motor and servo reacts to
PWM as any other motor or servo.
|-
! scope="row"| 3
| 11/25
| Make separate compass, gps, and pwm tasks
| Completed
These tasks are a simple tasks demoing the functionality
|-
! scope="row"| 4
| 12/02
| Link separate task outputs together using navigation task.
| Completed
Debug the steering and motor control commands issued
by the state of the navigation task state machine.
|-
! scope="row"| 5
| 12/16
| Revise gps task to give only needed information and use
all task outputs in the navigation task
| Completed
Buggy and needs to check for invalid information using checksum
|-
! scope="row"| 6
| 12/20
| Update the wiki page
| Completed
Clean up exceptions in the land demo program
|-}

= Parts List & Cost =

* SJ One Board | $80.00
* Tilt Corrected Compass | $30.00
* GPS | $50.00
* 7.2V 2600mAH Battery (included w/hull)
* 5V 5200mAH Battery | $13.00
* Hull | $155.00
* DC Motor (included w/hull)
* Servo (included w/hull)
* Electronic Speed Controller (included w/hull)

= 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 ==
Considerations for our hardware include power consumption and usefulness in a water scenario.
The root of this project where sensor input is analyzed and output signals are distributed
is the SJ One board. Using the FreeRTOS OS an autonomous system can adjust its velocity
and direction by controlling the motor and servo. GPS and Tilt compass provides the feedback
needed to make adjustments.

[[File:Project_Hardware_Overview_ANSOTAS.jpg|450px|thumb|center]]

== Hardware Interface ==

=== I2C ===
I2C was used to communicate to and from the SJ One board to the tilt adjusted compass. This protocol allows numerous sensors to be connect to a single wire to all devices for transmitting and receiving address and data information. This is possible because of synchronization of a clock signal and a pull-up resistor used in setting up the data/address bus. The disadvantage with this choice is speed since it can only transfer a max of 100KHz.

For our design we use our SJ One board as the master and the compass as the slave device. It is only enabled if it receives it's address from the master. Through out the operation of protocol a slave and master are under constant bidirectional communication. Using a byte or more to communicate what is desired in the form of an slave address, byte address and a quantity for receiving or transferring data. This continuous process follows a state machines for both the slave and master devices. Below Fig 5. describes for example a basic sequence of states that the slave can go through for receiving and transmitting data to a master. If at any point during transmission a data packet is invalid the transmission can abort and require exception handling.

[[File:Best_Case_Scenario_State_Diagrams-_Angel_H.png|500px|thumb|center|Fig 5. I2C Slave State Machine Diagram]]

=== SPI ===
A full duplex communication protocol characterized by the single unidirectional input and output lines between master(s) and slave(s).
Our project utilizes SPI to transmit and receive data for logging on the external SD card and interface with the compass. The plan is to use a form of serial communication for it's speed and ability to use GPIO for enabling the devices' chip select.

=== UART ===

=== PWM ===

=== ADC ===

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

[[File:UpperTierHardwareBase.png|thumb|400px|center| Fig. 3 Top of the base]]
[[File:BottomTierHardwareStack.png|thumb|400px|center| Fig. 4 Bottom of the base]]

= Testing & Technical Challenges =
The test plan includes unit testing, and integration testing. After writing the code for each task we used each method of each task class as the starting point. Before, during and after development any referenced class endured it's own unit testing. For example the classes which control communication protocols were heavily tested to ensure that data was not corrupted during transit. During higher level unit testing erroneous was output but testing had to be done on the classes used. By adding print statements to the data before and after packaging and transferring data. Following the results that tasks worked independently using black box testing the tasks were tested using integration testing. This area remains to this moment an area requiring further tests. In the following subsections, detailed descriptions and solutions faced in this project will be explained.

=== GPS Issue #1 ===
Issue:
GPS data is sent constantly from the GPS module through UART without the need for a command.
Full messages referred to as NMEA sentences are received by the module and read by the
microcontroller. They do not always arrive in their entirety or represent accurate data.

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

=== GPS Issue #2 ===
Issue:
Coordinates in the NMEA sentences are off by more than +/- 5 meters.

Solution:

=== GPS Issue #3 ===
Issue:
NMEA messages that represent the recommended minimum specific are around 67 characters can
overflow the local RX FIFO used with UART. Since the FIFO is 16 bytes long an interrupt is
activated when the receiving buffer is not empty to store enough values to

Solution: To counter act this problem a checksum value is included in the sentence and is
useful for checking the values of he payload checksum value for the specific data in the
message.

== 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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

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

=== References Used ===
[http://cdn.sparkfun.com/datasheets/Sensors/GPS/Venus/638/doc/AN0003_v1.4.19.pdf GPS module DataSheet]

[http://aprs.gids.nl/nmea/ NMEA Decoding]

[http://www.doctormonk.com/2012/05/sparkfun-venus-gps-and-arduino.html GPS Recommended Minimum Specifics Parsing]

[http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf SJ One board MCU Datasheet]

[http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJ One board Introduction]

=== Appendix ===
You can list the references you used.

F16: Autonomous Nautical System

2016-12-21T11:29:27Z

146 user3: /* My Issue #1 */

F16: Autonomous Nautical System

2016-12-21T09:24:19Z

146 user3: /* Testing & Technical Challenges */

F16: Autonomous Nautical System

2016-12-21T04:04:13Z

146 user3: /* Hardware Interface */

F16: Autonomous Nautical System

2016-12-21T03:28:26Z

146 user3: /* Implementation */

F16: Autonomous Nautical System

2016-12-21T03:26:16Z

146 user3: /* Implementation */

F16: Autonomous Nautical System

2016-12-21T02:32:43Z

146 user3: /* = Implementation */

F16: Autonomous Nautical System

2016-12-21T02:31:58Z

146 user3: /* Autonomous Nautical Systems for Ocean Transit and Survey (ANSOTAS) */

F16: Autonomous Nautical System

2016-12-21T02:31:40Z

146 user3: /* Parts List & Cost */

F16: Autonomous Nautical System

2016-12-21T02:30:44Z

146 user3: /* Hardware Interface */

F16: Autonomous Nautical System

2016-12-21T02:29:30Z

146 user3: /* Design & Implementation */

F16: Autonomous Nautical System

2016-12-21T02:26:58Z

146 user3: /* References Used */

F16: Autonomous Nautical System

2016-12-21T02:19:30Z

146 user3: /* Hardware Design */

F16: Autonomous Nautical System

2016-12-21T02:17:01Z

146 user3: /* Team Members & Responsibilities */

F16: Autonomous Nautical System

2016-12-21T02:13:09Z

146 user3: /* Hardware Interface */

F16: Autonomous Nautical System

2016-12-21T01:03:46Z

146 user3: /* Hardware Design */

F16: Autonomous Nautical System

2016-12-21T00:30:21Z

146 user3: /* Schedule */

F16: Autonomous Nautical System

2016-12-21T00:29:33Z

146 user3: /* Schedule */

F16: Autonomous Nautical System

2016-12-21T00:27:51Z

146 user3: /* Schedule */

F16: Autonomous Nautical System

2016-12-20T06:23:14Z

146 user3: /* Parts List & Cost */

F16: Autonomous Nautical System

2016-11-10T21:26:16Z

146 user3: Created page with "=== Grading Criteria === * How well is Software & Hardware Design described? * How well can this report be used to reproduce this project? * Code Quali..."

Realtime OS on Embedded Systems

2016-11-10T21:01:41Z

146 user3: /* Fall 2016 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===
=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* Add Your Group on Here, then follow the link to add more to your template *
* [[F16: Autonomous Secure Delivery]]
* [[F16: Autonomous Nautical System]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

S15: Motion-Controlled RC Car

2015-05-27T03:37:36Z

146 user3: /* Implementation */

== Motion-Controlled RC Car ==

[[File:S15_146_G3_IMG_RCcar.jpg|800px|center]]

== Abstract ==
The Motion-Controlled RC Car will allow inexperienced users to drive a high-performance RC vehicle. This is accomplished with a tilt controller, which is more intuitive than a traditional RC transmitter, and a slip-limiting system that will reduce the potential for crashes.

== Objectives & Introduction ==
High performance RC vehicles can be difficult to control because of their immense power and are typically expensive to repair. The goal of this project is to create both a wireless tilt controller and a traction control system for a high-performance RC car. From an engineering standpoint, the project can be broken into three major objectives.

1. Nordic wireless communication

2. Measurement of front and rear axle speed

3. Pulse-width modulated control of motor and servo

=== Team Members & Responsibilities ===

* Shangming Wang - Mesh Communication, Report writing, testing

* Daniel Khawaja - Wheel speed capture, RC car maintenance, PWM

== Schedule ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Completion Date
|-
! scope="row"| 0
| 4/10
| 4/24
| Obtain Hall sensors
| Not Completed
| ---
|-
! scope="row"| 1
| 4/20
| 4/27
| Find PWM parameters, Test mesh communication
| Completed
| PWM: 4/27 Mesh: 5/4
|-
! scope="row"| 2
| 4/27
| 5/4
| Implement PWM control, Finalize mesh communication, Obtain photo interrupters
| Completed
| PWM: 5/4 Mesh: 5/13 Photo: 5/14
|-
! scope="row"| 3
| 5/4
| 5/11
| Implement motion control, Modify RC for 2wd and mount wheel speed sensors
| Completed
| Motion: 5/13 Modification: 5/15
|-
! scope="row"| 4
| 5/11
| 5/18
| Finish wheel speed capture, Test and polish traction control parameters
| Completed
| Capture: 5/23 T.C.: 5/25

|-
! scope="row"| 5
| 5/18
| 5/25
| Implement extra features
| Not Completed
| ---
|}

== Parts List & Cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="60" align="center"|Total Cost
|-
| align="center"|50||Jumper Wires||align="right"|$3.00
|-
| align="center"|1||Prototype Board||align="right"|$1.00
|-
| align="center"|1||Turnigy 500mAh Battery||align="right"|$40.00
|-
| align="center"|2||Wireless Antenna||align="right"|$6.00
|-
| align="center"|1||Remote Control Car||align="right"|$150.00
|-
| align="center"|2||SJOne Board||align="right"|$160.00
|-
| align="center"|2||Motorola MOC7821 Photo Interrupter||align="right"|$4.00
|-
| ||Total Cost '''||align="right"|$364'''
|-
|}

== Design & Implementation ==

=== Hardware Design ===

[[File:S15_146_G3_IMG_1.png|400px|center]]

A high-level schematic of the electronics involved in this project

Our hardware design began with connecting the Sj-One board with the servo and motor controller controller that were built into the model car.

=== Hardware Interfaces ===
The Transmitting Module used the following interfaces:
* [http://www.socialledge.com/sjsu/index.php?title=Embedded_System_I2C_Tutorial I2C Bus]
** Used for reading the orientation value from accelerometer sensor
*[http://www.socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_SPI SPI Bus]
** Used for transmit commands from Nordic wireless sensor to receiving board

The Receiving Interface used the following interfaces:
*[http://www.socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_SPI SPI Bus]
** Used for receive commands from Nordic wireless sensor from transmitting board
*[http://www.socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_GPIO GPIO]
** Used to read the axle speed from the front and rear
** Used to pass PWM signal to the motor and the servo

=== SJOne ===
[[File:S15_146_G3_IMG_SJOne.png|center]]

Our project used two [http://http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJOne boards], both running FreeRTOS. For our project we used the built-in Nordic Wireless system, Accelerometer, GPIO, and PWM functions.

=== Servo, Motor & Motor Controller ===
[[File:S15_146_g3_pwmInterfacedElectronics.jpg|460px|center]]

The servo used in this project was a Futaba S3004 and the motor, already built into the model car, was a Leopard Hobby 3300Kv brushless motor. The Castle Sidewinder 3 motor controller and the Futaba servo were both controlled using pulse widths ranging from 1 to 2miliseconds. A width of 1.5 miliseconds was a 0% signal, 1 milisecond was -100%, and 2 miliseconds was +100%. The motor controller included a 5v regulated output, so it was used to power all the electronics on the vehicle.

=== Photo Interrupter ===
[[File:S15_146_G3_IMG_photoInt.png|200px|center]]

The photo interrupters we chose were the Motorola MOC7821. These devices contain an infrared LED and an infrared-controlled transistor. When the gap between the LED and the sensor is open the transistor turns on and allows current to flow. When an object passes through the space between the LED and the sensor the transistor turns off and behaves like an open circuit.

=== Software Design ===

'''Transmitting Module'''

The transmitter first reads the accelerometer data in both the x and y directions and encodes them in an integer. That integer is sent to the vehicle using the Nordic Wireless system.

[[File:S15_146_G3_IMG_flowchart_transmit.png|200px|center]]

'''Receiving Module'''

The SJ One board on the vehicle, waiting to receive data, accepts the integer. The vehicle reads the wheel speeds at the front and rear axle. This is done by reading the signal from the photo interrupters many times in a row and incrementing a counter each time the signal transitions between high and low. One counter holds the number of transitions read from the front axle and the other counter holds the number of transitions at the rear axle and the task determines if the vehicle is in a low traction situation based on the two counter values. The car then translates the encoded command using one of two throttle maps, based on the traction situation, and uses that to set motor speed and servo angle.

[[File:S15_146_G3_IMG_flowchart_receive.png|500px|center]]

=== Implementation ===

'''Accelerometer'''

The built-in sensor that reads the tilt direction of the SJ One board.

*Step 1: Initialize accelerometer sensor.

*Step 2: Read X and Y axis from the sensor and get the orientation of the board.

Read X value:
Function X-axis Range
Forward -200 <= x < 200
Left -500 <= x < -200
Right 200 <= x < 500
Hard Left x >= 500
Hard Right x <= -500

Read Y value:
Num Speed Y-axis Range
0 7.5 -150 <= y < 150
1 7.9 150 <= y < 250
2 8.3 250 <= y < 400
3 8.7 400 <= y < 550
4 9.1 550 <= y < 700
5 9.5 700 <= y < 850
6 9.9 y >= 850

*Step 3: Encode the function and speed number as a single integer and pass them to the wireless task.

'''Nordic Wireless''' (nRF24L01).

The Nordic wireless sensor is built-in on SJOne Board. It used to send and receive data from one SJOne to other. For our project, it is used to send an encoded x and y tilt of the control board to the board on the vehicle. The following steps were taken to implement the Nordic wireless system

*Step 1: Configure the wireless node address and wireless channel number in sys_config.h file. (Make sure both boards have the same channel)

*Step 2: Used mesh_set_node_address() function to set both sending and receiving address. In our project, the car address is set to 300.

*Step 3: On the sending side, it used wireless_send(addr, protocol, data, size of data, max_hops) function to send the data from SJOne board.

*Step 4: On the receiving side, it used wireless_get_rx_pkt() function to catch the data coming from the wireless.

'''Photo Interrupters''' (MOC7821).

[[File:S15_146_G3_IMG_motor.png|500px|left]] [[File:S15_146_G3_IMG_servo.png|460px|center]]

The photo interrupters are used to monitor wheel rotation. An interrupter was mounted around a disk attached to the output of each differential. In the photos above the rear wheel speed sensor assembly and the front wheel speed sensor assembly are on the left and right, respectively. Notches were cut into the disks so that as they spun the outputs of the interrupters would rise and fall. The SJ One board monitored these signals using its GPIO inputs and counted the rising edges over a set period of time to determine the speed of the axle. Being a rear-drive vehicle, the rear axle rotates faster than the front in a slip condition, and the program responds by reducing throttle.

== Testing & Technical Challenges ==

=== Issue #1 ===
The first issue that we ran into involved our implementation of the Nordic wireless system. During the early stages of the project, we wrote and tested our features in separate C or C++ programs. Using the provided libraries and functions, we designed transmitting and receiving programs to test the wireless. During testing, the first packet sent without issue, but any following packets took up to 30 seconds to send. This is because the libraries and functions that we were relying on were designed to be used within the structured FreeRTOS environment. Using them without the work that FreeRTOS does in the background causes them to misbehave.

=== Issue #2 ===
The Motorola MOC7821 photo interrupters that we purchased had very little documentation. We found information about the sensor side of the part, but nothing about the LEDs that make up the infrared emitters. Two of the interrupter's LEDs burnt out before we found the correct dropout voltage and amperage. We recommend that future students obtain access to a variable power supply and test the LEDs by slowly increasing voltage from zero until the dropout voltage is found.

=== Issue #3 ===
This issue was never resolved. Our initial design goal was to implement the timer's capture system so that the rising edges of the photo interrupters' signals could be counted without consuming CPU cycles. The initialization process seemed straightforward but any time we attempted to modify the lower 4 bits of the Counter Control Register it caused an error that triggered a reboot of the system. After many hours of research and guessing no solution was found so we made our own function that, at the price of many CPU cycles, used the GPIO pins to accomplish the same goal.

Any project of this type will encounter roadblocks such as these. These issues, as well as many smaller bugs, were discovered and resolved using frequent testing. Each task was broken down into as small of a block as we could devise a test for. For example, the photo interrupters were tested in four stages. First we tested the sensor side using an infrared television remote. Once we knew the sensor was working we tested the LEDs using an infrared sensitive camera. The whole package was then tested on a bread board, and finally tested again once installed on the model car.

This multi-tiered testing approach was also applied to our software design process. Testing was an integral part of our design and frequent testing helped us to catch bugs sooner and solve them faster by shrinking the amount of code that could be contributing to the problem.

== Conclusion ==

Though this project was ultimately successful, it was a struggle. Poor planning coupled with an injury from a car accident and an untrustworthy online retailer all pushed the timeline for the project. We were severely behind schedule and were able to successfully complete the project by abandoning the "capture" peripheral and placing the load on the CPU by using the GPIO pins. This project taught a lesson in proper scheduling and planning.

However, that was not the only lesson. In our implementation we were forced to execute, in a best case situation, over 500 lines of code in between each command between the transmitter and the receiver. The delay that the extra code caused in the controlling of the vehicle was barely noticeable, and helped us to see just how blazingly fast modern micro controllers actually are. The thought of a micro controller being slower and "less capable" than a computer is, in most cases, incorrect.

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

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]

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

=== References Used ===
http://www.nxp.com/documents/user_manual/UM10360.pdf

http://www.socialledge.com/sjsu/images/d/de/2012SJOneBoardSchematic.pdf

http://www.datasheetspdf.com/PDF/MOC7821/613725/1

http://www.socialledge.com/sjsu/index.php?title=PWM_Motor_Controller_Interface

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

http://www.socialledge.com/sjsu/index.php?title=Low_Powered_Mesh_Network_stack

S15: Motion-Controlled RC Car

2015-05-27T03:36:32Z

146 user3: /* Hardware Interfaces */

== Motion-Controlled RC Car ==

[[File:S15_146_G3_IMG_RCcar.jpg|800px|center]]

== Abstract ==
The Motion-Controlled RC Car will allow inexperienced users to drive a high-performance RC vehicle. This is accomplished with a tilt controller, which is more intuitive than a traditional RC transmitter, and a slip-limiting system that will reduce the potential for crashes.

== Objectives & Introduction ==
High performance RC vehicles can be difficult to control because of their immense power and are typically expensive to repair. The goal of this project is to create both a wireless tilt controller and a traction control system for a high-performance RC car. From an engineering standpoint, the project can be broken into three major objectives.

1. Nordic wireless communication

2. Measurement of front and rear axle speed

3. Pulse-width modulated control of motor and servo

=== Team Members & Responsibilities ===

* Shangming Wang - Mesh Communication, Report writing, testing

* Daniel Khawaja - Wheel speed capture, RC car maintenance, PWM

== Schedule ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Completion Date
|-
! scope="row"| 0
| 4/10
| 4/24
| Obtain Hall sensors
| Not Completed
| ---
|-
! scope="row"| 1
| 4/20
| 4/27
| Find PWM parameters, Test mesh communication
| Completed
| PWM: 4/27 Mesh: 5/4
|-
! scope="row"| 2
| 4/27
| 5/4
| Implement PWM control, Finalize mesh communication, Obtain photo interrupters
| Completed
| PWM: 5/4 Mesh: 5/13 Photo: 5/14
|-
! scope="row"| 3
| 5/4
| 5/11
| Implement motion control, Modify RC for 2wd and mount wheel speed sensors
| Completed
| Motion: 5/13 Modification: 5/15
|-
! scope="row"| 4
| 5/11
| 5/18
| Finish wheel speed capture, Test and polish traction control parameters
| Completed
| Capture: 5/23 T.C.: 5/25

|-
! scope="row"| 5
| 5/18
| 5/25
| Implement extra features
| Not Completed
| ---
|}

== Parts List & Cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="60" align="center"|Total Cost
|-
| align="center"|50||Jumper Wires||align="right"|$3.00
|-
| align="center"|1||Prototype Board||align="right"|$1.00
|-
| align="center"|1||Turnigy 500mAh Battery||align="right"|$40.00
|-
| align="center"|2||Wireless Antenna||align="right"|$6.00
|-
| align="center"|1||Remote Control Car||align="right"|$150.00
|-
| align="center"|2||SJOne Board||align="right"|$160.00
|-
| align="center"|2||Motorola MOC7821 Photo Interrupter||align="right"|$4.00
|-
| ||Total Cost '''||align="right"|$364'''
|-
|}

== Design & Implementation ==

=== Hardware Design ===

[[File:S15_146_G3_IMG_1.png|400px|center]]

A high-level schematic of the electronics involved in this project

Our hardware design began with connecting the Sj-One board with the servo and motor controller controller that were built into the model car.

=== Hardware Interfaces ===
The Transmitting Module used the following interfaces:
* [http://www.socialledge.com/sjsu/index.php?title=Embedded_System_I2C_Tutorial I2C Bus]
** Used for reading the orientation value from accelerometer sensor
*[http://www.socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_SPI SPI Bus]
** Used for transmit commands from Nordic wireless sensor to receiving board

The Receiving Interface used the following interfaces:
*[http://www.socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_SPI SPI Bus]
** Used for receive commands from Nordic wireless sensor from transmitting board
*[http://www.socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_GPIO GPIO]
** Used to read the axle speed from the front and rear
** Used to pass PWM signal to the motor and the servo

=== SJOne ===
[[File:S15_146_G3_IMG_SJOne.png|center]]

Our project used two [http://http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJOne boards], both running FreeRTOS. For our project we used the built-in Nordic Wireless system, Accelerometer, GPIO, and PWM functions.

=== Servo, Motor & Motor Controller ===
[[File:S15_146_g3_pwmInterfacedElectronics.jpg|460px|center]]

The servo used in this project was a Futaba S3004 and the motor, already built into the model car, was a Leopard Hobby 3300Kv brushless motor. The Castle Sidewinder 3 motor controller and the Futaba servo were both controlled using pulse widths ranging from 1 to 2miliseconds. A width of 1.5 miliseconds was a 0% signal, 1 milisecond was -100%, and 2 miliseconds was +100%. The motor controller included a 5v regulated output, so it was used to power all the electronics on the vehicle.

=== Photo Interrupter ===
[[File:S15_146_G3_IMG_photoInt.png|200px|center]]

The photo interrupters we chose were the Motorola MOC7821. These devices contain an infrared LED and an infrared-controlled transistor. When the gap between the LED and the sensor is open the transistor turns on and allows current to flow. When an object passes through the space between the LED and the sensor the transistor turns off and behaves like an open circuit.

=== Software Design ===

'''Transmitting Module'''

The transmitter first reads the accelerometer data in both the x and y directions and encodes them in an integer. That integer is sent to the vehicle using the Nordic Wireless system.

[[File:S15_146_G3_IMG_flowchart_transmit.png|200px|center]]

'''Receiving Module'''

The SJ One board on the vehicle, waiting to receive data, accepts the integer. The vehicle reads the wheel speeds at the front and rear axle. This is done by reading the signal from the photo interrupters many times in a row and incrementing a counter each time the signal transitions between high and low. One counter holds the number of transitions read from the front axle and the other counter holds the number of transitions at the rear axle and the task determines if the vehicle is in a low traction situation based on the two counter values. The car then translates the encoded command using one of two throttle maps, based on the traction situation, and uses that to set motor speed and servo angle.

[[File:S15_146_G3_IMG_flowchart_receive.png|500px|center]]

=== Implementation ===

'''Accelerometer'''

The built-in sensor that reads the tilt direction of the SJ One board.

*Step 1: Initialize accelerometer sensor.

*Step 2: Read X and Y axis from the sensor and get the orientation of the board.

Read X value:
Function X-axis Range
Forward -200 <= x < 200
Left -500 <= x < -200
Right 200 <= x < 500
Hard Left x >= 500
Hard Right x <= -500

Read Y value:
Num Speed Y-axis Range
0 7.5 -150 <= y < 150
1 7.9 150 <= y < 250
2 8.3 250 <= y < 400
3 8.7 400 <= y < 550
4 9.1 550 <= y < 700
5 9.5 700 <= y < 850
6 9.9 y >= 850

*Step 3: Encode the function and speed number as a single integer and pass them to the wireless task.

'''Nordic Wireless''' (nRF24L01).

The Nordic wireless sensor is built-in on SJOne Board. It used to send and receive data from one SJOne to other. For our project, it is used to send an encoded x and y tilt of the control board to the board on the vehicle. The following steps were taken to implement the Nordic wireless system

*Step 1: Configure the wireless node address and wireless channel number in sys_config.h file. (Make sure both boards have the same channel)

*Step 2: Used mesh_set_node_address() function to set both sending and receiving address. In our project, the car address is set to 300.

*Step 3: On the sending side, it used wireless_send(addr, protocol, data, size of data, max_hops) function to send the data from SJOne board.

*Step 4: On the receiving side, it used wireless_get_rx_pkt() function to catch the data coming from the wireless.

'''Photo Interrupters''' (MOC7821).

[[File:S15_146_G3_IMG_motor.png|500px|left]] [[File:S15_146_G3_IMG_servo.png|460px|center]]

The photo interrupters are used to monitor wheel rotation. An interrupter was mounted around a disk attached to each differential. In the photos above the rear wheel speed sensor assembly and the front wheel speed sensor assembly are on the left and right, respectively. Notches were cut into the disks so that as they spun the outputs of the interrupters would rise and fall. The SJ One board monitored these signals using its GPIO inputs and counted the rising edges over a set period of time to determine the speed of the axle. Being a rear-drive vehicle, the rear axle rotates faster than the front in a slip condition, and the program responds by reducing throttle.

== Testing & Technical Challenges ==

=== Issue #1 ===
The first issue that we ran into involved our implementation of the Nordic wireless system. During the early stages of the project, we wrote and tested our features in separate C or C++ programs. Using the provided libraries and functions, we designed transmitting and receiving programs to test the wireless. During testing, the first packet sent without issue, but any following packets took up to 30 seconds to send. This is because the libraries and functions that we were relying on were designed to be used within the structured FreeRTOS environment. Using them without the work that FreeRTOS does in the background causes them to misbehave.

=== Issue #2 ===
The Motorola MOC7821 photo interrupters that we purchased had very little documentation. We found information about the sensor side of the part, but nothing about the LEDs that make up the infrared emitters. Two of the interrupter's LEDs burnt out before we found the correct dropout voltage and amperage. We recommend that future students obtain access to a variable power supply and test the LEDs by slowly increasing voltage from zero until the dropout voltage is found.

=== Issue #3 ===
This issue was never resolved. Our initial design goal was to implement the timer's capture system so that the rising edges of the photo interrupters' signals could be counted without consuming CPU cycles. The initialization process seemed straightforward but any time we attempted to modify the lower 4 bits of the Counter Control Register it caused an error that triggered a reboot of the system. After many hours of research and guessing no solution was found so we made our own function that, at the price of many CPU cycles, used the GPIO pins to accomplish the same goal.

Any project of this type will encounter roadblocks such as these. These issues, as well as many smaller bugs, were discovered and resolved using frequent testing. Each task was broken down into as small of a block as we could devise a test for. For example, the photo interrupters were tested in four stages. First we tested the sensor side using an infrared television remote. Once we knew the sensor was working we tested the LEDs using an infrared sensitive camera. The whole package was then tested on a bread board, and finally tested again once installed on the model car.

This multi-tiered testing approach was also applied to our software design process. Testing was an integral part of our design and frequent testing helped us to catch bugs sooner and solve them faster by shrinking the amount of code that could be contributing to the problem.

== Conclusion ==

Though this project was ultimately successful, it was a struggle. Poor planning coupled with an injury from a car accident and an untrustworthy online retailer all pushed the timeline for the project. We were severely behind schedule and were able to successfully complete the project by abandoning the "capture" peripheral and placing the load on the CPU by using the GPIO pins. This project taught a lesson in proper scheduling and planning.

However, that was not the only lesson. In our implementation we were forced to execute, in a best case situation, over 500 lines of code in between each command between the transmitter and the receiver. The delay that the extra code caused in the controlling of the vehicle was barely noticeable, and helped us to see just how blazingly fast modern micro controllers actually are. The thought of a micro controller being slower and "less capable" than a computer is, in most cases, incorrect.

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

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]

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

=== References Used ===
http://www.nxp.com/documents/user_manual/UM10360.pdf

http://www.socialledge.com/sjsu/images/d/de/2012SJOneBoardSchematic.pdf

http://www.datasheetspdf.com/PDF/MOC7821/613725/1

http://www.socialledge.com/sjsu/index.php?title=PWM_Motor_Controller_Interface

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

http://www.socialledge.com/sjsu/index.php?title=Low_Powered_Mesh_Network_stack

S15: Motion-Controlled RC Car

2015-05-27T03:33:50Z

146 user3: /* SJOne */

== Motion-Controlled RC Car ==

[[File:S15_146_G3_IMG_RCcar.jpg|800px|center]]

== Abstract ==
The Motion-Controlled RC Car will allow inexperienced users to drive a high-performance RC vehicle. This is accomplished with a tilt controller, which is more intuitive than a traditional RC transmitter, and a slip-limiting system that will reduce the potential for crashes.

== Objectives & Introduction ==
High performance RC vehicles can be difficult to control because of their immense power and are typically expensive to repair. The goal of this project is to create both a wireless tilt controller and a traction control system for a high-performance RC car. From an engineering standpoint, the project can be broken into three major objectives.

1. Nordic wireless communication

2. Measurement of front and rear axle speed

3. Pulse-width modulated control of motor and servo

=== Team Members & Responsibilities ===

* Shangming Wang - Mesh Communication, Report writing, testing

* Daniel Khawaja - Wheel speed capture, RC car maintenance, PWM

== Schedule ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Completion Date
|-
! scope="row"| 0
| 4/10
| 4/24
| Obtain Hall sensors
| Not Completed
| ---
|-
! scope="row"| 1
| 4/20
| 4/27
| Find PWM parameters, Test mesh communication
| Completed
| PWM: 4/27 Mesh: 5/4
|-
! scope="row"| 2
| 4/27
| 5/4
| Implement PWM control, Finalize mesh communication, Obtain photo interrupters
| Completed
| PWM: 5/4 Mesh: 5/13 Photo: 5/14
|-
! scope="row"| 3
| 5/4
| 5/11
| Implement motion control, Modify RC for 2wd and mount wheel speed sensors
| Completed
| Motion: 5/13 Modification: 5/15
|-
! scope="row"| 4
| 5/11
| 5/18
| Finish wheel speed capture, Test and polish traction control parameters
| Completed
| Capture: 5/23 T.C.: 5/25

|-
! scope="row"| 5
| 5/18
| 5/25
| Implement extra features
| Not Completed
| ---
|}

== Parts List & Cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="60" align="center"|Total Cost
|-
| align="center"|50||Jumper Wires||align="right"|$3.00
|-
| align="center"|1||Prototype Board||align="right"|$1.00
|-
| align="center"|1||Turnigy 500mAh Battery||align="right"|$40.00
|-
| align="center"|2||Wireless Antenna||align="right"|$6.00
|-
| align="center"|1||Remote Control Car||align="right"|$150.00
|-
| align="center"|2||SJOne Board||align="right"|$160.00
|-
| align="center"|2||Motorola MOC7821 Photo Interrupter||align="right"|$4.00
|-
| ||Total Cost '''||align="right"|$364'''
|-
|}

== Design & Implementation ==

=== Hardware Design ===

[[File:S15_146_G3_IMG_1.png|400px|center]]

A high-level schematic of the electronics involved in this project

Our hardware design began with connecting the Sj-One board with the servo and motor controller controller that were built into the model car.

=== Hardware Interfaces ===
The Transmitting Module used the following interfaces:
* I2C Bus
** Used for reading the orientation value from accelerometer sensor
*SPI Bus
** Used for transmit commands from Nordic wireless sensor to receiving board

The Receiving Interface used the following interfaces:
*SPI Bus
** Used for receive commands from Nordic wireless sensor from transmitting board
*GPIO
** Used to read the axle speed from the front and rear
** Used to passing PWM signal to the motor and the servo

=== SJOne ===
[[File:S15_146_G3_IMG_SJOne.png|center]]

Our project used two [http://http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board SJOne boards], both running FreeRTOS. For our project we used the built-in Nordic Wireless system, Accelerometer, GPIO, and PWM functions.

=== Servo, Motor & Motor Controller ===
[[File:S15_146_g3_pwmInterfacedElectronics.jpg|460px|center]]

The servo used in this project was a Futaba S3004 and the motor, already built into the model car, was a Leopard Hobby 3300Kv brushless motor. The Castle Sidewinder 3 motor controller and the Futaba servo were both controlled using pulse widths ranging from 1 to 2miliseconds. A width of 1.5 miliseconds was a 0% signal, 1 milisecond was -100%, and 2 miliseconds was +100%. The motor controller included a 5v regulated output, so it was used to power all the electronics on the vehicle.

=== Photo Interrupter ===
[[File:S15_146_G3_IMG_photoInt.png|200px|center]]

The photo interrupters we chose were the Motorola MOC7821. These devices contain an infrared LED and an infrared-controlled transistor. When the gap between the LED and the sensor is open the transistor turns on and allows current to flow. When an object passes through the space between the LED and the sensor the transistor turns off and behaves like an open circuit.

=== Software Design ===

'''Transmitting Module'''

The transmitter first reads the accelerometer data in both the x and y directions and encodes them in an integer. That integer is sent to the vehicle using the Nordic Wireless system.

[[File:S15_146_G3_IMG_flowchart_transmit.png|200px|center]]

'''Receiving Module'''

The SJ One board on the vehicle, waiting to receive data, accepts the integer. The vehicle reads the wheel speeds at the front and rear axle. This is done by reading the signal from the photo interrupters many times in a row and incrementing a counter each time the signal transitions between high and low. One counter holds the number of transitions read from the front axle and the other counter holds the number of transitions at the rear axle and the task determines if the vehicle is in a low traction situation based on the two counter values. The car then translates the encoded command using one of two throttle maps, based on the traction situation, and uses that to set motor speed and servo angle.

[[File:S15_146_G3_IMG_flowchart_receive.png|500px|center]]

=== Implementation ===

'''Accelerometer'''

The built-in sensor that reads the tilt direction of the SJ One board.

*Step 1: Initialize accelerometer sensor.

*Step 2: Read X and Y axis from the sensor and get the orientation of the board.

Read X value:
Function X-axis Range
Forward -200 <= x < 200
Left -500 <= x < -200
Right 200 <= x < 500
Hard Left x >= 500
Hard Right x <= -500

Read Y value:
Num Speed Y-axis Range
0 7.5 -150 <= y < 150
1 7.9 150 <= y < 250
2 8.3 250 <= y < 400
3 8.7 400 <= y < 550
4 9.1 550 <= y < 700
5 9.5 700 <= y < 850
6 9.9 y >= 850

*Step 3: Encode the function and speed number as a single integer and pass them to the wireless task.

'''Nordic Wireless''' (nRF24L01).

The Nordic wireless sensor is built-in on SJOne Board. It used to send and receive data from one SJOne to other. For our project, it is used to send an encoded x and y tilt of the control board to the board on the vehicle. The following steps were taken to implement the Nordic wireless system

*Step 1: Configure the wireless node address and wireless channel number in sys_config.h file. (Make sure both boards have the same channel)

*Step 2: Used mesh_set_node_address() function to set both sending and receiving address. In our project, the car address is set to 300.

*Step 3: On the sending side, it used wireless_send(addr, protocol, data, size of data, max_hops) function to send the data from SJOne board.

*Step 4: On the receiving side, it used wireless_get_rx_pkt() function to catch the data coming from the wireless.

'''Photo Interrupters''' (MOC7821).

[[File:S15_146_G3_IMG_motor.png|500px|left]] [[File:S15_146_G3_IMG_servo.png|460px|center]]

The photo interrupters are used to monitor wheel rotation. An interrupter was mounted around a disk attached to each differential. In the photos above the rear wheel speed sensor assembly and the front wheel speed sensor assembly are on the left and right, respectively. Notches were cut into the disks so that as they spun the outputs of the interrupters would rise and fall. The SJ One board monitored these signals using its GPIO inputs and counted the rising edges over a set period of time to determine the speed of the axle. Being a rear-drive vehicle, the rear axle rotates faster than the front in a slip condition, and the program responds by reducing throttle.

== Testing & Technical Challenges ==

=== Issue #1 ===
The first issue that we ran into involved our implementation of the Nordic wireless system. During the early stages of the project, we wrote and tested our features in separate C or C++ programs. Using the provided libraries and functions, we designed transmitting and receiving programs to test the wireless. During testing, the first packet sent without issue, but any following packets took up to 30 seconds to send. This is because the libraries and functions that we were relying on were designed to be used within the structured FreeRTOS environment. Using them without the work that FreeRTOS does in the background causes them to misbehave.

=== Issue #2 ===
The Motorola MOC7821 photo interrupters that we purchased had very little documentation. We found information about the sensor side of the part, but nothing about the LEDs that make up the infrared emitters. Two of the interrupter's LEDs burnt out before we found the correct dropout voltage and amperage. We recommend that future students obtain access to a variable power supply and test the LEDs by slowly increasing voltage from zero until the dropout voltage is found.

=== Issue #3 ===
This issue was never resolved. Our initial design goal was to implement the timer's capture system so that the rising edges of the photo interrupters' signals could be counted without consuming CPU cycles. The initialization process seemed straightforward but any time we attempted to modify the lower 4 bits of the Counter Control Register it caused an error that triggered a reboot of the system. After many hours of research and guessing no solution was found so we made our own function that, at the price of many CPU cycles, used the GPIO pins to accomplish the same goal.

Any project of this type will encounter roadblocks such as these. These issues, as well as many smaller bugs, were discovered and resolved using frequent testing. Each task was broken down into as small of a block as we could devise a test for. For example, the photo interrupters were tested in four stages. First we tested the sensor side using an infrared television remote. Once we knew the sensor was working we tested the LEDs using an infrared sensitive camera. The whole package was then tested on a bread board, and finally tested again once installed on the model car.

This multi-tiered testing approach was also applied to our software design process. Testing was an integral part of our design and frequent testing helped us to catch bugs sooner and solve them faster by shrinking the amount of code that could be contributing to the problem.

== Conclusion ==

Though this project was ultimately successful, it was a struggle. Poor planning coupled with an injury from a car accident and an untrustworthy online retailer all pushed the timeline for the project. We were severely behind schedule and were able to successfully complete the project by abandoning the "capture" peripheral and placing the load on the CPU by using the GPIO pins. This project taught a lesson in proper scheduling and planning.

However, that was not the only lesson. In our implementation we were forced to execute, in a best case situation, over 500 lines of code in between each command between the transmitter and the receiver. The delay that the extra code caused in the controlling of the vehicle was barely noticeable, and helped us to see just how blazingly fast modern micro controllers actually are. The thought of a micro controller being slower and "less capable" than a computer is, in most cases, incorrect.

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

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]

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

=== References Used ===
http://www.nxp.com/documents/user_manual/UM10360.pdf

http://www.socialledge.com/sjsu/images/d/de/2012SJOneBoardSchematic.pdf

http://www.datasheetspdf.com/PDF/MOC7821/613725/1

http://www.socialledge.com/sjsu/index.php?title=PWM_Motor_Controller_Interface

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

http://www.socialledge.com/sjsu/index.php?title=Low_Powered_Mesh_Network_stack

S15: Motion-Controlled RC Car

2015-05-27T03:15:09Z

146 user3: /* SJOne */

== Motion-Controlled RC Car ==

[[File:S15_146_G3_IMG_RCcar.jpg|800px|center]]

== Abstract ==
The Motion-Controlled RC Car will allow inexperienced users to drive a high-performance RC vehicle. This is accomplished with a tilt controller, which is more intuitive than a traditional RC transmitter, and a slip-limiting system that will reduce the potential for crashes.

== Objectives & Introduction ==
High performance RC vehicles can be difficult to control because of their immense power and are typically expensive to repair. The goal of this project is to create both a wireless tilt controller and a traction control system for a high-performance RC car. From an engineering standpoint, the project can be broken into three major objectives.

1. Nordic wireless communication

2. Measurement of front and rear axle speed

3. Pulse-width modulated control of motor and servo

=== Team Members & Responsibilities ===

* Shangming Wang - Mesh Communication, Report writing, testing

* Daniel Khawaja - Wheel speed capture, RC car maintenance, PWM

== Schedule ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Completion Date
|-
! scope="row"| 0
| 4/10
| 4/24
| Obtain Hall sensors
| Not Completed
| ---
|-
! scope="row"| 1
| 4/20
| 4/27
| Find PWM parameters, Test mesh communication
| Completed
| PWM: 4/27 Mesh: 5/4
|-
! scope="row"| 2
| 4/27
| 5/4
| Implement PWM control, Finalize mesh communication, Obtain photo interrupters
| Completed
| PWM: 5/4 Mesh: 5/13 Photo: 5/14
|-
! scope="row"| 3
| 5/4
| 5/11
| Implement motion control, Modify RC for 2wd and mount wheel speed sensors
| Completed
| Motion: 5/13 Modification: 5/15
|-
! scope="row"| 4
| 5/11
| 5/18
| Finish wheel speed capture, Test and polish traction control parameters
| Completed
| Capture: 5/23 T.C.: 5/25

|-
! scope="row"| 5
| 5/18
| 5/25
| Implement extra features
| Not Completed
| ---
|}

== Parts List & Cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="60" align="center"|Total Cost
|-
| align="center"|50||Jumper Wires||align="right"|$3.00
|-
| align="center"|1||Prototype Board||align="right"|$1.00
|-
| align="center"|1||Turnigy 500mAh Battery||align="right"|$40.00
|-
| align="center"|2||Wireless Antenna||align="right"|$6.00
|-
| align="center"|1||Remote Control Car||align="right"|$150.00
|-
| align="center"|2||SJOne Board||align="right"|$160.00
|-
| align="center"|2||Motorola MOC7821 Photo Interrupter||align="right"|$4.00
|-
| ||Total Cost '''||align="right"|$364'''
|-
|}

== Design & Implementation ==

=== Hardware Design ===

[[File:S15_146_G3_IMG_1.png|400px|center]]

A high-level schematic of the electronics involved in this project

Our hardware design began with connecting the Sj-One board with the servo and motor controller controller that were built into the model car.

=== Hardware Interfaces ===
The Transmitting Module used the following interfaces:
* I2C Bus
** Used for reading the orientation value from accelerometer sensor
*SPI Bus
** Used for transmit commands from Nordic wireless sensor to receiving board

The Receiving Interface used the following interfaces:
*SPI Bus
** Used for receive commands from Nordic wireless sensor from transmitting board
*GPIO
** Used to read the axle speed from the front and rear
** Used to passing PWM signal to the motor and the servo

=== SJOne ===
[[File:S15_146_G3_IMG_SJOne.png|center]]

The SJOne board is running FreeRTOS. It has Nordic Wireless sensor, Accelerometer sensor, and PWM built-in functions for communicate two boards wirelessly and provide power signal to control the external motor.

=== Servo, Motor & Motor Controller ===
[[File:S15_146_g3_pwmInterfacedElectronics.jpg|460px|center]]

The servo used in this project was a Futaba S3004 and the motor, already built into the model car, was a Leopard Hobby 3300Kv brushless motor. The Castle Sidewinder 3 motor controller and the Futaba servo were both controlled using pulse widths ranging from 1 to 2miliseconds. A width of 1.5 miliseconds was a 0% signal, 1 milisecond was -100%, and 2 miliseconds was +100%. The motor controller included a 5v regulated output, so it was used to power all the electronics on the vehicle.

=== Photo Interrupter ===
[[File:S15_146_G3_IMG_photoInt.png|200px|center]]

The photo interrupters we chose were the Motorola MOC7821. These devices contain an infrared LED and an infrared-controlled transistor. When the gap between the LED and the sensor is open the transistor turns on and allows current to flow. When an object passes through the space between the LED and the sensor the transistor turns off and behaves like an open circuit.

=== Software Design ===

'''Transmitting Module'''

The transmitter first reads the accelerometer data in both the x and y directions and encodes them in an integer. That integer is sent to the vehicle using the Nordic Wireless system.

[[File:S15_146_G3_IMG_flowchart_transmit.png|200px|center]]

'''Receiving Module'''

The SJ One board on the vehicle, waiting to receive data, accepts the integer. The vehicle reads the wheel speeds at the front and rear axle. This is done by reading the signal from the photo interrupters many times in a row and incrementing a counter each time the signal transitions between high and low. One counter holds the number of transitions read from the front axle and the other counter holds the number of transitions at the rear axle and the task determines if the vehicle is in a low traction situation based on the two counter values. The car then translates the encoded command using one of two throttle maps, based on the traction situation, and uses that to set motor speed and servo angle.

[[File:S15_146_G3_IMG_flowchart_receive.png|500px|center]]

=== Implementation ===

'''Accelerometer'''

The built-in sensor that reads the tilt direction of the SJ One board.

*Step 1: Initialize accelerometer sensor.

*Step 2: Read X and Y axis from the sensor and get the orientation of the board.

Read X value:
Function X-axis Range
Forward -200 <= x < 200
Left -500 <= x < -200
Right 200 <= x < 500
Hard Left x >= 500
Hard Right x <= -500

Read Y value:
Num Speed Y-axis Range
0 7.5 -150 <= y < 150
1 7.9 150 <= y < 250
2 8.3 250 <= y < 400
3 8.7 400 <= y < 550
4 9.1 550 <= y < 700
5 9.5 700 <= y < 850
6 9.9 y >= 850

*Step 3: Encode the function and speed number as a single integer and pass them to the wireless task.

'''Nordic Wireless''' (nRF24L01).

The Nordic wireless sensor is built-in on SJOne Board. It used to send and receive data from one SJOne to other. For our project, it is used to send an encoded x and y tilt of the control board to the board on the vehicle. The following steps were taken to implement the Nordic wireless system

*Step 1: Configure the wireless node address and wireless channel number in sys_config.h file. (Make sure both boards have the same channel)

*Step 2: Used mesh_set_node_address() function to set both sending and receiving address. In our project, the car address is set to 300.

*Step 3: On the sending side, it used wireless_send(addr, protocol, data, size of data, max_hops) function to send the data from SJOne board.

*Step 4: On the receiving side, it used wireless_get_rx_pkt() function to catch the data coming from the wireless.

'''Photo Interrupters''' (MOC7821).

[[File:S15_146_G3_IMG_motor.png|500px|left]] [[File:S15_146_G3_IMG_servo.png|460px|center]]

The photo interrupters are used to monitor wheel rotation. An interrupter was mounted around a disk attached to each differential. In the photos above the rear wheel speed sensor assembly and the front wheel speed sensor assembly are on the left and right, respectively. Notches were cut into the disks so that as they spun the outputs of the interrupters would rise and fall. The SJ One board monitored these signals using its GPIO inputs and counted the rising edges over a set period of time to determine the speed of the axle. Being a rear-drive vehicle, the rear axle rotates faster than the front in a slip condition, and the program responds by reducing throttle.

== Testing & Technical Challenges ==

=== Issue #1 ===
The first issue that we ran into involved our implementation of the Nordic wireless system. During the early stages of the project, we wrote and tested our features in separate C or C++ programs. Using the provided libraries and functions, we designed transmitting and receiving programs to test the wireless. During testing, the first packet sent without issue, but any following packets took up to 30 seconds to send. This is because the libraries and functions that we were relying on were designed to be used within the structured FreeRTOS environment. Using them without the work that FreeRTOS does in the background causes them to misbehave.

=== Issue #2 ===
The Motorola MOC7821 photo interrupters that we purchased had very little documentation. We found information about the sensor side of the part, but nothing about the LEDs that make up the infrared emitters. Two of the interrupter's LEDs burnt out before we found the correct dropout voltage and amperage. We recommend that future students obtain access to a variable power supply and test the LEDs by slowly increasing voltage from zero until the dropout voltage is found.

=== Issue #3 ===
This issue was never resolved. Our initial design goal was to implement the timer's capture system so that the rising edges of the photo interrupters' signals could be counted without consuming CPU cycles. The initialization process seemed straightforward but any time we attempted to modify the lower 4 bits of the Counter Control Register it caused an error that triggered a reboot of the system. After many hours of research and guessing no solution was found so we made our own function that, at the price of many CPU cycles, used the GPIO pins to accomplish the same goal.

Any project of this type will encounter roadblocks such as these. These issues, as well as many smaller bugs, were discovered and resolved using frequent testing. Each task was broken down into as small of a block as we could devise a test for. For example, the photo interrupters were tested in four stages. First we tested the sensor side using an infrared television remote. Once we knew the sensor was working we tested the LEDs using an infrared sensitive camera. The whole package was then tested on a bread board, and finally tested again once installed on the model car.

This multi-tiered testing approach was also applied to our software design process. Testing was an integral part of our design and frequent testing helped us to catch bugs sooner and solve them faster by shrinking the amount of code that could be contributing to the problem.

== Conclusion ==

Though this project was ultimately successful, it was a struggle. Poor planning coupled with an injury from a car accident and an untrustworthy online retailer all pushed the timeline for the project. We were severely behind schedule and were able to successfully complete the project by abandoning the "capture" peripheral and placing the load on the CPU by using the GPIO pins. This project taught a lesson in proper scheduling and planning.

However, that was not the only lesson. In our implementation we were forced to execute, in a best case situation, over 500 lines of code in between each command between the transmitter and the receiver. The delay that the extra code caused in the controlling of the vehicle was barely noticeable, and helped us to see just how blazingly fast modern micro controllers actually are. The thought of a micro controller being slower and "less capable" than a computer is, in most cases, incorrect.

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

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]

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

=== References Used ===
http://www.nxp.com/documents/user_manual/UM10360.pdf

http://www.socialledge.com/sjsu/images/d/de/2012SJOneBoardSchematic.pdf

http://www.datasheetspdf.com/PDF/MOC7821/613725/1

http://www.socialledge.com/sjsu/index.php?title=PWM_Motor_Controller_Interface

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

http://www.socialledge.com/sjsu/index.php?title=Low_Powered_Mesh_Network_stack

S15: Motion-Controlled RC Car

2015-05-27T03:10:11Z

146 user3: /* Photo Interrupter */

== Motion-Controlled RC Car ==

[[File:S15_146_G3_IMG_RCcar.jpg|800px|center]]

== Abstract ==
The Motion-Controlled RC Car will allow inexperienced users to drive a high-performance RC vehicle. This is accomplished with a tilt controller, which is more intuitive than a traditional RC transmitter, and a slip-limiting system that will reduce the potential for crashes.

== Objectives & Introduction ==
High performance RC vehicles can be difficult to control because of their immense power and are typically expensive to repair. The goal of this project is to create both a wireless tilt controller and a traction control system for a high-performance RC car. From an engineering standpoint, the project can be broken into three major objectives.

1. Nordic wireless communication

2. Measurement of front and rear axle speed

3. Pulse-width modulated control of motor and servo

=== Team Members & Responsibilities ===

* Shangming Wang - Mesh Communication, Report writing, testing

* Daniel Khawaja - Wheel speed capture, RC car maintenance, PWM

== Schedule ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Completion Date
|-
! scope="row"| 0
| 4/10
| 4/24
| Obtain Hall sensors
| Not Completed
| ---
|-
! scope="row"| 1
| 4/20
| 4/27
| Find PWM parameters, Test mesh communication
| Completed
| PWM: 4/27 Mesh: 5/4
|-
! scope="row"| 2
| 4/27
| 5/4
| Implement PWM control, Finalize mesh communication, Obtain photo interrupters
| Completed
| PWM: 5/4 Mesh: 5/13 Photo: 5/14
|-
! scope="row"| 3
| 5/4
| 5/11
| Implement motion control, Modify RC for 2wd and mount wheel speed sensors
| Completed
| Motion: 5/13 Modification: 5/15
|-
! scope="row"| 4
| 5/11
| 5/18
| Finish wheel speed capture, Test and polish traction control parameters
| Completed
| Capture: 5/23 T.C.: 5/25

|-
! scope="row"| 5
| 5/18
| 5/25
| Implement extra features
| Not Completed
| ---
|}

== Parts List & Cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="60" align="center"|Total Cost
|-
| align="center"|50||Jumper Wires||align="right"|$3.00
|-
| align="center"|1||Prototype Board||align="right"|$1.00
|-
| align="center"|1||Turnigy 500mAh Battery||align="right"|$40.00
|-
| align="center"|2||Wireless Antenna||align="right"|$6.00
|-
| align="center"|1||Remote Control Car||align="right"|$150.00
|-
| align="center"|2||SJOne Board||align="right"|$160.00
|-
| align="center"|2||Motorola MOC7821 Photo Interrupter||align="right"|$4.00
|-
| ||Total Cost '''||align="right"|$364'''
|-
|}

== Design & Implementation ==

=== Hardware Design ===

[[File:S15_146_G3_IMG_1.png|400px|center]]

A high-level schematic of the electronics involved in this project

Our hardware design began with connecting the Sj-One board with the servo and motor controller controller that were built into the model car.

=== Hardware Interfaces ===
The Transmitting Module used the following interfaces:
* I2C Bus
** Used for reading the orientation value from accelerometer sensor
*SPI Bus
** Used for transmit commands from Nordic wireless sensor to receiving board

The Receiving Interface used the following interfaces:
*SPI Bus
** Used for receive commands from Nordic wireless sensor from transmitting board
*GPIO
** Used to read the axle speed from the front and rear
** Used to passing PWM signal to the motor and the servo

=== SJOne ===
[[File:S15_146_G3_IMG_SJOne.png|center]]

=== Servo, Motor & Motor Controller ===
[[File:S15_146_g3_pwmInterfacedElectronics.jpg|460px|center]]

The servo used in this project was a Futaba S3004 and the motor, already built into the model car, was a Leopard Hobby 3300Kv brushless motor. The Castle Sidewinder 3 motor controller and the Futaba servo were both controlled using pulse widths ranging from 1 to 2miliseconds. A width of 1.5 miliseconds was a 0% signal, 1 milisecond was -100%, and 2 miliseconds was +100%. The motor controller included a 5v regulated output, so it was used to power all the electronics on the vehicle.

=== Photo Interrupter ===
[[File:S15_146_G3_IMG_photoInt.png|200px|center]]

The photo interrupters we chose were the Motorola MOC7821. These devices contain an infrared LED and an infrared-controlled transistor. When the gap between the LED and the sensor is open the transistor turns on and allows current to flow. When an object passes through the space between the LED and the sensor the transistor turns off and behaves like an open circuit.

=== Software Design ===

'''Transmitting Module'''

The transmitter first reads the accelerometer data in both the x and y directions and encodes them in an integer. That integer is sent to the vehicle using the Nordic Wireless system.

[[File:S15_146_G3_IMG_flowchart_transmit.png|200px|center]]

'''Receiving Module'''

The SJ One board on the vehicle, waiting to receive data, accepts the integer. The vehicle reads the wheel speeds at the front and rear axle. This is done by reading the signal from the photo interrupters many times in a row and incrementing a counter each time the signal transitions between high and low. One counter holds the number of transitions read from the front axle and the other counter holds the number of transitions at the rear axle and the task determines if the vehicle is in a low traction situation based on the two counter values. The car then translates the encoded command using one of two throttle maps, based on the traction situation, and uses that to set motor speed and servo angle.

[[File:S15_146_G3_IMG_flowchart_receive.png|500px|center]]

=== Implementation ===

'''Accelerometer'''

The built-in sensor that reads the tilt direction of the SJ One board.

*Step 1: Initialize accelerometer sensor.

*Step 2: Read X and Y axis from the sensor and get the orientation of the board.

Read X value:
Function X-axis Range
Forward -200 <= x < 200
Left -500 <= x < -200
Right 200 <= x < 500
Hard Left x >= 500
Hard Right x <= -500

Read Y value:
Num Speed Y-axis Range
0 7.5 -150 <= y < 150
1 7.9 150 <= y < 250
2 8.3 250 <= y < 400
3 8.7 400 <= y < 550
4 9.1 550 <= y < 700
5 9.5 700 <= y < 850
6 9.9 y >= 850

*Step 3: Encode the function and speed number as a single integer and pass them to the wireless task.

'''Nordic Wireless''' (nRF24L01).

The Nordic wireless sensor is built-in on SJOne Board. It used to send and receive data from one SJOne to other. For our project, it is used to send an encoded x and y tilt of the control board to the board on the vehicle. The following steps were taken to implement the Nordic wireless system

*Step 1: Configure the wireless node address and wireless channel number in sys_config.h file. (Make sure both boards have the same channel)

*Step 2: Used mesh_set_node_address() function to set both sending and receiving address. In our project, the car address is set to 300.

*Step 3: On the sending side, it used wireless_send(addr, protocol, data, size of data, max_hops) function to send the data from SJOne board.

*Step 4: On the receiving side, it used wireless_get_rx_pkt() function to catch the data coming from the wireless.

'''Photo Interrupters''' (MOC7821).

[[File:S15_146_G3_IMG_motor.png|500px|left]] [[File:S15_146_G3_IMG_servo.png|460px|center]]

The photo interrupters are used to monitor wheel rotation. An interrupter was mounted around a disk attached to each differential. In the photos above the rear wheel speed sensor assembly and the front wheel speed sensor assembly are on the left and right, respectively. Notches were cut into the disks so that as they spun the outputs of the interrupters would rise and fall. The SJ One board monitored these signals using its GPIO inputs and counted the rising edges over a set period of time to determine the speed of the axle. Being a rear-drive vehicle, the rear axle rotates faster than the front in a slip condition, and the program responds by reducing throttle.

== Testing & Technical Challenges ==

=== Issue #1 ===
The first issue that we ran into involved our implementation of the Nordic wireless system. During the early stages of the project, we wrote and tested our features in separate C or C++ programs. Using the provided libraries and functions, we designed transmitting and receiving programs to test the wireless. During testing, the first packet sent without issue, but any following packets took up to 30 seconds to send. This is because the libraries and functions that we were relying on were designed to be used within the structured FreeRTOS environment. Using them without the work that FreeRTOS does in the background causes them to misbehave.

=== Issue #2 ===
The Motorola MOC7821 photo interrupters that we purchased had very little documentation. We found information about the sensor side of the part, but nothing about the LEDs that make up the infrared emitters. Two of the interrupter's LEDs burnt out before we found the correct dropout voltage and amperage. We recommend that future students obtain access to a variable power supply and test the LEDs by slowly increasing voltage from zero until the dropout voltage is found.

=== Issue #3 ===
This issue was never resolved. Our initial design goal was to implement the timer's capture system so that the rising edges of the photo interrupters' signals could be counted without consuming CPU cycles. The initialization process seemed straightforward but any time we attempted to modify the lower 4 bits of the Counter Control Register it caused an error that triggered a reboot of the system. After many hours of research and guessing no solution was found so we made our own function that, at the price of many CPU cycles, used the GPIO pins to accomplish the same goal.

Any project of this type will encounter roadblocks such as these. These issues, as well as many smaller bugs, were discovered and resolved using frequent testing. Each task was broken down into as small of a block as we could devise a test for. For example, the photo interrupters were tested in four stages. First we tested the sensor side using an infrared television remote. Once we knew the sensor was working we tested the LEDs using an infrared sensitive camera. The whole package was then tested on a bread board, and finally tested again once installed on the model car.

This multi-tiered testing approach was also applied to our software design process. Testing was an integral part of our design and frequent testing helped us to catch bugs sooner and solve them faster by shrinking the amount of code that could be contributing to the problem.

== Conclusion ==

Though this project was ultimately successful, it was a struggle. Poor planning coupled with an injury from a car accident and an untrustworthy online retailer all pushed the timeline for the project. We were severely behind schedule and were able to successfully complete the project by abandoning the "capture" peripheral and placing the load on the CPU by using the GPIO pins. This project taught a lesson in proper scheduling and planning.

However, that was not the only lesson. In our implementation we were forced to execute, in a best case situation, over 500 lines of code in between each command between the transmitter and the receiver. The delay that the extra code caused in the controlling of the vehicle was barely noticeable, and helped us to see just how blazingly fast modern micro controllers actually are. The thought of a micro controller being slower and "less capable" than a computer is, in most cases, incorrect.

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

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]

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

=== References Used ===
http://www.nxp.com/documents/user_manual/UM10360.pdf

http://www.socialledge.com/sjsu/images/d/de/2012SJOneBoardSchematic.pdf

http://www.datasheetspdf.com/PDF/MOC7821/613725/1

http://www.socialledge.com/sjsu/index.php?title=PWM_Motor_Controller_Interface

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

http://www.socialledge.com/sjsu/index.php?title=Low_Powered_Mesh_Network_stack

S15: Motion-Controlled RC Car

2015-05-27T03:07:13Z

146 user3: /* Design & Implementation */

== Motion-Controlled RC Car ==

[[File:S15_146_G3_IMG_RCcar.jpg|800px|center]]

== Abstract ==
The Motion-Controlled RC Car will allow inexperienced users to drive a high-performance RC vehicle. This is accomplished with a tilt controller, which is more intuitive than a traditional RC transmitter, and a slip-limiting system that will reduce the potential for crashes.

== Objectives & Introduction ==
High performance RC vehicles can be difficult to control because of their immense power and are typically expensive to repair. The goal of this project is to create both a wireless tilt controller and a traction control system for a high-performance RC car. From an engineering standpoint, the project can be broken into three major objectives.

1. Nordic wireless communication

2. Measurement of front and rear axle speed

3. Pulse-width modulated control of motor and servo

=== Team Members & Responsibilities ===

* Shangming Wang - Mesh Communication, Report writing, testing

* Daniel Khawaja - Wheel speed capture, RC car maintenance, PWM

== Schedule ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Completion Date
|-
! scope="row"| 0
| 4/10
| 4/24
| Obtain Hall sensors
| Not Completed
| ---
|-
! scope="row"| 1
| 4/20
| 4/27
| Find PWM parameters, Test mesh communication
| Completed
| PWM: 4/27 Mesh: 5/4
|-
! scope="row"| 2
| 4/27
| 5/4
| Implement PWM control, Finalize mesh communication, Obtain photo interrupters
| Completed
| PWM: 5/4 Mesh: 5/13 Photo: 5/14
|-
! scope="row"| 3
| 5/4
| 5/11
| Implement motion control, Modify RC for 2wd and mount wheel speed sensors
| Completed
| Motion: 5/13 Modification: 5/15
|-
! scope="row"| 4
| 5/11
| 5/18
| Finish wheel speed capture, Test and polish traction control parameters
| Completed
| Capture: 5/23 T.C.: 5/25

|-
! scope="row"| 5
| 5/18
| 5/25
| Implement extra features
| Not Completed
| ---
|}

== Parts List & Cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="60" align="center"|Total Cost
|-
| align="center"|50||Jumper Wires||align="right"|$3.00
|-
| align="center"|1||Prototype Board||align="right"|$1.00
|-
| align="center"|1||Turnigy 500mAh Battery||align="right"|$40.00
|-
| align="center"|2||Wireless Antenna||align="right"|$6.00
|-
| align="center"|1||Remote Control Car||align="right"|$150.00
|-
| align="center"|2||SJOne Board||align="right"|$160.00
|-
| align="center"|2||Motorola MOC7821 Photo Interrupter||align="right"|$4.00
|-
| ||Total Cost '''||align="right"|$364'''
|-
|}

== Design & Implementation ==

=== Hardware Design ===

[[File:S15_146_G3_IMG_1.png|400px|center]]

A high-level schematic of the electronics involved in this project

Our hardware design began with connecting the Sj-One board with the servo and motor controller controller that were built into the model car.

=== Hardware Interfaces ===
The Transmitting Module used the following interfaces:
* I2C Bus
** Used for reading the orientation value from accelerometer sensor
*SPI Bus
** Used for transmit commands from Nordic wireless sensor to receiving board

The Receiving Interface used the following interfaces:
*SPI Bus
** Used for receive commands from Nordic wireless sensor from transmitting board
*GPIO
** Used to read the axle speed from the front and rear
** Used to passing PWM signal to the motor and the servo

=== SJOne ===
[[File:S15_146_G3_IMG_SJOne.png|center]]

=== Servo, Motor & Motor Controller ===
[[File:S15_146_g3_pwmInterfacedElectronics.jpg|460px|center]]

The servo used in this project was a Futaba S3004 and the motor, already built into the model car, was a Leopard Hobby 3300Kv brushless motor. The Castle Sidewinder 3 motor controller and the Futaba servo were both controlled using pulse widths ranging from 1 to 2miliseconds. A width of 1.5 miliseconds was a 0% signal, 1 milisecond was -100%, and 2 miliseconds was +100%. The motor controller included a 5v regulated output, so it was used to power all the electronics on the vehicle.

=== Photo Interrupter ===
[[File:S15_146_G3_IMG_photoInt.png|200px|center]]

The photo interrupters we chose were the Motorola MOC7821. These devices contain an infrared LED and an infrared-controlled transistor. When the gap between the LED and the sensor is open the transistor turns on and allows current to flow, when an object passes through the space between the LED and the sensor the transistor turns off and behaves like an open circuit.

=== Software Design ===

'''Transmitting Module'''

The transmitter first reads the accelerometer data in both the x and y directions and encodes them in an integer. That integer is sent to the vehicle using the Nordic Wireless system.

[[File:S15_146_G3_IMG_flowchart_transmit.png|200px|center]]

'''Receiving Module'''

The SJ One board on the vehicle, waiting to receive data, accepts the integer. The vehicle reads the wheel speeds at the front and rear axle. This is done by reading the signal from the photo interrupters many times in a row and incrementing a counter each time the signal transitions between high and low. One counter holds the number of transitions read from the front axle and the other counter holds the number of transitions at the rear axle and the task determines if the vehicle is in a low traction situation based on the two counter values. The car then translates the encoded command using one of two throttle maps, based on the traction situation, and uses that to set motor speed and servo angle.

[[File:S15_146_G3_IMG_flowchart_receive.png|500px|center]]

=== Implementation ===

'''Accelerometer'''

The built-in sensor that reads the tilt direction of the SJ One board.

*Step 1: Initialize accelerometer sensor.

*Step 2: Read X and Y axis from the sensor and get the orientation of the board.

Read X value:
Function X-axis Range
Forward -200 <= x < 200
Left -500 <= x < -200
Right 200 <= x < 500
Hard Left x >= 500
Hard Right x <= -500

Read Y value:
Num Speed Y-axis Range
0 7.5 -150 <= y < 150
1 7.9 150 <= y < 250
2 8.3 250 <= y < 400
3 8.7 400 <= y < 550
4 9.1 550 <= y < 700
5 9.5 700 <= y < 850
6 9.9 y >= 850

*Step 3: Encode the function and speed number as a single integer and pass them to the wireless task.

'''Nordic Wireless''' (nRF24L01).

The Nordic wireless sensor is built-in on SJOne Board. It used to send and receive data from one SJOne to other. For our project, it is used to send an encoded x and y tilt of the control board to the board on the vehicle. The following steps were taken to implement the Nordic wireless system

*Step 1: Configure the wireless node address and wireless channel number in sys_config.h file. (Make sure both boards have the same channel)

*Step 2: Used mesh_set_node_address() function to set both sending and receiving address. In our project, the car address is set to 300.

*Step 3: On the sending side, it used wireless_send(addr, protocol, data, size of data, max_hops) function to send the data from SJOne board.

*Step 4: On the receiving side, it used wireless_get_rx_pkt() function to catch the data coming from the wireless.

'''Photo Interrupters''' (MOC7821).

[[File:S15_146_G3_IMG_motor.png|500px|left]] [[File:S15_146_G3_IMG_servo.png|460px|center]]

The photo interrupters are used to monitor wheel rotation. An interrupter was mounted around a disk attached to each differential. In the photos above the rear wheel speed sensor assembly and the front wheel speed sensor assembly are on the left and right, respectively. Notches were cut into the disks so that as they spun the outputs of the interrupters would rise and fall. The SJ One board monitored these signals using its GPIO inputs and counted the rising edges over a set period of time to determine the speed of the axle. Being a rear-drive vehicle, the rear axle rotates faster than the front in a slip condition, and the program responds by reducing throttle.

== Testing & Technical Challenges ==

=== Issue #1 ===
The first issue that we ran into involved our implementation of the Nordic wireless system. During the early stages of the project, we wrote and tested our features in separate C or C++ programs. Using the provided libraries and functions, we designed transmitting and receiving programs to test the wireless. During testing, the first packet sent without issue, but any following packets took up to 30 seconds to send. This is because the libraries and functions that we were relying on were designed to be used within the structured FreeRTOS environment. Using them without the work that FreeRTOS does in the background causes them to misbehave.

=== Issue #2 ===
The Motorola MOC7821 photo interrupters that we purchased had very little documentation. We found information about the sensor side of the part, but nothing about the LEDs that make up the infrared emitters. Two of the interrupter's LEDs burnt out before we found the correct dropout voltage and amperage. We recommend that future students obtain access to a variable power supply and test the LEDs by slowly increasing voltage from zero until the dropout voltage is found.

=== Issue #3 ===
This issue was never resolved. Our initial design goal was to implement the timer's capture system so that the rising edges of the photo interrupters' signals could be counted without consuming CPU cycles. The initialization process seemed straightforward but any time we attempted to modify the lower 4 bits of the Counter Control Register it caused an error that triggered a reboot of the system. After many hours of research and guessing no solution was found so we made our own function that, at the price of many CPU cycles, used the GPIO pins to accomplish the same goal.

Any project of this type will encounter roadblocks such as these. These issues, as well as many smaller bugs, were discovered and resolved using frequent testing. Each task was broken down into as small of a block as we could devise a test for. For example, the photo interrupters were tested in four stages. First we tested the sensor side using an infrared television remote. Once we knew the sensor was working we tested the LEDs using an infrared sensitive camera. The whole package was then tested on a bread board, and finally tested again once installed on the model car.

This multi-tiered testing approach was also applied to our software design process. Testing was an integral part of our design and frequent testing helped us to catch bugs sooner and solve them faster by shrinking the amount of code that could be contributing to the problem.

== Conclusion ==

Though this project was ultimately successful, it was a struggle. Poor planning coupled with an injury from a car accident and an untrustworthy online retailer all pushed the timeline for the project. We were severely behind schedule and were able to successfully complete the project by abandoning the "capture" peripheral and placing the load on the CPU by using the GPIO pins. This project taught a lesson in proper scheduling and planning.

However, that was not the only lesson. In our implementation we were forced to execute, in a best case situation, over 500 lines of code in between each command between the transmitter and the receiver. The delay that the extra code caused in the controlling of the vehicle was barely noticeable, and helped us to see just how blazingly fast modern micro controllers actually are. The thought of a micro controller being slower and "less capable" than a computer is, in most cases, incorrect.

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

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]

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

=== References Used ===
http://www.nxp.com/documents/user_manual/UM10360.pdf

http://www.socialledge.com/sjsu/images/d/de/2012SJOneBoardSchematic.pdf

http://www.datasheetspdf.com/PDF/MOC7821/613725/1

http://www.socialledge.com/sjsu/index.php?title=PWM_Motor_Controller_Interface

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

http://www.socialledge.com/sjsu/index.php?title=Low_Powered_Mesh_Network_stack

S15: Motion-Controlled RC Car

2015-05-27T03:06:38Z

146 user3: Undo revision 17695 by 146 user3 (talk)

== Motion-Controlled RC Car ==

[[File:S15_146_G3_IMG_RCcar.jpg|800px|center]]

== Abstract ==
The Motion-Controlled RC Car will allow inexperienced users to drive a high-performance RC vehicle. This is accomplished with a tilt controller, which is more intuitive than a traditional RC transmitter, and a slip-limiting system that will reduce the potential for crashes.

== Objectives & Introduction ==
High performance RC vehicles can be difficult to control because of their immense power and are typically expensive to repair. The goal of this project is to create both a wireless tilt controller and a traction control system for a high-performance RC car. From an engineering standpoint, the project can be broken into three major objectives.

1. Nordic wireless communication

2. Measurement of front and rear axle speed

3. Pulse-width modulated control of motor and servo

=== Team Members & Responsibilities ===

* Shangming Wang - Mesh Communication, Report writing, testing

* Daniel Khawaja - Wheel speed capture, RC car maintenance, PWM

== Schedule ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Completion Date
|-
! scope="row"| 0
| 4/10
| 4/24
| Obtain Hall sensors
| Not Completed
| ---
|-
! scope="row"| 1
| 4/20
| 4/27
| Find PWM parameters, Test mesh communication
| Completed
| PWM: 4/27 Mesh: 5/4
|-
! scope="row"| 2
| 4/27
| 5/4
| Implement PWM control, Finalize mesh communication, Obtain photo interrupters
| Completed
| PWM: 5/4 Mesh: 5/13 Photo: 5/14
|-
! scope="row"| 3
| 5/4
| 5/11
| Implement motion control, Modify RC for 2wd and mount wheel speed sensors
| Completed
| Motion: 5/13 Modification: 5/15
|-
! scope="row"| 4
| 5/11
| 5/18
| Finish wheel speed capture, Test and polish traction control parameters
| Completed
| Capture: 5/23 T.C.: 5/25

|-
! scope="row"| 5
| 5/18
| 5/25
| Implement extra features
| Not Completed
| ---
|}

== Parts List & Cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="60" align="center"|Total Cost
|-
| align="center"|50||Jumper Wires||align="right"|$3.00
|-
| align="center"|1||Prototype Board||align="right"|$1.00
|-
| align="center"|1||Turnigy 500mAh Battery||align="right"|$40.00
|-
| align="center"|2||Wireless Antenna||align="right"|$6.00
|-
| align="center"|1||Remote Control Car||align="right"|$150.00
|-
| align="center"|2||SJOne Board||align="right"|$160.00
|-
| align="center"|2||Motorola MOC7821 Photo Interrupter||align="right"|$4.00
|-
| ||Total Cost '''||align="right"|$364'''
|-
|}

== Design & Implementation ==

=== Hardware Design ===

[[File:S15_146_G3_IMG_1.png|400px|center]]

A high-level schematic of the electronics involved in this project

Our hardware design began with connecting the Sj-One board with the servo and motor controller controller that were built into the model car.

=== SJOne ===
[[File:S15_146_G3_IMG_SJOne.png|center]]

=== Servo, Motor & Motor Controller ===
[[File:S15_146_g3_pwmInterfacedElectronics.jpg|460px|center]]

The servo used in this project was a Futaba S3004 and the motor, already built into the model car, was a Leopard Hobby 3300Kv brushless motor. The Castle Sidewinder 3 motor controller and the Futaba servo were both controlled using pulse widths ranging from 1 to 2miliseconds. A width of 1.5 miliseconds was a 0% signal, 1 milisecond was -100%, and 2 miliseconds was +100%. The motor controller included a 5v regulated output, so it was used to power all the electronics on the vehicle.

=== Photo Interrupter ===
[[File:S15_146_G3_IMG_photoInt.png|200px|center]]

The photo interrupters we chose were the Motorola MOC7821. These devices contain an infrared LED and an infrared-controlled transistor. When the gap between the LED and the sensor is open the transistor turns on and allows current to flow, when an object passes through the space between the LED and the sensor the transistor turns off and behaves like an open circuit.

=== Hardware Interface ===
The Transmitting Module used the following interfaces:
* I2C Bus
** Used for reading the orientation value from accelerometer sensor
*SPI Bus
** Used for transmit commands from Nordic wireless sensor to receiving board

The Receiving Interface used the following interfaces:
*SPI Bus
** Used for receive commands from Nordic wireless sensor from transmitting board
*GPIO
** Used to read the axle speed from the front and rear
** Used to passing PWM signal to the motor and the servo

=== Software Design ===

'''Transmitting Module'''

The transmitter first reads the accelerometer data in both the x and y directions and encodes them in an integer. That integer is sent to the vehicle using the Nordic Wireless system.

[[File:S15_146_G3_IMG_flowchart_transmit.png|200px|center]]

'''Receiving Module'''

The SJ One board on the vehicle, waiting to receive data, accepts the integer. The vehicle reads the wheel speeds at the front and rear axle. This is done by reading the signal from the photo interrupters many times in a row and incrementing a counter each time the signal transitions between high and low. One counter holds the number of transitions read from the front axle and the other counter holds the number of transitions at the rear axle and the task determines if the vehicle is in a low traction situation based on the two counter values. The car then translates the encoded command using one of two throttle maps, based on the traction situation, and uses that to set motor speed and servo angle.

[[File:S15_146_G3_IMG_flowchart_receive.png|500px|center]]

=== Implementation ===

'''Accelerometer'''

The built-in sensor that reads the tilt direction of the SJ One board.

*Step 1: Initialize accelerometer sensor.

*Step 2: Read X and Y axis from the sensor and get the orientation of the board.

Read X value:
Function X-axis Range
Forward -200 <= x < 200
Left -500 <= x < -200
Right 200 <= x < 500
Hard Left x >= 500
Hard Right x <= -500

Read Y value:
Num Speed Y-axis Range
0 7.5 -150 <= y < 150
1 7.9 150 <= y < 250
2 8.3 250 <= y < 400
3 8.7 400 <= y < 550
4 9.1 550 <= y < 700
5 9.5 700 <= y < 850
6 9.9 y >= 850

*Step 3: Encode the function and speed number as a single integer and pass them to the wireless task.

'''Nordic Wireless''' (nRF24L01).

The Nordic wireless sensor is built-in on SJOne Board. It used to send and receive data from one SJOne to other. For our project, it is used to send an encoded x and y tilt of the control board to the board on the vehicle. The following steps were taken to implement the Nordic wireless system

*Step 1: Configure the wireless node address and wireless channel number in sys_config.h file. (Make sure both boards have the same channel)

*Step 2: Used mesh_set_node_address() function to set both sending and receiving address. In our project, the car address is set to 300.

*Step 3: On the sending side, it used wireless_send(addr, protocol, data, size of data, max_hops) function to send the data from SJOne board.

*Step 4: On the receiving side, it used wireless_get_rx_pkt() function to catch the data coming from the wireless.

'''Photo Interrupters''' (MOC7821).

[[File:S15_146_G3_IMG_motor.png|500px|left]] [[File:S15_146_G3_IMG_servo.png|460px|center]]

The photo interrupters are used to monitor wheel rotation. An interrupter was mounted around a disk attached to each differential. In the photos above the rear wheel speed sensor assembly and the front wheel speed sensor assembly are on the left and right, respectively. Notches were cut into the disks so that as they spun the outputs of the interrupters would rise and fall. The SJ One board monitored these signals using its GPIO inputs and counted the rising edges over a set period of time to determine the speed of the axle. Being a rear-drive vehicle, the rear axle rotates faster than the front in a slip condition, and the program responds by reducing throttle.

== Testing & Technical Challenges ==

=== Issue #1 ===
The first issue that we ran into involved our implementation of the Nordic wireless system. During the early stages of the project, we wrote and tested our features in separate C or C++ programs. Using the provided libraries and functions, we designed transmitting and receiving programs to test the wireless. During testing, the first packet sent without issue, but any following packets took up to 30 seconds to send. This is because the libraries and functions that we were relying on were designed to be used within the structured FreeRTOS environment. Using them without the work that FreeRTOS does in the background causes them to misbehave.

=== Issue #2 ===
The Motorola MOC7821 photo interrupters that we purchased had very little documentation. We found information about the sensor side of the part, but nothing about the LEDs that make up the infrared emitters. Two of the interrupter's LEDs burnt out before we found the correct dropout voltage and amperage. We recommend that future students obtain access to a variable power supply and test the LEDs by slowly increasing voltage from zero until the dropout voltage is found.

=== Issue #3 ===
This issue was never resolved. Our initial design goal was to implement the timer's capture system so that the rising edges of the photo interrupters' signals could be counted without consuming CPU cycles. The initialization process seemed straightforward but any time we attempted to modify the lower 4 bits of the Counter Control Register it caused an error that triggered a reboot of the system. After many hours of research and guessing no solution was found so we made our own function that, at the price of many CPU cycles, used the GPIO pins to accomplish the same goal.

Any project of this type will encounter roadblocks such as these. These issues, as well as many smaller bugs, were discovered and resolved using frequent testing. Each task was broken down into as small of a block as we could devise a test for. For example, the photo interrupters were tested in four stages. First we tested the sensor side using an infrared television remote. Once we knew the sensor was working we tested the LEDs using an infrared sensitive camera. The whole package was then tested on a bread board, and finally tested again once installed on the model car.

This multi-tiered testing approach was also applied to our software design process. Testing was an integral part of our design and frequent testing helped us to catch bugs sooner and solve them faster by shrinking the amount of code that could be contributing to the problem.

== Conclusion ==

Though this project was ultimately successful, it was a struggle. Poor planning coupled with an injury from a car accident and an untrustworthy online retailer all pushed the timeline for the project. We were severely behind schedule and were able to successfully complete the project by abandoning the "capture" peripheral and placing the load on the CPU by using the GPIO pins. This project taught a lesson in proper scheduling and planning.

However, that was not the only lesson. In our implementation we were forced to execute, in a best case situation, over 500 lines of code in between each command between the transmitter and the receiver. The delay that the extra code caused in the controlling of the vehicle was barely noticeable, and helped us to see just how blazingly fast modern micro controllers actually are. The thought of a micro controller being slower and "less capable" than a computer is, in most cases, incorrect.

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

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]

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

=== References Used ===
http://www.nxp.com/documents/user_manual/UM10360.pdf

http://www.socialledge.com/sjsu/images/d/de/2012SJOneBoardSchematic.pdf

http://www.datasheetspdf.com/PDF/MOC7821/613725/1

http://www.socialledge.com/sjsu/index.php?title=PWM_Motor_Controller_Interface

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

http://www.socialledge.com/sjsu/index.php?title=Low_Powered_Mesh_Network_stack

S15: Motion-Controlled RC Car

2015-05-27T03:02:24Z

146 user3: /* Software Design */

== Motion-Controlled RC Car ==

[[File:S15_146_G3_IMG_RCcar.jpg|800px|center]]

== Abstract ==
The Motion-Controlled RC Car will allow inexperienced users to drive a high-performance RC vehicle. This is accomplished with a tilt controller, which is more intuitive than a traditional RC transmitter, and a slip-limiting system that will reduce the potential for crashes.

== Objectives & Introduction ==
High performance RC vehicles can be difficult to control because of their immense power and are typically expensive to repair. The goal of this project is to create both a wireless tilt controller and a traction control system for a high-performance RC car. From an engineering standpoint, the project can be broken into three major objectives.

1. Nordic wireless communication

2. Measurement of front and rear axle speed

3. Pulse-width modulated control of motor and servo

=== Team Members & Responsibilities ===

* Shangming Wang - Mesh Communication, Report writing, testing

* Daniel Khawaja - Wheel speed capture, RC car maintenance, PWM

== Schedule ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Completion Date
|-
! scope="row"| 0
| 4/10
| 4/24
| Obtain Hall sensors
| Not Completed
| ---
|-
! scope="row"| 1
| 4/20
| 4/27
| Find PWM parameters, Test mesh communication
| Completed
| PWM: 4/27 Mesh: 5/4
|-
! scope="row"| 2
| 4/27
| 5/4
| Implement PWM control, Finalize mesh communication, Obtain photo interrupters
| Completed
| PWM: 5/4 Mesh: 5/13 Photo: 5/14
|-
! scope="row"| 3
| 5/4
| 5/11
| Implement motion control, Modify RC for 2wd and mount wheel speed sensors
| Completed
| Motion: 5/13 Modification: 5/15
|-
! scope="row"| 4
| 5/11
| 5/18
| Finish wheel speed capture, Test and polish traction control parameters
| Completed
| Capture: 5/23 T.C.: 5/25

|-
! scope="row"| 5
| 5/18
| 5/25
| Implement extra features
| Not Completed
| ---
|}

== Parts List & Cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="60" align="center"|Total Cost
|-
| align="center"|50||Jumper Wires||align="right"|$3.00
|-
| align="center"|1||Prototype Board||align="right"|$1.00
|-
| align="center"|1||Turnigy 500mAh Battery||align="right"|$40.00
|-
| align="center"|2||Wireless Antenna||align="right"|$6.00
|-
| align="center"|1||Remote Control Car||align="right"|$150.00
|-
| align="center"|2||SJOne Board||align="right"|$160.00
|-
| align="center"|2||Motorola MOC7821 Photo Interrupter||align="right"|$4.00
|-
| ||Total Cost '''||align="right"|$364'''
|-
|}

== Design & Implementation ==

=== Hardware Design ===

[[File:S15_146_G3_IMG_1.png|400px|center]]

A high-level schematic of the electronics involved in this project

Our hardware design began with connecting the Sj-One board with the servo and motor controller controller that were built into the model car.

=== SJOne ===
[[File:S15_146_G3_IMG_SJOne.png|center]]

=== Servo, Motor & Motor Controller ===
[[File:S15_146_g3_pwmInterfacedElectronics.jpg|460px|center]]

The servo used in this project was a Futaba S3004 and the motor, already built into the model car, was a Leopard Hobby 3300Kv brushless motor. The Castle Sidewinder 3 motor controller and the Futaba servo were both controlled using pulse widths ranging from 1 to 2miliseconds. A width of 1.5 miliseconds was a 0% signal, 1 milisecond was -100%, and 2 miliseconds was +100%. The motor controller included a 5v regulated output, so it was used to power all the electronics on the vehicle.

=== Photo Interrupter ===
[[File:S15_146_G3_IMG_photoInt.png|200px|center]]

The photo interrupters we chose were the Motorola MOC7821. These devices contain an infrared LED and an infrared-controlled transistor. When the gap between the LED and the sensor is open the transistor turns on and allows current to flow, when an object passes through the space between the LED and the sensor the transistor turns off and behaves like an open circuit.

=== Hardware Interface ===
The Transmitting Module used the following interfaces:
* I2C Bus
** Used for reading the orientation value from accelerometer sensor
*SPI Bus
** Used for transmit commands from Nordic wireless sensor to receiving board

The Receiving Interface used the following interfaces:
*SPI Bus
** Used for receive commands from Nordic wireless sensor from transmitting board
*GPIO
** Used to read the axle speed from the front and rear
** Used to passing PWM signal to the motor and the servo

=== Software Design ===

'''Transmitting Module'''

The transmitter first reads the accelerometer data in both the x and y directions and encodes them in an integer. That integer is sent to the vehicle using the Nordic Wireless system.

[[File:S15_146_G3_IMG_flowchart_transmit.png|200px|center]]

'''Receiving Module'''

The SJ One board on the vehicle, waiting to receive data, accepts the integer. The vehicle reads the wheel speeds at the front and rear axle. This is done by reading the signal from the photo interrupters many times in a row and incrementing a counter each time the signal transitions between high and low. One counter holds the number of transitions read from the front axle and the other counter holds the number of transitions at the rear axle and the task determines if the vehicle is in a low traction situation based on the two counter values. The car then translates the encoded command using one of two throttle maps, based on the traction situation, and uses that to set motor speed and servo angle.

[[File:S15_146_G3_IMG_flowchart_receive.png|500px|center]]

=== Software Design ===

'''Transmitting Module'''

The transmitter first reads the accelerometer data in both the x and y directions and encodes them in an integer. That integer is sent to the vehicle using the Nordic Wireless system.

[[File:S15_146_G3_IMG_flowchart_transmit.png|200px|center]]

'''Receiving Module'''

The SJ One board on the vehicle, waiting to receive data, accepts the integer. The vehicle reads the wheel speeds at the front and rear axle. This is done by reading the signal from the photo interrupters many times in a row and incrementing a counter each time the signal transitions between high and low. One counter holds the number of transitions read from the front axle and the other counter holds the number of transitions at the rear axle and the task determines if the vehicle is in a low traction situation based on the two counter values. The car then translates the encoded command using one of two throttle maps, based on the traction situation, and uses that to set motor speed and servo angle.

[[File:S15_146_G3_IMG_flowchart_receive.png|500px|center]]

== Testing & Technical Challenges ==

=== Issue #1 ===
The first issue that we ran into involved our implementation of the Nordic wireless system. During the early stages of the project, we wrote and tested our features in separate C or C++ programs. Using the provided libraries and functions, we designed transmitting and receiving programs to test the wireless. During testing, the first packet sent without issue, but any following packets took up to 30 seconds to send. This is because the libraries and functions that we were relying on were designed to be used within the structured FreeRTOS environment. Using them without the work that FreeRTOS does in the background causes them to misbehave.

=== Issue #2 ===
The Motorola MOC7821 photo interrupters that we purchased had very little documentation. We found information about the sensor side of the part, but nothing about the LEDs that make up the infrared emitters. Two of the interrupter's LEDs burnt out before we found the correct dropout voltage and amperage. We recommend that future students obtain access to a variable power supply and test the LEDs by slowly increasing voltage from zero until the dropout voltage is found.

=== Issue #3 ===
This issue was never resolved. Our initial design goal was to implement the timer's capture system so that the rising edges of the photo interrupters' signals could be counted without consuming CPU cycles. The initialization process seemed straightforward but any time we attempted to modify the lower 4 bits of the Counter Control Register it caused an error that triggered a reboot of the system. After many hours of research and guessing no solution was found so we made our own function that, at the price of many CPU cycles, used the GPIO pins to accomplish the same goal.

Any project of this type will encounter roadblocks such as these. These issues, as well as many smaller bugs, were discovered and resolved using frequent testing. Each task was broken down into as small of a block as we could devise a test for. For example, the photo interrupters were tested in four stages. First we tested the sensor side using an infrared television remote. Once we knew the sensor was working we tested the LEDs using an infrared sensitive camera. The whole package was then tested on a bread board, and finally tested again once installed on the model car.

This multi-tiered testing approach was also applied to our software design process. Testing was an integral part of our design and frequent testing helped us to catch bugs sooner and solve them faster by shrinking the amount of code that could be contributing to the problem.

== Conclusion ==

Though this project was ultimately successful, it was a struggle. Poor planning coupled with an injury from a car accident and an untrustworthy online retailer all pushed the timeline for the project. We were severely behind schedule and were able to successfully complete the project by abandoning the "capture" peripheral and placing the load on the CPU by using the GPIO pins. This project taught a lesson in proper scheduling and planning.

However, that was not the only lesson. In our implementation we were forced to execute, in a best case situation, over 500 lines of code in between each command between the transmitter and the receiver. The delay that the extra code caused in the controlling of the vehicle was barely noticeable, and helped us to see just how blazingly fast modern micro controllers actually are. The thought of a micro controller being slower and "less capable" than a computer is, in most cases, incorrect.

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

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]

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

=== References Used ===
http://www.nxp.com/documents/user_manual/UM10360.pdf

http://www.socialledge.com/sjsu/images/d/de/2012SJOneBoardSchematic.pdf

http://www.datasheetspdf.com/PDF/MOC7821/613725/1

http://www.socialledge.com/sjsu/index.php?title=PWM_Motor_Controller_Interface

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

http://www.socialledge.com/sjsu/index.php?title=Low_Powered_Mesh_Network_stack