Group 5: Dylan Dean, Dan Galy, Jake Anderson, Alec Vozzy

Justin O’KayApril 3, 2014

Group 5: Dylan Dean, Dan Galy, Jake Anderson, Alec Vozzy

Remote Box/Wireless Transceivers /Wave Shield/Display Screen

Group Task

Group five is assigned with the task to make a short range vehicle control for an electric car. This goal is split into two tasks an “a” and a “b” task. Task a is to make a display parking procedure for the driver. Task b is to implement an automotive parking system.

Week Objectives

The goal for this week was to finish the necessary adjustments for the remote box so that the wave shield, display screen, and wireless transceivers would have a solid platform to hold them. Once the platform was completed the wave shield, display screen, three buttons and wireless transceiver could be wired up and coded so that the remote box would have all the necessary systems to completing task “a”.

Problems Encountered Individual Systems

Remote Box

Minor adjustments to the size of the screw holes, and screen cutout, were made to the cover plate for the remote box. Small adjustments box was printed twice, second box was made to work. The bottom box is designed to hold the 3” speaker and battery to power the remote. This box was printed by the maker bot and not adjustments were made to the box since completion. The middle box has had four attempts to be printed, the first attempt screw holes and other cutouts were found to be small. Adjustments were made in auto cad to correct this. Printing was attempted three more times with the maker bot were allfiles had errors with corners lifting or maker bot shifting the build over about 3 cm. Middle box of the remote with adjustments was put on hold due to maker bot issue that needs to be resolved. Also due to the combination of the systems the adjustments are also on idle until the coding catches up.

Wireless Transceivers

At the start of this week the wireless transceiver examples were running. The libraries from the Arduino website were downloaded and added, all the example files complied. We started by taking two Arduino Uno’s and uploading and example file on each one. One file was used to send data and the other to receive and send a message that the data was received correctly back to the sender. The code was very understandable and straight forward to work with, when only the transceiver was connected to the Arduino board. When other systems were added the Arduino would get somewhat confused with which device to send information.

Wave Shield

The wave shield as designed, sits on top of all the pins to the Arduino Uno. The design of the remote more than one system has to be put onto the Arduino board. First we pulled off the shield and wired up the pins that are required to run the wave shield. We found that the essential pins were 13, 12, 11, 10, 5, 4, 3, 2, and the ground (This is in addition to the power or ground for the board). Also because the wave shield is not an Arduino base product although compatible with Arduino it was difficult to find help with the pins layouts. Due to other conflicts we shifted to an Arduino mega which is completely different pin layout for the wave shield. It was later found that not only were the pins different that the wave shield is not designed for the mega board.

Display Screen

The display screen was found to be very versatile when we moved it from board to board it was able to run the code that was designed for it specifically. When the display screen was put with the wireless transceiver the Arduino board was having some difficulty with the SPI with the two systems.

Problems Encountered Combining Systems

The first attempt was to connect all the systems in parallel with the on and Arduino Uno. After the construction was complete each system was tested to see if it was working by running each systems individual codes one the new circuit. It was found that only two systems would work together at one time. It was either the display screen and the wireless transceiver, or the wave shield and the wireless transceiver. At this point we shifted designs and moved all the systems over to a mega board, having more pins we were able to separate systems from using the same pins and only having to use common SPI pins. This worked for running the display screen and the wireless transceiver but the wave shield never designed for this board. Again we shifted gears to find a way to mesh all the systems so they will work together. Knowing that all the systems worked individually on and Uno we decided that it may work splitting the systems onto two Arduino boards the sound shield on one and the display screen and wireless transceiver on the other.

Future

Where we sit right now is that wireless transceivers work. Data can be sent from one to the other where we can activate if statements. This will allow us to press a button that will send over a signal that will put the car into parallel park, back up, turn left, turn right, motions. Though there is still some work to be done putting all three systems together onto one platform for the remote. There is also a lot of work to be done combining the two systems so that they can work on one board or so that they can work on two boards which can communicate with one another. This way task “a” will be completed.

Dylan Dean

Sr. Design Progress report week 11.

This week the model car portion of the senior design project was altered to allow for different Arduino microcontrollers to be used to interface with the sensors.

There was a significant amount of time spent changing the Arduino board that controls the car. The Arduino Mega board was originally intended to control the car. However, some testing was done with the remote that required the Arduino Mega. Without the Mega, changes were made to the parking code and ultrasonic sensors. The Arduino Mega was replaced with an Arduino uno for the model control. The sensors were changed to analog output due to the lack of pulse width modulation pins on the Arduino uno. When the code was altered to accommodate the Arduino uno, it was found that the remote could be altered to use an Arduino uno to operate. So, the decision was made to switch the Arduino Mega back to the model car controller. However, due to the alteration of the sensor configuration, it made more sense to change the code than re-solder the sensors. With these changes, the structure of the code to take sensor input and respond with motor output is also changed.

The code now, using analog pins, must take several inputs and average them. This aspect of using analog pins will slow down the processing time slightly for the program, which will in turn slow the speed of the car. The car needed to be slowed down some originally so this is one advantage of the new code structure.

In the coming week, all members of the group have several tests. So progress may be slow for the coming week. However, the group goals are clear for the project, for the coding especially. First, the code to parallel park the car will be organized into its own void loop, which will be called by the remote interface. The idea is that the car will be placed near where it will park, then with a cue from the remote the parking void loop will be triggered. The car will read all of the sensors to make sure that it is safe to go forward and reverse. Then the side sensors will be checked to make sure that the vehicle is close enough to the object is needs to pull up next to, to park. If those readings are satisfied the car will pull forward until it loses the signal of the object alongside it. At which point the car will pull forward and attempt to sense the other object that it will attempt to park next to. When this object is sensed the vehicle will stop briefly, the wheels will be turned toward the object, and the vehicle will reverse for a specified amount of time or until it senses that the object behind it is too close. When it reaches this point, the wheels will be turned the other way and will be moved forward until the front and rear sensors are an acceptable distance away from the objects that it is to park between, or both front and rear sensors read the same distance value. At which point the car will stop and the void loop will continue to cycle but the car will be stopped and the parking sequence will be completed.

If this parking sequence is able to be successfully coded and tested, the model will be a success. After this point the process for the installation of the parking assist in the car will be determined. As well as whether the code can be altered to interface with the steering, speed, and safety controls that may or may not be in place from the other groups.

Progress Report: (Dan Galy)

The goal for this week was to link the Arduino TFT screen, the wave Arduino sound shield, and both of the Addicore transmitters to all work together. We wanted to link all of these systems so that the user could pick up the remote, view the TFT screen, use buttons to choose the type of parking desired, listen to the audio guide the user through the process, and transmit the signal to the car so that the car will choose the appropriate method to park. In order to make all of these devices work together a new protocol for data transmission needed to be researched. This protocol is called Serial Peripheral Interfacing. This subjected was researched in depth and the overview can be seen next in this work.

Overview of SPI interfacing:

SPI stands for serial peripheral interfacing and is used to synchronously send data serially. This process is utilized for devices that utilize EEPROM.

SPI requires the use of four functions: MISO, MOSI, SCK, and SS. They are defined as follows:

MISO(Master In Slave Out) - The Slave line for sending data to the master,

MOSI(Master Out Slave In) - The Master line for sending data to the peripherals,

SCK(Serial Clock) - The clock pulses which synchronize data transmission generated by the master and one line specific for every device:

SS(Slave Select) - the pin on each device that the master can use to enable and disable specific devices.

When a SS is LOW, it communicates with the master.

When a SS is HIGH, it ignores the master.

***This is what allows you have multiple devices sharing the same MISO, MOSI, and CLK lines***

Things that need to be known before setting up an SPI system:

Is the data shifted in MSB or LSB first? (This is controlled by SPI.setBitOrder() )

Is the data clock idle when HIGH or LOW? (Controlled by SPI.setDataMode() )

May be called clock polarity

Are samples on the rising or falling edge of clock pulses? (Controlled by SPI.setDataMode() )

Rising or falling edge may be called clock phase

Four modes set with SPI.setDataMode()

The clock speed must be adjusted also if the default is not correct (4Mhz). This can be set using SPI.setClockDivider().

Using the SPI protocol:

Each of the devices requires a direct connection to: MOSI, MISO, SCK, and SS pins. The idea is to allocate time for each of the devices to transmit data. A succinct explanation of what our trials was that we have yet to successfully connect all of these devices together on one Arduino board. Our first attempts were with an Arduino Mega 2560. The problem with the mega was that the sound board was not configured to work with this board. There were many discussions online that described how to set up the sound board with the mega however we were not able to get them to work. The problem the shield had was that the data transmission for the device was never configured to work with the Mega. The reason that we were trying to use the mega was for the number of pins. The Uno simply did not have enough pins for us to use all three devices with it. Another problem with the sound shield was that it did not have proper documentation to describe the proper wiring when not attached to an Uno. Normally the shield takes all of the pins of the Uno, in our case we wanted to utilize as many pins as possible for other devices. The process that we understood to discover which pins were required was to wire every pin to the device and simply take them off one by one and testing the system for functionality. The final diagram can be seen as follows:

Pins13, 12, 11were used for SPI protocol. The other pins were 2, 3, 4, and 5for the DAC and pin 10 for the SD card. In addition to these an optional pin was discovered that could be used for using the DAC to sample which was pin 1. The final pin that gave us trouble was just a simple ground. The shield requires two ground pins one on the left and one located on the right hand side of the board.

After the discovery that there were too many devices to hook up to one UNO and the sound shield did not work with the MEGA we decided we would have to use an UNO just for the sound shield and one UNO for the transmitters and the TFT screen. We already knew that the sound shield worked fine with a single UNO and each device did as well so we then attempted to use the transmitters along with the TFT. We were able to get the two of them to work at the same time however we have yet to get the SPI protocol to enable proper data transmission. We wanted to have the screen print out the alongside the transmitters. The screen did work at initialization however once data had been received from the transmitter the data needed to be sent to the screen became unusable.

The transmitters were a complete success however. We discovered how to send data transmissions of virtually any type and of significant length. For our purposes three bytes of data allows 128 different types of signals and an accurate method to determine if information has been corrupted. Since we were unable to get the SPI protocol to work as of yet for the transmitter and TFT on one UNO we decided in order to accomplish a task of having a remote control parking system we would get the system to work without the TFT. We configured a “Proof of Concept,” for this setup. For the final setup we configured the two transmiters, one acting as client and one acting as server. The client would call the server with a message, a simple byte of information. This byte of information was an ASCII encoded character that corresponded to the LED’s attached to the server. The client would send a ‘O’ for orange or an ‘R’ for red. The server code would total three bytes and verify that the total would equal three times the ASCII code for either of the characters. If the correct message was received then the server would power an LED with the same color. This proof of concept shows that a signal can be sent to initialize a parking sequence. The code for this can be seen as follows and picture of the final setup: