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

Sound ShieldGroup 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.

Individual Task

I am currently working on task a. This task was split into two parts. Part one is to make a visual display for the driver, and part two is to include sound. By the completion for these two parts the driver will have a visual and audio interface for the automotive parking system. I am currently working on part two of task a.

Current Audio Standing

To implement the audio for task a, an Arduino sound shield was selected to be used. After last week sound was able to be produced by the shield, the group decided that more options for sound would be beneficial. One option that he group choose for sound output would be based on distance from another object. Currently the shield currently says “Please Start the car and put it in reverse” even though that does not make logical since for an sound output, with proximity to an object like another car the fact that sound was produced with the input from the range sensors was a nice achievement. Now that sound and range are combined within the same code the sound output can be altered or adjusted to anything the group decides. To accomplish this, I worked with another member of the group who was working on the range sensors which reads in and out distances. We managed this through the use of an Arduino Uno. Although this is not permanent for the overall project, it is only for testing that the Arduino Uno was used.

Future

For this upcoming week the other group members and I are going to try to overcome some of the problems that we faced interfacing the range sensors and sound systems with the mega. Some issues that were caused came from the sound shield being switched from the Uno to the mega. The range sensors were coded with both the Uno and mega, for they only use one pin besides the power and ground pins which allowed them to be fairly compatible to switch boards. When both systems were brought together on the mega there was an error with the shield coding. The problem with the sound shield is thought to be with the pins. When switching from the Uno to the mega the pins do not line up. This is the first problem that has to be fixed in the upcoming

week. When doing some trouble shooting this week we eliminated some variables by hooking everything up to the Uno that was used to run the sound shield. It was found that the combined code for sound and sensors work perfectly. Knowing that there was no problems with the code, shield, or sensors we concluded that there was a problem with the interfacing the two systems on the mega.

Another task that needs to be done to finalize implementing the sound is getting enough small size sound files that can be used construed a message for the driver depending on the driver’s performance with parking. This will allow the audio to be able to adapt too many situations based on how the car is positioned simply by linking the audio files together. The group still has to decide on when the opportune time to send out a sound will be so that the driver is not distracted or startled, when driving the car. Also there is a 3’’ diameter speaker that needs to be mounted and soldered in place so that the sound can be heard.

Figure (1): Sound shield connected to the Arduino Mega

Alec Vozzy Senior Lab Progress Report 3

This week I worked on the beam range with the ultra-sonic sensors and helped integrate the sensor code with the audio code. To test the beam width I took a small box and also a large board to test its beam width. Figure 1 shows an approximation of how the beam width is projected. You’ll notice that there is a “dead zone”, this dead zone is where the sensor will measure 5 inches no matter what. The actual length of the dead zone is 6.5 to 7 inches in length. If an object is large and past this dead zone the sensor will accurately measure the range with in a ±1 inches. From figure 1 you can also see approximated beam pattern going out creating a cone shape.

Figure 1: Beam Characteristic To approximate this beam characteristic I took a smaller box and pushed it slowly into the beam.

Doing so would create lost echoes; Figure 2 shows how the sensor operates. Pushing the box slowly into the ream pointed directly at the sensor would bounce an echo directly back at it while pushing all lost and ghost echoes out to the side. These findings are very close to what the data sheet shows for the beam width. The data sheet is also shown in Figure 2 for its beam characteristics. After testing the beam on larger objects it had an easier time sensing and ranging. This is perfect for our application, one problem I do see is when we do the small scale test we will have to scale the objects up so it can accurately range.

Figure 2: Ultra-sonic Sensor Echoes and Beam Width

After I tested the beam width, Justin and I combined the range finding code and the audio code together. Figure 3 shows the code the sensor code that was added to the audio code. Implementing the code was fairly easy, we had to declare the variables in the sensor code in the audio code and write a loop that will trigger an audio event. In the IF loop outlined by the red box the range will trigger an event to go into an index and output an audio file. This code worked perfectly for the Arduino Uno and not the Mega. There was a problem while using the Mega and I believe it has to do with how the pins are laid out on the Mega.

Figure 3: Combined code

Figure 4 shows the differences between the Uno and Mega. I noticed the main differences in the two board is how they layout their digital pins and Pulse Width Modulation pins. The pins of interests are outlined in the red boxes.

Figure 4: Comparison between Uno and Mega

If you notice on the Uno that their digital pins and its PWM pins are combined together on row of pins. For the Mega the PWM pins are all on one side while it’s separated from its digital pins. This is a problem for the shield because the shield relies on pins 13, 12, 11, 10, 2, 3, 4, and 5. On the Uno pins 11, 10, 5, and 3 are PWM pins, and this is not a problem on the Mega, the problem are the pins that are not PWM. Pins 13, 12, 4, and 2 are not supposed to be pulse pins, but on the Mega these pins are PWM. The rest of the week and next week’s task is to look into this pin problem. It is a possibility that we can just rewrite the pins not to be pulse width output. Justin and I will also try to declare different pins for the audio shield and use jumper wires to jump non PWM pins to the bottom digital pins.

Dylan Dean

Progress Report 3/7/14

The status of the senior design project as of this week is, the car is driving with input from the

Arduino. We can control the speed, turning, and forward and reverse motion. This was done with the

use of an H-bridge. Two ports of the h bridge are set to control the forward and reverse motion of the

car. The other two ports control the left and right turning. The Arduino code is where the speed is

controlled. As can be seen in Figure(1).

An Arduino uno was used in testing the code and the +5v source on the Arduino was used to

power the motors, doing so gave them an insufficient amount of power. So, a 12 volt rechargeable

battery will be used to supplement the draw of the motors. The addition of the battery will not add

digitalWrite(motor1Pin, HIGH); // set leg 1 of the H-bridge high

digitalWrite(motor2Pin, LOW); // set leg 2 of the H-bridge low speed = analogRead(potPin);

speed = 793 + (speed/4);

analogWrite (speedPin, speed);

Serial.println(speed); Figure(1): code to control motor speed

much weight to the rc car and will provide power to the Arduino board and motors. The basic circuit

setup can be seen in Figure(2). The chip in the illustration is the h-bridge. Also, note that there is only

one connected motor in the figure, in the actual setup there are 2.

There are only a few tasks left to do on this project to get the model acting as it should. Namely

consolidating all of the codes for the sensors, soundboard, print screens and wifi communication. Since

the car is can drive a platform of sorts will need to be made to mount on the car to hold and house the

electronics and sensors.

For the coming week the plan is to draft up a platform for the car, to be 3d printed, using solid

edge. Along with this, the car should begin to take shape as we integrate our systems to act based on

inputs from the sensors. If all goes according to plan this week. We should be troubleshooting and

testing by the end of the week we return from spring break.

Figure(2): dc motor controller setup.

Jacob Anderson

Senior Design Report

Week 3/7/2014

Progress:

This past week me and Dylan have been working together on getting the two DC motors

to work better. The front motor needs to have enough power to turn the wheels all the way and

doesn’t not need to have control over this motor. But the back motor needs to be controlled. If

we can control the speed then parking would be a lot easier with the ultrasonic sensors. We

solved the problem by using an h-bridge. A single h-bridge would solve this problem. First we

had to find an h-bridge and the EE-Lab did not have one to supply us with. I then supplied our

group with one of my own h-bridges.

The h-bridge solved the problem of controlling the two DC motors and only using 4

digital pins from the Arduino. This is a good compromise compared to the relay option that did

not have speed control. At first we powered the motors using the 5V power from the Arduino,

but realized that when two motors were both pulling power off of this it caused a power

deficiency. So we then, solved this by hooking up an external power supply to the motors, this

made them consistent and a lot more powerful.

Plans:

Our plans for next week is to make a platform for all the components to sit on the car so

we can start programing the motors for the proper weight. Dan is thinking about making one out

of PLA, but I think his workload for the project is fairly large right now so I think I will take it

over and make a quick one out of pine wood. The other thing for next week that I would like to

get done the battery power supply for the Arduino that will be used on the car. I have a

rechargeable 12V battery that is around 1800mWh so I think this will be efficient enough for the

intended purpose of the project. The last thing we need to work on for next week is stabilizing

the motors. Right now they are a little unstable, but they do work really well. So we have to

play around with the code for a bit to. And if we get ahead of schedule then we will start

implementing the other parts of our car with the DC motors and try to hook up the DC motors to

the Arduino mega.

H-Bridge used

Daniel Galy Senior Design Group 5

SN 333719

Parking Team Task (A) Update:

In order to create a system that will aid the driver when parking many different systems need to come together. The movement control, audio, distance sensors, visual, and remote control all need to be designed and implemented together. This week my task was to finish and fix the Arduino screen’s coding, and then to order and begin coding the wireless transmitters.

Problems with screen coding resolved:

The original code that was sent in with the first progress report was found to have errors due to a multiple problems with the Arduino software and TFT class implementation.

The first error was that when the images were loaded from the SD card there would be displayed as bars across the screen. This error was as a result of libraries that were not updated. Updating libraries does not automatically happen when the Arduino IDE is updated. In order to update the libraries, a completely different Arduino IDE needed to be downloaded from the same website. The new IDE is called Arduino Nightly Updates. The software is virtually the same except that the Nightly Builds version checks the libraries for out of date classes and header files. The download link can be found following:

http://arduino.cc/en/main/software#.UxjVPj9dVTY

The next problem that was resolved was an error that would occur when multiple images were loaded. The problem was that after a few images were loaded the Arduino would freeze and stop displaying images all together. After some research this problem was determined to be an error in the TFT library where a memory leak would overwrite the images. In order to rectify this problem the “PImage” type variable that stored the image data would need to be assigned a value the instant that the image would be needed to be displayed. Once this method was implemented the problem as resolved. The final code can be seen as follows:

Wireless Transmitter for Arduino Proposed Code:

The code for the transmitter needs to be able to send a simple signal that will let the remote know what to do. Until the device can be tested, all that can be done is propose a code that may accomplish this task. The code can be seen on the following page. Briefly stated, two “pipes” are created with unique signature frequencies. The task of communication can be accomplished by setting a pin on the remote to be a “listener” while the pin on an Arduino inside the car is set to transmission. When the transmitter sends a message it then turns into a receiver and waits for a call back. If it does not receive a call back then it will send the message again. Meanwhile, the remote, upon receiving a message will change to a transmitter and send a signal that acknowledges the signal. The amount different signals that can be sent depend on the number of “pipes” created. We have to wait until the packages arrive to test the code.