We are ePIC Win

After gluing everything together and taping things down, we have checked off. We also did our first test drive in Hoop Fountain, and even made it through the heavy water jets. Still to come are the presentation tomorrow and video of the boat driving around, once we get around to uploading it.

CVC functional (almost)

The CVC has been entirely migrated to the soldered board, including all Molex connections. The only thing left is to transfer from wall wart to battery power on the E128. Unfortunately one battery isn't enough to power everything, and the TA office is out of them. So we have to fetch one soon. It also requires some small tweaks to the board to get a second battery on, but there is still space (barely).

Plus the CVC needs a home, but that seems to be coming very soon thanks to Matt's rapid SolidWorks skills. It'll be pretty satisfying to finally drive the boat around in the water soon.

Final Push

Glad the CVC and ACV are functional. Good job to Preyas and Matt for figuring out the problem with the voltage regulators!

The next steps seem to be finishing the CVC, including integrating a funny hat with the accelerometer. Plus wire management and connecting everything, like batteries and switches. I need to add code to reset the atoll statuses at the start of a game. And there are probably some wires that could use Molex connectors at the end. So, all the little things that will make everything finally work together.

Trust

It was a weird day. We had both ACV and CVC soldered. We had already checked that the CVC ckt worked alright. We had failed once with the ACV circuit. We had burned a pic in the process, so Matt and I were apprehensive about testing out the same ckt again (with some modifications). So we put all the pieces and chips in the sockets and turned on the power supply. We tried to see if we got any UART response from the bus pirate when we swiped the card in front of the reader. It wasn't working. Again. We checked if some chips were getting hot, as had turned out in the last attempt, and they were this time too! Then out of respect to Jackie's efforts in soldering, we decided that there was something wrong about the way we were doing it. We traced our paths back and couldn't find any problem. Just out of whim, we decided to switch our power supply source to the batteries we had. We though that it may be wrong driving  the o/p pins of the voltage regulator with the external power supply we connected initially. Apparently the 7805 isn't reverse protected. This time, with the batteries as power, we incrementally went about testing the ckt- RFID reader output. It worked. Then we added in the RFID PIC. It worked. Then added in the Security chip related PIC. It worked. Then added in the security controller. It worked. Then added in the main PIC. It worked! I texted Jackie and congratulated her on her effort. She looked satisfied, evident from the text back.

This brings me to the thing that got us through today- trust. We just happened to trust each other more at crucial moments and prevented a mega-soldering effort that Matt and I had planned for tomorrow. I am amazed how much trust one can have in someone you know well only since last couple of weeks

A battle of epic proportions

I spent 3 days trying to figure out why the pickit3 debugger wasn't stopping at simple breakpoints and why a seemingly correct code worked sometimes and didn't most of the times. Things looked to have a probabilistic flavor and I was almost sure I would have to find the expected number of times I need to burn the same code, though that wouldn't guarantee anything! It was an epic battle. First I found some module variables weren't getting initialized to right value. Ruslan and I forced it to work in this case by manually setting those variables to required values. Then I included the 'finding the teammate' part of my code and things went as wrong as they can go only in hell- the code simply stopped executing at a particular fixed line. Certainly I had no clue and neither did the great Ed! Then I turned towards the simple Eric Wei and his amazing insights and asked him to use his brain's awesome computing power and fix it for me. We commented out the line where the code got stuck and tried to stop at the breakpt. And it worked! Then I uncommented that line and  it still worked! I promised him a treat, but Ed wasn't happy because now the problem was 'lost' and could not be reproduced. Being a follower of procedures, I did as Ed had told me- restarted the entire workstation devices, including the computer. Then I checked if the problem still persisted, and it did! I had given up and just decided to initialize my set of variables inside my Init function instead of initializing them outside during declaration. It seemed to make the debugger stop at the breakpts I set but it didn't stop at breakpts set later than a particular line, as if it were 'offset'. Then I decided to check what worked in my old code (the one with the old timer) and new code (new timer).I had always thought the new timer was causing the problems, but I realized that I had fewer state machines in the old code.  Just on a whim, I decide to remove one of the 3 parallel state machines I was using and instead code it up in an interrupt routine like I had in old code. I also ditched the debugger for the seemingly more reliable picstart plus programmer. This I tried in the checkpt2 code and it worked. I held my breath and tried it with the complete code, and it worked! Fittingly, it was an ePIC Win! The only explanation I can think of is that the compiler is not able to handle long codes even if it wasn't using its complete program memory. So eliminating one of the state machines and coding it up as an interrupt response routine reduced the number of lines of code to some acceptable value for the compiler. Bottomline, don't trust the Lite Mode Hitech Compiler for C for PICs.

~Preyas.

P.S. I still feel 'violated' as a manner of speaking because the stupid compiler was at fault and wasted precious 3 days that I could have used for something else. And boasted about in the spdl. Damn all the Murphys of the world.

Next: Battle of the Xbee, Jackie

Screwed Up Project Specs

Fixed the problem with the RFID and security chip. It wasn't sending valid codes! wasted almost half a day on figuring that out. They should have made project specs clearer, specially with ACV replacing DCH everywhere :P.  Ryan and Will have done well though. Couldn't have had better TAs.
Also came across the weirdest compiler thing. Ruslan and I sat down and fixed it. Now we have sweet 8 software timers at out disposal. Aye aye, Barbosa!

Monday 16 May, 12pm 44min 34s (Pacific Time): finished coding on ACV. works fine

Status

Into the final 11 days. We are at a good position. Major part of coding is over. Soldering the electrical circuits now. Facing a couple of problems in talking with the atoll. should be able to address them soon. Otherwise, we are ready for chkpt 2 3 days before it! Matt finally working on some respectable prototype and things seem to be exciting.

XBees are talking for real

Turns out what was missing was a resistor between the bus pirate and the receiving line on one XBee. Then it was a resistor between the other XBee and the receiving line for the ACV Pic. Either way, with all of our 1Ks in place, we have communication!

Oh, and blinky lights. The E128 has enough ports that I can control all the lines on 5 RGB LEDs (for display atoll possession status) and still have room left over for accelerometer and potentiometer inputs, a whole bunch of other switches, maybe some debugging lines, etc. Good stuff.

Things for me to do by the end of the week:

• I know transmitting is working on the CVC, now I need to be able to receive.
• Get it reading sensor data and composing messages accordingly.
• Start parsing messages from the ACV, other players, and wherever messages will come from.
• On that note, read the communications protocol carefully and understand everything I'll have to handle.
• Package everything nicely into state machine format.
• Start soldering the final versions of circuits as they finish.

Communication charts, state diagrams, things to do ...the usual

Will's website

http://me218c.weebly.com/

Updates From Friday (May 6, 2001)

Today: 6 May
parts yet to receive: propeller

coding done:
ACV:tested PWM and motors
tested RFID, works completely.
written Security chip State Machine
written Receive part of State Machine on Main PIC

CVC:
written State Machine. Currently Testing

Xbee:
testing. don't yet know if they work

To do:
start soldering bigger circuits (if any)
start prototyping (after Matt's exam)

Things to buy/get:
larger circuit board, wires?
a box to keep all our material in place

Small Snippets of Code that may be required to check the Receive State Machines:
A code which sends a fixed formatted message from e128
a code which sends a fixed formatted message from the pic

Aims for next couple of days:
protoyping after Matt's exam finishes tomorrow
get Xbee working (hopefully tonite)
Get ACV and CVC state machines working (hopefully by tmrw nite)
We have to get this done by Monday, 9 May. 10 May is the checkpt.

Attached is an almost final draft of the protocol decided by the Comm Comm.

Trying to Get the XBee to Talk

Things to take note of:

• Length and checksum are referring to just the data (after the start byte and length, before the checksum).
• If the lights aren't on, the XBee isn't working.
• Bus pirates are awesome.

Hopefully good progress will be made today. It appears my skeleton state machine for the E128 on the CVC is functional. Now I just have to get more than garbage back from the XBee.

Also, the PIC16F777 arrived this morning. It looks like a beast.
 $11.62 from Microchip Direct.

Comm-Comm Notes

Requests to capture an atoll are broadcast messages which only specify the serial number of the atoll, and not the address of the atoll's radio.

We can set an option byte to receive all broadcast messages. A broadcast message is any message which is directed to address 0xFFFF.

Pre-built messages will work well with a test harness.

What to do with transmit status? Only applicable to directed messages.

What does the transmit message look like?

Add cycle limiter or timeout limit for any message transmission.

Draft will be completed by Friday, Final Draft due next Tuesday.

Motors + Drivers

We decided to use a pair of beefy Johnson Automation motors from Jameco. Its operating range is 13.5V and 1.44A, and it spins at 18500 rpm.

We will be pairing this with a LMD18200 H-bridge, http://www.national.com/ds/LM/LMD18200.pdf

I Am Epic Win

the giraffes are real though. http://www.petitelapgiraffe.com/

BOM update

Accelerometer from Adafruit, $20
Tupperware container from Amazon, ~$4

Paid for by Jackie

Controller Ideas

We have a pretty good idea of what we need to do for our AVC. Now we need to pin down our CVC (controller) design. Some ideas:

• Accelerometer--already been ordered. It can be part of anything, but my current favorite idea is a helmet or ridiculous hat with the accelerometer at the top so whoever is driving has to tilt their head back and forth to drive.
• Glove with cool buttons and other controls. Nice and small, so simple mechanically, but we can put a whole bunch of sensors on it.
• Drum: the faster you hit, the faster the boat will go (can be hilariously combined with the helmet).
• Steering wheel and gas pedal setup.
• Matt wants something with a potentiometer.
• Non-contact sensors like photo-sensors, tape sensors, solar cells, etc.
• Giant crank with an encoder.