First print cover, problem corner lifted. First print bottom

Justin O’Kay April 3, 2014Group 5: Dylan Dean, Dan Galy, Jake Anderson, Alec Vozzy

Remote Box/Wireless Transceivers /Wave Shield/Display ScreenGroup 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 all files 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.

1

Third print Middle box, problem corner lifted.

Forth print Middle box, maker bot shifted about 3 cm on build

Wireless transceivers receiving data and turning LED lights on and off.

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.

2

Wave ShieldThe 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 ScreenThe 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.

3

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

4

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.

5

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

6

Daniel Galy Group 5 Senior Design

SN 333719

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:

Pins 13, 12, 11 were used for SPI protocol. The other pins were 2, 3, 4, and 5 for 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

7

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:

8

MakerBot Problems:

The week started with trying to finish up utilizing the MakerBot© to build the remote control case. We ran into some more problems with the print. The print was coming out in stair cases which created a completely unusable build. According to online references, this could be the result of one of the following:

The filament fan nozzle dropped or print lifted The x movement rod became jammed The belt has been damaged The stepper motor cable is damaged

Each of these will be checked out and followed up before the week is done.

Website design:

A final note on the website. I am still awaiting email from OIT so that the website can be created. I will be getting in touch with SAS to put pressure on the subject.

9

Jacob Anderson

Senior Design Report

4-3-2014

Objectives:

The Plans for this week were to get the wireless communication working and to clean up the car a bit and work on the ultrasonic sensors for the DC motors. Alec and Dylan were to work together on the sensors and clean up the car a bit, Justin and Dan were to work on the remote box this week and to also get the wireless communication “talking” to each other. My task was to help who needs help and to get all the files together and organized.

Progress:

I attempted to help Dan and Justin with the wireless communication, so that the car and the remote can “talk” to each other to control the parking even if you’re not in the car. I started asking questions and to see how far they got. I then started to look at their code and saw that it had several subfolders that it called on and I thought this could have been part of the problem; that the code was too complicated and possibly could find an easier one. I then started doing some research to try and help Justin and Dan. I did not want to help them with their current code and set-up because they have been working for some time and knew it better than me, so I don’t think it would have been a good use of my time. After a little bit of research I found that there wasn’t any other libraries that were more efficient, so I then helped them a little, but felt that three was a crow for the task at hand so then I went on and started getting all the files together that were missing from the shared dropbox folder.

I tracked down all the files for the H-Bridge, DC motors and Sensors that will be needed for future classes to reference off of. Then I rearranged all the files in the dropbox because this late in the semester files were not well organized and all over the place. I also included a file of the Car and all the wires. I used Microsoft Vizio to make a diagram and show how the ultrasonic sensors, DC motors, Power Supply, and Arduino Uno are hooked up.

Plans:

My plans for next week are pretty simple. Once Justin and Dan get the wireless communication working then the remote will need to be assembled. I will have to do all the soldering and assembly of the remote, with the help of Dan and Justin for reference. A lot of buttons, wires, and components will need to be put in place. Once this is done I will have to make a wire diagram of the remote, so that future classes can look back and reference it in the future. I was told by Justin and Dan that it will take a lot of time to complete this. I was

10

supposed to do it this week, but some snags held up Justin and Dan on the wireless communication portion of the remote. But we can make up time next week if I get all my part of the work done early in the week and I can hand it back off to the guys and start helping them program it for the final stages to park itself!

11

Alec VozzyProgress Report Week 6

This week as a group we hit a rough patch with what micro controllers to use. Dan and Justin were going to switch to the Mega, since we only have one Mega I took the Uno and implemented the Uno to work with four ultrasonic sensors. There was a challenge in switching to the Uno from the Mega. The Uno does not have enough PWM pins for the sensors and the H-Bridge. The way I got around this problem is I switched the sensors from PWM to Analog. This frees up all the PWM and digital pins to be used for the H-bridge. Analog works a little differently from the PWM method; the analog method has a voltage output from the bounce back from an object. I had to convert this voltage to a distance using a scale factor. The scale factor is (Vcc/512) per inch. A 5V supply yields ~9.8mV/in, also the Arduino analog pin goes from 0 to 1024, so the value has to be divided by 2 to get the actual inches. This conversion factor will give us a value for the voltage in terms of distance. To get the value I first created a for loop that would take the average of readings with 60 samples. This for loop would run 60 times while adding previous values and taking the average and summing it from previous results. The result would be a distance in inches; Figure 1 shows this For loop.

Figure 1: For loop of analog sensorsThis method is a little slower than the PWM method but it will work just as good. After the for

loop I convert the sum values into a distance value, once this is done the sums must be reset to grab another reading from the sensors. Figure 2 shows the conversion to inches and the sum being reset at the end of the code. I can speed up the loop by changing the delays in the for loop, I only experimented with this a little bit and will try different delays following this week. After I had a code that measured the distance with the analog option I implemented it to the combo code. This required me to change some pin layouts and adding to the for loops.

12

Figure 2: Conversion to Inches and Reset of sum

Figure 3 shows the new pin layouts of the variable to work on the uno. This wasn’t hard and it was very easy to implement into the code. I then reset the sums at the end of the code but without realizing this set up for a potential failure, and that potential failure turned into an actual failure in the system. The car would work fine when I was testing but if I didn’t touch the system for a while it would start to do the last action it was told to do. For example I would put my hand on the back sensor and it would correct itself and go forward thinking that it was about to back into something. Once I took my hand off the sensor it would stop then it would go and not stop at all. I realized that the problem was the sum values. I was only resetting the values at the end of code in the void loop. This was problem because if the code went into another for loop it would sum the numbers and keep those values and not rest. I fixed this by resetting the sum values in each for loop. This can be seen in Figure 4 where the for loop to have the car move forward, at the end of the loop you can see that I reset the sum values.

Figure 3: New Pin Layout for the Uno Figure 4: For loop with sum reset

13

After making the code work for the Uno Justin and Dan decided that they did not need the mega for what they were doing after they worked with it more. We will be using the Mega again but this week’s work was not a total waste of time. Now when we use the mega we freed up space on the PWM and digital pins to use for the H-bridge. I also have the sensor covers redesigned in AutoCad to make it easier to transfer over to the maker bot. Justin and I will print out on prototype to make sure that the measurements are correct before we print all four sensor covers for a final product all at once.

Next week I will be working on getting the car turning with the analog inputs and slowing down the speed of the car to make the readings from the sensors more accurate and obtaining good data from the sensors. This will also bring up a challenge of hooking the sensors to the car with a more reliable system. This is where the sensor covers will come in and also I plan on raising the sensors up from the car so the sensors will not get readings from the floor.

14