Moore Display Case

The RAC Mustang currently being proudly displayed in the Moore building display case at the School of Engineering and Applied Science.

Demos and Videos

Explanation Demo

PING and Anti collision system
Drive with lights

Newly installed PING sensors and rearlights

Time to Turn Up the Heat

We think the reason our PING sensor anti collision system isn't working at the moment is because not enough current is being sourced to the sensors while the motors are running (they are all powered by one 9V battery).  To remedy this, we're going to try one of Bill's LiPo batteries, capable of sourcing several Amps at 11V.  We've cut the duty cycle of the DC PWM in anticipation of crazy immense current.

From Wikipedia: "Li-poly batteries are also gaining favor in the world of radio-controlled aircraft as well as radio-controlled cars, where the advantages of both lower weight and greatly increased run times can be sufficient justification for the price."

We hope this works.

*Update*
After replacing the 9V batteries with the LiPo, every component of our system worked. Despite this, our RAC Mustang still did not run flawlessly because there were some loose connections between components. We soldered what we could (like the light system and PING) but the majority of the connections were to the microcontrollers and we weren't allowed to solder those. In the end, our car works perfectly roughly 2/3 of the time and is passable for the other 1/3.

PING!

After a few days of trials and tribulations, the PING sensor finally works with the HC12.  The missing piece? the line that clears the IOC flag in the interrupt handler, a mistake second only to the common ground in painfulness. An anti-collision system is now in code that prevents the car from moving in the direction an obstacle is in.  Once the circuit for the PING sensors on the front and back of the car is completed, we can give it a spin.

Common Ground -> Progress -> *Baseline* -> Refine -> Extension

We are using the DC motor that came with the car so it did not need to be mounted, however the servo motor still needed to be attached. I used Evan's dremmel again to shave off the arms of the servo and then mounted the servo onto the front of the car using electric tape. With the servo and DC motors working correctly, we pretty much had a RAC car. And on top of that, we also had a functional lighting system. However, with the HC12 tied down to the project board for power, we couldn't technically drive the car more than the length of our shortest wire. Thus, we had to move the HC12 and everything else onto the car base. The problem with the HC12 was that we weren't sure how to power it. Initially we fed its Vaux pin a 5V output from a voltage regulator, but this did nothing more than turn on the indicator LEDs on the HC12 (the DC and servo motors twitches so we thought there wasn't enough voltage/current going through). We also tried using the barrel connector, which seemed a more direct power input method. This returned the same result as using Vaux so we opened up the datasheet for the APS12 board. We learned that the microcontroller has a build in voltage regulator and accepts input voltages between 6V and, if I recall, 18V. We proceeded to give the +7.5V from the five AA batteries using both methods, but still got the same futile results. All this time we were trying different jumper combinations for each method. Furthermore, from the datasheet we learned that the board limits the current to 250mA, and using a power supply on the motors while limiting the current to 250mA barely moves them. After extensive debugging as shown from the picture, we decided to add another power source specifically to power the Hc12. This method worked and we were able to put together a working RAC car,  which is our baseline goal.

Common Ground -> *Progress* -> Baseline -> Refine -> Extension

When we finally had things to update on, we never got the chance to write about it because we were working so much on our project to reach the baseline. Now that we reached it I am taking some time to write about what we have been doing since the common ground realization.


Servo Motor:

We wrote up the code for the HC12 to rotate servo motor based on x-axis accelerometer inputs (now that SPI is working). The servo motor was also controlled using PWM, and the duty cycle of the square wave generated using PWM determined the angle at which the servo would turn. The turning mechanism of the Mustang car consisted of a groove as shown. The servo motor's cross fits perfectly in the groove. All we had to do was map the full range of x-axis accelerometer values to the restricted range needed to turn the wheels. We eyeballed it to be 3.75% to 5.1% and got it right the first try.


Light System:

For this we took our first steps into a whole bunch of soldering. We bought some super bright blue LEDs for the headlights and then four red LEDs for the rearlights. The light system circuit consisted of the LEDs and a photoresistor voltage divider. We programmed the HC12 so that if the ambient light gets dim enough, the output of the voltage divider with the photoresistor would be a high enough input to the ADC pin. As a result of this, we output a high to PA0 and PA1, which are connected to the positive end of the headlight and rearlight LEDs. In addition, we programmed so that the rearlights would turn on anytime the car is driving in reverse.


H-Bridge:

To drive and control the DC motor we needed an H-bridge, however the dual channel H-bridge we had was definitely too big to fit under the car case. We went to the GM lab and obtained a L293D quadruple half-H drivers, which was just a tiny IC. By looking up the datasheet for the L293D and using our knowledge from the H-bridge we used before, we were able to successfully use the tiny L293D to control the DC motors to spin forward and reverse.


PCB Cookie:
To have a standalone RAC car, we need the HC12 independent of the project board. This also means that we won't get to use the complementary breadboard. Initially we found a mini breadboard where we wired up our circuits, but it was still a little thick and didn't look very clean. Our friend Bill found us a clean PCB to which we soldered the H-bridge circuit and common ground.


Ping Sensor Installation:
Finally, in anticipation for our add on to the baseline, we decided to mount the ping sensors to the car case in advance. Thanks to Kevin's tools and Evan's dremmel we were able to drill two holes where the ping sensor could poke through.

*Common Ground* -> Progress -> Baseline -> Refine -> Extension

If we ignore the post of the baseline demo video yesterday, the last updated was posted on April 15th. If you recall I mentioned that " it shouldn't take long for us to fix whatever the problem is [with SPI]." Well I was wrong; the reason why we haven't made any updates is because there was nothing to post about. We spent a week debugging SPI because it wasn't correctly transmitting values from the FireFly to the HC12. We tried everything we could think of and even thought about switching to alternatives such as UART, serial, MaEvArM, or even scrapping the HC12 all together. When we finally enlisted the help of Sanket and Mishu, the things they suggested we have all tried, and more. After a whole week, our amazing TA Mishu noticed we had extraneous offset voltages because there was no common ground between the HC12 and FireFly. This immediately fixed our problem of the FireFly sending random junk values in between correct values to the HC12 via SPI, because it turns out we had SPI working right from the beginning. Once this irksome hurdle was overcame, we finally started making noticeable progress.

Update - Baseline Demo

It is 2:43am in the RCA lab and our car runs on battery power. It turns out we needed to use the barrel connector instead of Vaux on the J1 connector to power the HC12, and needed the correct jumper configuration (we found the datasheet for the APS12 board). We also needed to give it a separate power supply (currently a 9V battery, the HC12 has an internal voltage regulator called VR1) because otherwise neither it nor the motors got enough current to work properly. We'll put together the whole thing fancily later. Just thought we'd update after actually getting success.

Making some noise

So we brought the mustang car to the RCA lab today and hooked up its original motor to a function generator and power supply through an H-bridge. We generated a 50Hz 5V amplitude square wave using the function generator to simulate a PWM output and fed that to the motor. As a result, we were able to control the speed of the motor by changing the duty cycle of the square wave.

Now that we know how the DC that came with the car works, we intend to control it next using the HC12 microcontroller. First we have to do some debugging to get the wirelessly received accelerometer data on the slave FireFly to output to the HC12 using SPI. We had SPI working few days ago so it shouldn't take long for us to fix whatever the problem is. Once we have SPI working between the FireFly and HC12, we will be able to control the motors wirelessly with the accelerometer.

SPI!

We've finally gotten SPI communication working between a FireFly node and the HC12.  Our goal with this was to transfer accelerometer data to the HC12, which would handle the grunt work of powering the motors.  Right now it's only one-way communication, but if we find other uses we could make the line bidirectional as well.  Our thanks to TA Sanket for help, he taught us SPI and found the source of the bug that kept the system from working: the NRK_DEBUG_0 port wasn't actually outputting any signal.  Now that this step is done, we've got to write the code for the HC12 that uses this accelerometer data to move the car around.  Maybe we can find why RT-Link isn't working so well either...

I just bought a Mustang

Last weekend I went with members of another ESE350 group to KMart to buy a toy car which we will make RAC (Varun could not make it, but was there in spirit and on phone). We knew there were several specifications that need to be met:

1. the car must be able to move
2. the car must be able to turn
3. the car must be big enough for us to cramp in a couple microcontrollers, sensors, and power supply
4. the car must be sturdy enough to withhold these additional components
4. the car must look slick

Almost every car in the toy department could move in a straight line at the very least, so the first specification was easily met. However we realized to fulfill the second requirement, we would need to actually buy a car that was already RC, because simpler toy cars have no need for the complexity of turning. With two constraints satisfied, we pretty much narrowed ourselves down to the RC car section. All was left to do was to pick a car from the selection looks like it can satisfy the last three specifications. We were prepared to adapt to any shortcoming that our car might have, once we take it apart at home.

I spent more than 20 minutes walking around the store and finally decided on a very nice looking RC Mustang Shelby GT-H, shown in the following pictures. I bought it, and took it home so that I can take it part to see what we are dealing with. (Click to see enlarged).



After taking off the shell, we see the PCB for the original RC capabilities. There are wires connected to the motors and power supply, and we can strip them and integrate/replace them for our own microcontroller. When this PCB was dismounted, we freed up space where we can put the FireFly and the HC12.

The reason why we bought a RC car is so we don't have to make our own steering system, such as with a rack and pinion. As we see here, the RC car came with a very primitive rack-and-pinion steering system where any simple pinion that would fit in the notch (rack) indicated could force the wheels to turn. We can to interface the servo motor directly with this component.

Also, the RC car came with a DC motor, so we could either figure out how duty cycle affects it by testing it on our HC12, or replace with with our own DC motor. The question to be answered here is how we would supply enough current to turn the wheels at a force that can move the car. We had planned to use an H-bridge, but looking at the original DC motor, it seems we might be able to get the wheels spinning without an H-bridge.

As mentioned in our project proposal, we hope to implement a functional lighting system to our RAC Mustang. When I removed the bummer, I saw some very convenient holes where we could loop through some wires; and on the other side of these holes was the clear headlight casing with enough room in between to fit a LED. More modifications would be needed, however, to do the same for the back light.

Project Proposal

When we learned the spring 2010 ESE350 final design project's theme was "games," we decided that building a RC car would be fun, interesting, and interactive. The baseline of our project to wirelessly control the steering and speed of a car with motion sensor controls. Motor actuation will be enabled through the use of the FireFly and HC12 microcontrollers.


~Control Scheme~
We would attach an sensor board with an accelerometer to the Firefly node and the sensor inputs would direct the servo motor and DC motor for steering and acceleration respectively. The user would be able to tilt the FireFly away and towards him to drive the car forward and in reverse. The angle at which the user tilts the FireFly (from normal) would be proportional to how fast the DC motor spins in either direction. In addition, the user can "steer" the car by tilting the FireFly to the left or right. The servo motor would rotate the front wheels in the appropriate direction, which would enable turning capabilities when coupled with the back wheel acceleration.
Like we mentioned above, our baseline goal is to control this response wirelessly. To accomplish this, we would use the FireFly's networking capabilities (likely over BMAC) to connect to another FireFly node inside the car, and transmit the accelerometer data over that link. Then we would use SPI to connect that node to the HC12 microcontroller also located inside the car, which would use the accelerometer data to generate the appropriate PWM signals to power the DC and servo motors that move and turn the car.

~Extensions~
Once our baseline goal of having a functional remote accelerometer controlled (RAC) car have been reached, we will incrementally make this prototype more developed and sophisticated with additional features.

We first hope to install a functional lighting system to the RAC car through the addition of blue and red LEDs to the headlight and back-light locations. The back-lights will turn on if the microcontroller senses the car is moving in reverse. Furthermore, if the ambient light is dim enough (measured with a photodiode), we would toggle both the headlights and taillights to turn on automatically.

Next, we hope to establish an anti-collision system to our RAC car. We would install PING sensors to the front and back of the car, which will detect objects directly in front of and behind the vehicle. With this capability, we can calculate the speed of the car by detecting the changing distances to a target and measuring the time it takes for the distances to change. We hope to constantly print this value on a LCD display, possible by wiring it to an Arduino if installing the LCD on the FireFly isn't feasible. By comparing both the car's speed and its proximity to the nearest obstacle, we can prevent collisions by deactivating the acceleration once thresholds for both factors have been exceeded.

An extension to this feature would be an auto-pilot capability, where the car would avoid all obstacles by driving around them (through a combined use of PING sensors and motor response). In addition, we could also/alternatively implement an automated wall hugging function through the addition of a side PING sensor.


We hope to have the prototype stage, with the remote control of motors working and progress on one of the ancillary stages by the preliminary demo.

Challenges we face are interleaving on the SPI bus to take traffic from the wireless link and also to send data to the HC12. If we were to use an LCD screen, we have to figure out where to connect it and how. We also have space constraints in using a toy car, along with motor issues such as weight and the need to supply enough current. Finally, we need to power all of the peripherals within the confined car space while keeping the outside appearance pristine.