Monday, May 3, 2010

Video Demo

Here's a short video demonstrating our project. Also note that Joe got a job offer. He's pretty excited.

Thursday, April 29, 2010

Neater Block Diagram



Again, this is a sketch of the communication between each component. The communication between the cars, controllers, and gate is all wireless

Error Handling

Things To Look Out For:
Every task must end with
nrk_wait_until_next_period();
-When we were adjusting our PWM so that no signal would be output when there was zero duty period, we mistakenly put the above statement into the check, leading to 'Task Reserve Violated' errors. We put the check in because there was a slight lag between setting and clearing the pin that caused the cars to inch forward, even when duty periods were 0.

Pictures!






Here are some fresh pics of the tanks and remotes. A couple of close-ups as well.

Wednesday, April 28, 2010

Block Diagram



This is the new block diagram for our communication setup. I decided to draw it because I was prompted to draw a block diagram in an interview this morning, and because I was trying to figure out some enabling stuff for the gate. From this, the new communication from controller to gate was born.

TODO:
compartmentalize code. It's getting unwieldy.

Tuesday, April 27, 2010

Integrating the Gate

We've set up the communication between the cars, controllers, and gates. They'll communicate in a circle:

CONTROLLER->duty periods->CAR
CAR->if they won->GATE
GATE->enable/disable based on start/end of race->CONTROLLER

After getting past initialization issues, we now have hit a wall: once you send a packet, you stop receiving. the fix: enable receiving every time you send a packet.

Now all three of the nodes are sending packets in a circle. The actual gate still needs to be built.

I think what we're going to do is have gate effectively enable each of the cars through the controllers. To signal the race start, both controllers will have to press the "select" button. Then, the gate will check that both cars are under the gate (using information from the light sensors on the cars) and once this is verified, it will count down the start of the race with LEDs. Once the race has officially begun, the controllers will be able to send non-zero duty periods to their respective cars, and they'll be able to move. Once one of the cars senses that they have won, it will inform the gate, which will display the winner.

Monday, April 26, 2010

The Start\End Gate

We've started working on the start/end gate code. So far, the gate node is receiving packets and can register and display who wins. So basically, the easy part. We still need to get the cars to send special packets out when they register that they win. They sense that they win when their light sensors are in darkness. The cars need to respond to that win detection by sending out packets that start with an identifier for the gate node (we're using the number 99) and follow by their identifying number (1 or 2). The gate node then checks to see if each packet is for them, reads in the winner, and displays it. The actual gate has yet to be built. Our project for tomorrow: get the gate built and working.

Also, the new (and neat!) circuits for the car and controller are debugged and working. Now, if we want our cars to drive backwards, they're set up to do it! We just need to update our controller-to-duty period algorithm....

More Wiring, and Starting the START/END Gate

Today we got some smaller H-bridges and wired them up to the DC motors in the tanks. originally, we tried to wire in an inverter so that we would only need one pin for changing the direction of the car, but we kept on frying them, even after we hooked them up to voltage regulators. So, since we have extra pins, we have decided to forgo the finicky inverters. Quick and dirty, and the professor says...

Today we also wired up the other car and joystick, and got some new nodes as well (we still need one more firefly, but we got two today). We continued working on getting the cars to detect which has won the race using light sensors, and were also working on making the cars go backwards. Also, the broken car is now soldered back together.

Still to do:
-build end gate
-program end gate node
-finish hooking up light sensors
-get communication between cars and end gate
-debug some of the wiring for making the tanks go forward/backward

It seems like we didn't make much progress today even though we spent a lot of time in the lab. We still have a lot to do...

Sunday, April 25, 2010

The Working Baseline

Our problem with the signal not coming out of our node once it was disconnected from the programmer board is gone! By grounding the ADC header with the ground for the motors, we got the signal to come out, and now our tank is driving around, sans wires. The only thing we have yet to make wireless is the controller; it's still hooked up to a power supply.

Controller Finished

Today we finished putting together and calibrating the controller. The controller basically consists of a potentiometer joystick and a firefly node. It's all soldered together now (and I learned how to solder!) and ready to go. The only thing is, right now we have to power it from a power supply. Hopefully we can find a way to get power to the joystick from the Firefly.

Basic overview of our joystick:
-takes in ADC values for x and y axis
-converts this data into duty periods for the PWMs for each motor
-sends packets consisting of these duty periods to sister node

-car is stationary when joystick is at origin
-car moves forward, turns
-still cant move backwards; any motion of joystick in negative y direction gives duty periods of 0 (no motion)

Saturday, April 24, 2010

No signal produced when node not connected to programmer board

We realized today that our output signal is not produced when we disconnect our nodes from the programmer board. This could be because there are extra resistors connecting the batteries. Whatever it is, we know that the LEDs still work when the node is disconnected from the programmer board, so we have to find two nodes with the LEDs soldered off and use those pins for out output signals to our motors.

Tuesday, April 20, 2010

PWM straight from the ATmega128

We found PWM in the Atmega128 micro! At first, we were looking through the nano-RK documentation and were trying to get a signal out using tasks, but that wasn't working well, and there was no PWM. So we're working around nano-RK and going straight to the source: the micro. I'm sifting through the documentation, and we're just going to override the whole Firefly/nano-RK setup to get more functionality.

Monday, April 19, 2010

Parts update

We've gotten some new code from Mishu that increases the speed of receiving/sending packets. This should make our cars' response time a lot better. We've also had some parts delayed since Roop is in the ER, but we're making due. Since the potentiometer joysticks and their breakout boards aren't in yet, we'll be testing using a regular potentiometer. We've also picked up a dual H-bridge to drive our DC motors, and may end up with a snazzy mini version if we can get one from the GM lab.

Though one of our car chassis came in broken and we'll need to solder back together one of the connections, our other car is running smoothly.

Tuesday, April 13, 2010

Car Chassis

In the end, we decided on a tank-like chassis for our cars (I think it's Art's guy side coming out). It doesn't go as fast as the 3pi, but we will be able to incorporate obstacle courses. The reason we didn't decide to use the Boe-Bots that the RCA lab already has is that we'd need to get new motors/wheels for them because right now, they're running with super-slow servo motors. We were worried about fitting new wheels on the robots, because we only have two more weeks to finish the project and we don't want to deal with mechanical issues. Here's the link for the tanks were getting:

http://www.pololu.com/catalog/product/1059

Monday, April 12, 2010

Parts

We're thinking about how to put together each of our cars. We looked at hobby car kits, but they come ready to assemble and are pretty expensive. Now we're looking at using K'Nex to build our car bodies. Hopefully, K'Nex won't end up being too expensive, and it will allow us to easily change the design of the cars to fit components inside.
Our biggest problem with the car body is going to be the chassis. We need something strong that also allows for steering. We can either get someone in MEAM to help us build something or we can buy a chassis.
Buggy Car Chassis Kit: http://www.hobbyengineering.com/H2020.html
Pololu 3pi robot http://www.pololu.com/catalog/product/975
Boe Bot http://www.parallax.com/tabid/411/Default.aspx
We already have Boe Bots, but they run on servo motors and are very slow, so we'd need new DC motors for those

For our joystick, we're going to use potentiometer joysticks.
http://www.sparkfun.com/commerce/product_info.php?products_id=9032

For the starting and ending gates, were going to need LEDs, which we can find in the lab.

each car will sense when it crosses the finish line, and send that information to the finishing gate to be displayed. The cars will sense when they enter the dark of the finishing gate/garage with light sensors/photoresistors, which we can find in the lab.

Preliminary Project Description

Racecars

We are planning on building two racecars for our final project. Each player will control their respective car using a joystick. The joysticks will controls what direction the car drives in, whether the car drives in forward or reverse, and at what speed the racecar moves. For this, we will use a two-axis accelerometer. If we decide to change the joystick into a wii-mote type of controller, we will need a three-axis accelerometer and a gyroscope. The cars will have DC motors that turn their wheels, whose PWMs (and thus speeds) will be adjusted in correlation with the distance the joystick is moved from the origin. If the joystick is moved backwards, the duty cycles created by PWM will be decreased to zero and the direction of the DC motor will be changed before the duty cycle is increased again. This can be used as a breaking mechanism, where the player will hold the joystick backwards for a short amount of time to slow down the car before it starts moving backwards, as well as a mechanism for driving in reverse. When the car is turning, one of the wheels will turn faster than the other, and thus its motor will have a larger duty cycle.

The cars will have a starting gate that double as a finish line. It will tell the cars when to move with sequential starting lights. An option is that the cars will not be able to move before the start signal is initiated, so that no false starts will occur. When the race finished, the start/end gate will register which car passed through the gate first, and the result of who won will be displayed on the gate using LEDs.