The N.M.E design team met to continue working on the printed circuit board. From previous testing we encountered a problem involving the datalogger and LM34 Temp. sensor. During the week, our group received the new components and tested them to our circuit. The new datalogger and LM34 operated successfully!
Once our N.M.E. design team completed that issue, we began applying epoxy to the designated areas of the R/C car where we were going to place the Thermocouple and LM34. Epoxy was applied around a hole that was drilled in the exhaust pipe where the thermocouple would be inserted. The LM34 needed to be placed on the head of the carburetor, so epoxy was applied near the bottom coil of the carburetor. Once the epoxy was applied it needed to sit for several hours so it can completely dry. The designated areas that the Thermocouple and LM34 were applied too were placed according to the temperature accuracy of those specific areas.
As we let the epoxy dry, we started modifying our .spin code. We needed to derive a code to monitor our servo controlling the R/C’s throttle response. We achieved this by using the ServoInput Object that uses one of a cog's counters to continuously poll an R/C servo control signal and store the pulse width in microseconds. On our board we set up 3 pin connections directly to the propeller chip to monitor the throttle response of the servo. For the throttle response to be correctly displayed on our datalogger, we had to connect one of the channels of the R/C’s receiver to be connected in series with a 10Kohm resistor to one of the pins of the propeller and of course the red wire to +5v and black to ground. First, we tested our code on a VGA monitor to make sure our board was properly monitoring the receiver’s throttle response. Once we saw that it was functioning correctly we revised the .spin code to record the throttle response to our datalogger. The range of the R/C’s throttle response (in decimal) was 800 to 1500 and 1200-1300 being in idle position.
Display of R/C receiver's throttle response (Full Throttle)
Display of R/C receiver's throttle response (Full Brake)
Display of R/C receiver's throttle response (Idle)
Picture below shows the area where epoxy was applied to hold the LM34 Temp. sensor on the bottom portion of the carburetor
Picture below shows the drilled portion of the exhaust pipe where the Thermocouple will be placed.
Picture below shows the finished product of the Thermocouple insertion into the exhaust pipe
Pictures below shows the carburetor dissassembled from R/C chassis (displayed from left to right)
On 10.17.2008, the N.M.E. design team met up to continue working on the ongoing problem with the operation of the servo. The same day we ordered our ExpressPCB boards and necessary components from Digikey and Parallax. Before our team met up to continue working on the project we had a quick meeting with Dr. Ducharme to discuss our problems that we were having with the servo. During the quick meeting he gave us very useful tips and helpful guidelines to follow during our testing on the servo.
After the meeting we continued our progress on the coding for the servo. The original plan that our group followed was using and modifying the servo demos that we’ve downloaded from the Parallax Object Exchange in the past. We were following the code coming from the Servo32v3 and Servo4 objects. Of course the servo demos would activate our servo, but it wouldn’t function the way we desired. So our first attempts to revise the code didn’t work. We went back and forth from servo demo to servo demo to try and make our servo motor turn at our desired angles for at a certain period in time. So our second option was to embed our working (demo) servo code into our main program. We already knew our servo was activating properly, so we decided “hey, since the servos working, let’s just throw it into our main code and move on from there”. But heading in that route just made our problems even bigger.
Previously in our last weeks lab testing our group successfully initialized two new cogs to run in our main program; one for the ADC and the second for the datalogger. So seeing that the main program compiled successfully, we decided to make things a little bit easier. So we went ahead and initiated a new cog for the servo to operate in, that way we could have the servo code in its own environment; since we already knew that the main program compiled well. So our main goal of the day was to run the .spin program to activate our ADC, datalogger, and servo simultaneously. But going down that path didn’t go so well either. Our main problem that our group was encountering was that the datalogger and servo wouldn’t operate simultaneously. The ADC was working successfully the whole time. As we initialized the servo the datalogger wouldn’t respond, but when we deactivated the servo the datalogger worked fine. So we all knew that the actual datalogger and servo itself were working correctly. So it had to be the code. Our group made numerous attempts to modify our .spin code. We attempted to run the whole program off one main cog, run each program in separate cogs, and even rearranged the process flow of the code. But then again our several attempts at revising the code were a failure.
Before our group lab testing on 10.17.08 & 10.19.08, our group had a hunch that maybe the servo needs to operate off a different power supply rather than the power supply coming from the Propeller board. Because we noticed that each time the servo moved its position the green LED on the Propeller board would turn on and off in relation to the activity of the servo. In another words, it seemed like each time the servo moved from angle-to-angle it would reset the whole program. Possibly because we assumed that the servo might be drawing out too much current. According to research, the GWS Pico servo can reach up to a MAX of 500 milli-amperes. So we decided to go with our hunch and give it a try. During the middle of the week our group went to the lab and continued to make the impossible, possible. Previously the servo was drawing the 5 volts coming from the Propeller board. So we connected the positive (+) and ground wire to a different power supply running at 5 volts, but we left the signal (white) to PIN2 on the propeller chip. Unfortunately, we didn’t get any successful results. The servo was still doing the same thing it was doing previously.
After our meeting with Dr. Ducharme, our group decided to start off on a clean slate with the servo. We discarded all the servo demo programs we were previously using and agreed to create our code from scratch, step-by-step. We wanted to work on the code for the servo “alone” before doing anything else (like running it with the main prog. simultaneously). Our group did our research and discovered that all servos operate by sending a pulse of variable width through the signal (control) wire. These pulses have ranges and they are: minimum pulse, maximum pulse, and repetition rate. The angle is determined by the duration of the pulse which is also known as Pulse Width Modulation. The period of the servo’s clock cycle is 20 milli-seconds. So what we had to do in order for the servo to stay at its turned angle was to send repetitive pulse signals through the signal wire. Also depending on the length of the pulse that was sent determines the increase in the motor turns. So in our code we initialized PIN2 as our output, because the signal (red) wire from the servo was connected to PIN2 on the propeller board. We calculated the delay when the servo should be on and off. So basically if the servo expects to see a pulse every 20 milli-seconds, we would turn the servo motor at an Xo angle for a Y amount of time, then leave it off for a Z amount of time so the servo can hold its position.
Our calculation we derived was:
The servo motor turned at Xo angle in Y amount of time
Then the servo motor held its position at Xo angle for a Z amount of time
We calculated the amount of time (delay) for Z by taking the difference of 20ms & Y.
Ex: 20ms – Y = Z
We would use this calculation in our code to get our desired angle on the servo. Since the pulse of variable width has a repetition rate, we simply just threw these delays into a loop so it would send pulse signals repeatedly in the program.
Once we got that working we attempted to try to run our servo simultaneously with our main .spin program and it did the same exact same thing as our previous attempts. So then we decided to go back to the drawing board and use another power supply, but this time we connected the red (+) wire to the different power supply at 5 volts and connected the ground (-) wire to the common ground of the Propeller board ( we did NOT do this in our previous attempt, we connected ground to the power supply). We compiled and ran the program. It was a success!
We measured the current drawing from the servo at each stroke. The range of current coming from the servo was a minimum of 200mA to a maximum of 500mA. That's a strong pico servo!
B. Justin Rosario
N.M.E. Design Team
The main purpose of the meetings held on Friday (10.10.2008) and Sunday (10.12.2008) was to complete a schematic of the N.M.E system and to work on a program to control the Pico-Servo. The secondary objective was to repair the RC car once again. (Programming portion is on separate post).
After working many hours on the design of the PCB and the components needed, we came up with a schematic of the N.M.E system along with a rough layout of the Printed Circuit Board (PCB). The schematic is composed of ; Prop-plug, EEPROM, Cold Junction Compensator, Op amp, Parallax Micro controller, Analog to Digital Converter, Voltage regulator circuit, Servo controls Datalogger and Thermocouple fig 1.1.
Fig 1.1 Schematic Pin-out
The next step was to design the PCB layout fig 1.2. The layout was obtained by following carefully the details from our schematic.
This two drawings were then submitted to our advisor for revision. Our advisor's revision proved to be important, since a few errors were found and our component layout/organization skills are average. His revisions were used as a final documents fig1.3.
Jorge E Fontanez
N.M.E. Design Team
On October 3rd (Friday), the N.M.E. design had a meeting with Dr. Ducharme to discuss the progress on our senior Design project at 1:00p.m. After the meeting our team continued our work on campus at the Engineering 2 building in room 180. Due to our previous attempt at making our op-amp circuit for the K-type thermocouple, our goal that day was to start from scratch and use the necessary tools within the lab to rebuild our circuit. On the first attempt of building our op-amp circuit (on 09.28.2008) we were unsuccessful because we didn't have the right accessories. For example, we purchased a circuit board that had to have the components soldered to it and the solder tip that we were using was a little bit dull, but it was still fully functional. Our digital multi-meter was also giving us problems, because it would give us wrong readings. A major issue that we also came across during this attempt, was we were unable to get a hold of a 100-ohm potentiometer so we had to make use and create one out of several resistors to be equivalent to that value. With all these factors revolving around us we miscalculated the time it would take to get it finished. And yes, it did take longer than expected and at the end of the day the 1st attempt of our op-circuit for the thermocouple was unsuccessful. (Aside note: A Thermocouple creates a voltage of its own.)
So on this day we had a better chance to get things finished correctly in a timely manner, because we had the necessary equipment and materials that were needed. We had full- access to the soldering irons, breadboards, variety of different value resistors, power supply, and digital multi-meters. So our team continuted with the 2nd attempt of constructing the op-amp circuit for the thermocouple. We followed the schematics and pinouts according to the LT1025 and LT1050. Our first problem we encountered, was wiring the necessary components to the correct op-amp. This problem was fixed just by simply switching the op-amps to their designated side. A factor that made our team's process alot easier this time around was using a breadboard. By using the breadboard it was very easy to replace components and less time consuming to troubleshoot. The fact that we didn't need to solder anything on the 2nd attempt was a big help. As we were constructing our circuit we came across a problem that involved our LT1025 255k ohm feedback resistor. The voltage reading coming from the thermocouple would highly depend on the value we would substitute for our feedback resistor to the LT1025. We did numerous attempts of replacing different value resistors in the circuit. But even with the assigned 255k ohm resistor it would give us miscalculated values (temp./voltage) readings. We went ahead and kept lowering the resistor values until our voltage readings were finally correct. The resistor value that we replaced with the 255k ohm resistor was a 127k ohm resistor. The equation that we used to determine the thermocouple's temperature in relation to the voltage readings was 10 milliVolts per degress Celsius (10mV / oC). The constructed op-amp circuit for our Exhaust Gas Temperature Thermocouple was SUCCESSFUL.
On October 5th (Sunday), the N.M.E. design group met to start the schematics for our printed circuit board, Bill of Materials, and operation of the servo. Our team is using the expressPCB program which we downloaded from ExpressPCB.com to build our printed circuit board. Our printed circuit board will have the necessary components such as the Propeller chip, Op-amp circuit for the thermocouple, EEPROM, voltage regulator, Propeller plug, pins for the servo, LM34 temp. sensor, datalogger, and TV/RCA adapter, etc. All the necessary and required components like resistors, capacitors, etc. will be available in the final draft of the Bill of Materials.
We began operation testing on the servo. Rather than receiving the Futaba standard servo from Parallax, we ended up receiving the Futaba continuous rotational servo which was the wrong product we ordered. We decided that we needed a smaller scale servo in order for the servo to mount correctly in the R/C car. So in exchange, we called Parallax, they courteously resolved the problem and the outcome resulted in Parallax providing us with a complimentary GWS Pico servo at no charge. In the mean time our team has been working on the code for the servo. Until the GWS pico servo arrives we our currently testing with the standard servo from the R/C car. Our group is determing whether it is a better choice to have the servo operate by pulse-width or angles. So far we've accomplished movement of the servo by incrementing values in the code, but we're trying to figure out how we can reset the position in the designated angle by our demand.
Below is the comparison of our 1st (Top) & 2nd (Bottom) attempts of the op-amp circuit for the thermocouple
Below is the thermocouple bath we used to stabalize the thermcouple's temperature
Below is proof that as the thermoC. heat rises the voltage created from the thermoC. increases.
B. Justin Rosario
N.M.E. Design Team
Our solution was to take (2) 100Ω (ohm) resistors, set them parallel to each other and obtain a 50 Ω (ohm) resistance. We also had (5) 150 Ω (ohm) resistors and followed the same procedure in order to obtain a 75 Ω (ohm) resistance. And finally we set a (1) 100K Ω (ohm), (1) 20K Ω (ohm), (1) 4K Ω (ohm) and a (1) 2.2K Ω (ohm) resistor in series to obtain a 127K Ω(ohm) resistance. After soldering all the components to the board we began testing (fig. 2). The resistance at expected intervals were correct as well as the reference and input voltages. Unfortunately the desired output from the thermocouple was not obtained. We will purchase the necessary components prior to the next meeting and will try to solve this problem.
Fig.2
Board Prototype
Jorge E. Fontanez
N.M.E. Design Team
