We survived!

We made it through the final checkoff despite our last-second problems with the iButton reader. Here are some celebratory before, after, and action shots!




For some reason, the blog insists on loading the above image sideways....




Great work, guys!
~Laurel

The Final Countdown

We added an additional battery for the pump that clocks in at 11.10 V (even though it claims to be a lowly 9.6V) It delivers a steady stream of water.

Finished testing today. All systems are go!

David out

DUN done

We draw 110 mA according to my multimeter. 110 mA *h = 880 mAH < 1500 mAH for the battery. We're good. (Theoretical is 2100 mAH, but uses a lot of worst case calculations)

We decorated the duck and enabled the eyes. They are awesome.

There was an issue with shifting in just one time to the display, so now it does it every 600 mS based off of the 200 ms timer.

We turn off all the LEDs except the ship number at the end to indicate gameover.

We are considering adding a second battery for the pump because it is lame.

We had a full successful run, including pings during and after pairing, start game from admirals, stand down, base switching, and end game. The motors behaved as expected at all poitns.

TODO Tomorrow:
Check craft/helm pairing with others (We had successful control of the hot dog today)
Fix up pump
Take videos
Waterproofing

David out

Readying for wet run

I saw some strange things this morning.

1. Motors and pump did not respond. This was due to a low voltage battery; problem disappeared when it was charged.
2. Display was not correct in 7 seg. At times, the team/goal LEDs did not turn on correctly. We knocked down the baud rate to the lowest setting and stopped updating every 200 ms. Now it just updates on standdown and goal change.

Tested all specials. The quack does not respond all the time. The packet sent is correct, but the timing on the PIC side needs tweaking. The pump and flagon seem to work just fine.

Next step: Power budget, wet run, waterproofing, LED eyes

David out

Endgame movements

Laurel and I completed the code and electronics for the LED and 7 segment displays today. The bitshift can occur at speeds up to the max of what the E128 can SSP out (25 Mhz/2) For some reason, we found that bits 4 and 7 had to be switched on the charts for the LED display. Quirk: if you call the ShowBoatNumber() function, you also have to update the team affiliation. I placed the refresh for every 200 ms and it is functionally stable, though the update rate is visible.

Benjie and I have hashed out a scheme where we are constantly reading the analog voltages from the drumsticks and use the average for speed every 200 ms. It works out quite nicely; we want the voltage for max speed to be (at the greatest!) about 500 (value from the analog voltage in)

New iButton check on the PIC works fine. Now it will reject 0x00 and 0x00 as well as 0xff and 0xff as successive valid reads

Karl was able to ping the Helm in its "looking for iButton state" and the Kraft in its "waiting to pair state." That seems solid.

Our helm construction is well on its way. We have tested out hardware for the quack switch (works!) but are still seeing the pump turn on at the start. I have implemented a pump timer which will call for water until 10 seconds after the user stops yelling. The pump code currently is not functional; nor is the duck release. Those are top priority tomorrow.

Agenda for tomorrow:
Fix pump and duck release
Integrate with drumsticks
Make power system more stable
Waterproof the duck

David out

Helm LEDs

Helm LEDs have been soldered onto the LED board. Should be ready to go.

I implemented a simple color code to keep track of what LED is what. Black/white wires are for the stand down LED, red/white wires are for team indicators, and green/white wires are for base indicators. 7-Segment cables have been made and are ready to go. Just need a bit of software and this part should be ready.

We are also the proud owners of a Shamu and Crew lunch box. Looks like everything will fit inside, awesome.

I'm hoping that we can get the whole thing mostly together by the end of the weekend so that we'll have plenty of time to test/break/fix things.
~Laurel

EDIT: Fry's order has arrived! I'll bring it to the lab tomorrow morning/afternoon.

LED shift order

I wrote up a table that outlines the order bits should be clocked into the shift registers. For a given pattern, clock in the bit in column 1 first and work your way to the bit in column 16. (I'm not sure how SSP shifts data. Is LSB or MSB first? Something to look into.) Table can be found in the team folder as LEDshiftTable.xls.

Logic for 7-segment display is inverted, if you want a particular segment on, set it to zero. Setting a segment pin equal to 1 turns it off. Base, team, and stand down LEDs have normal logic (1 is on, 0 off). The sheet of paper with 7-segment drawings and my scrawl all over it might be a bit confusing since the numbering on it is different from the numbering in the table (segment 1 is actually the 16th value shifted in, 2nd segment is the 15th value shifted in, etc.) Probably best to just ignore it and only use the table. Drop me a line if you have any questions. I'll try to be on-hand during programming time for question answering.

LED board is practically ready to go, just need to figure out how long LED wires need to be, solder them in, and pop in the shift registers.

Lunch box has been acquired, just need to mount the E128, xBee, and sensor circuitry inside.

I'm 100% serious about the beer and ice cream being up for grabs....please don't make me eat/drink it all -_-
~Laurel

EDIT: Just looked it up, LSB is shifted first. So all off would be 11111111 1000000 (0xFF 0x80)
Red Team with Blue Base active, no stand down, and craft 3 would be: 00100011 10001001 (0x23 0x89)...I think I'm going to modify the table to show the bit order rather than the shift order...should be easier to understand.

Okay, I was confused. Turns out we can do LSB or MSB first depending on if the LSB first bit is set/clear in the SPICR1 register. I'm not sure how David has it set up (I'm assuming MSB first since that's the default.) The LEDshiftTable.xls file has tables for both situations so we should be covered no matter what we choose.

LED board

Since we have tons of LEDs to power, Benjie and I decided to use a pair of shift registers rather than a ton of pins. This way we can use the built in serial communications stuff in the E128 to control all of our LEDs. I soldered up the board for this, it's a bit of a mess, but at least it's a color-coded one?
Red - 5V
Black - Ground
White - Clock
Green - MOSI/serial input to shift registers
Blue+Yellow - connect shift registers to buffers

We still need to get some HC 74HC164s since the student shop doesn't have any (instead the have the opposite 74HC165...how useless). Dan says they have the part we need at Jameco.

The board was made with wiring in mind, so the LED output order is a bit wonky:
From the top (where the power and ground rails are) to the bottom (where there's empty board).
Right Side | Left side
1 | 5
2 | 6
3 | 7
4 | 8
9 | 13
10 | 14
11 | 15
12 | 16

This shouldn't be a problem so long as we are smart about how we wire up the LEDs (i.e. put all the 7-segment control lines in order). I still need to figure out the pinout for the small 7-segment LEDs (Big ones require too much voltage). Once I get that figured out, I'll add some molex plugs for them to plug into at the bottom of the board.

Oh, long serial data, and power cables have been made. They're hanging by the E128 pinout paper.

I <3 Benjie's sharpies,
~Laurel

Pins from lunchbox to backboard

GND 1
7 seg display: 9
TeamColor 2
ActiveBase 2
StandDown 1
ibutton 3(2?)
Mic 1
Tilt switch 1
BIGREDBUTTON1

Total 21
or (20) if we give up the ibutton led

Hooray molex. >_<

Care for a quacker?

The duck quack for special 1 has been built, coded, and (lightly) tested. Thank you A quarter for providing us with a convenient sound chip from Radio Shack.

The red/white wire are power/ground and the white/green wires are signal/ground. To play a sound, pull the white signal wire low and hold. To play the sound again, pull the white signal wire high, wait a moment, then pull and hold it low again.

All this is already taken care of in software. To play the sound, just send a navigation command with bit 4 high in the Special Actions Byte. Pin A1 on DumbPIC controls the sound.

\o\
~Laurel

Pictures!

Victory dance v 2.0

Now with more beer!

Smart PIC/Dumb PIC setup is working nicely. They both read the xBee transmission line and respond appropriately. Whoo!

We also fixed up the board for the Duck. The battery connection is much more solid now and we've improved the connection to the pump.

David added a better jumper on Blinkyn, so now he's more reliable. Blinkyn, not David.

We were seeing the pump turn on sometimes right on powerup. We think it's software (pulldown didn't help) but we're not sure. It's working now, but we don't expect it to stay that way. We commented out setup IO, iButton, xbee and clrf intcon and uncommented them one by one. Unfortunately, it worked in the end. Go figure.

Green tea mochi ice cream and Mission Street beer are up for grabs. Enjoy~!
~Laurel

Schedule for today

Implement ReadW command (DLL)
Implement multiple read scheme (DLL)
Suggestion: Oversend the address. The smart pic sends 10, the dumb pic samples 3 times.
Each sample is blocking. Once 3 are received, pick either the number that was
repeated, or the last number received if they are all different
Implement smart pic code that sends the number when received (LF)
Incorporate ReadW into dumb pic code (LF + DLL)
Test on breadboard (LF + DLL)
Wire into duck (LF + DLL)
Test on duck (LF + DLL)

Check off + celebrate

David out

Victory Dance

\o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\
\o/

The Helm and craft are talking to each other, admirals, and occasionally the world at large (is someone braodcasting?) We've simulated an entire game with a helm, craft, and "admiral" xBee sending/receiving communications. We've tried all the communication combinations we could think of and it works as far as we can tell.

Today is a good day.

While soldering the iButton connector to the PIC on the craft board we realized that only one PIC can read the iButton. This PIC (henceforth referred to as 'smart PIC') is the only PIC that knows the iButton serial number. After bouncing around a few ideas, we think the best way to take care of this issue to use SSP between the PICS. Once the smart PIC is fully matched with the helm (first valid navigation command received,) it will SSP the address of the paired helm over to the dumb PIC. Meanwhile, the dumb PIC just sits and waits until it hears the address from the smart PIC. Once both PICs know who to listen to, they parse packets as normal.

\o\
~Laurel

Good news, everyone!

Pic code has been tested! It goes all the way through (with simulated inputs) from being pinged, then detecting an iButton, then receiving a message and finding a helm, to receiving navigations commands (with timeout!) And...it does standdown! We're pretty much done on this side!

The helm code can ID all of the admiral commands, but has problems sending. The problem is the extra layer implemented by SendMessage; the receiving E128 can't see all the packets from the new architecture. The old xbee harness works ok, though. All the supporting code for the state machines is present; now we actually need to program the game.

We have acquired an additional E128 for admiral spoofing. If only we could acquire an admiral XBee...

We rock! Let's check off for the whole week on Sunday!

We approve of the outrigger modifications. AWESOME!

David out

Rock and a hard place

Attempts to stabilize the craft:

Attempt:
Added pink foam under to raise it out of the water and strapped a big rock to the bottom.
Result:
More stable, same water profile, really heavy. Likes to spin, hates to go forward. seems to wallow in the water.


Attempt:
Remove the rock
Result:
Super tippy. rollin' all over the place, especially side to side (as always)

Attempt:
Add two outrigger ducks to make it a trimaran
Result:
Much much more stable rolling. Still a little tippy forward, but I think that the bumper should help with that. Plus the tri-duck affair has a classy look (and since it is really the pink foam under the ducks that causes the flotation we can fire them off if we like).

Things left to do for seaworthyness:

1. wait for it to dry and attach pink foam and outriggers with glue
2. attach bumper around all 3 ducks.
3. attach some kind of keel to help the craft drive straight
4. figure out how we are going to keep the inside dry and how/if we are going to try and seal the top

PS: a piece of wire-wrap wire, two alligator clips and a 3 amp power supply makes a great pink foam cutter.

Craft code, redone!

SO...massive restructuring of code for the craft is complete. I ran it through the debugger and it seems to work. I haven't tested all cases, I'd like to sit down with you guys, walk you through it and test all the possibilities we can think of.

The new version is much simpler, all packets are parsed by the same chunk of code rather than each state calling a unique parsing function. The code figures out where to return to using the Exit subroutine (based on the ExitPing idea suggested by Benjie). Exit checks a variable that tracks the current state of the craft (already in place since it's required for a ping response) and figures out if it should return to looking for iButton, looking for helm, or game mode. If it's really confused and can't figure out what state to return to, it just goes back to MAIN and resets.

Checking is now a bit more robust. Admiral addresses are fully checked, both MSB and LSB, instead of just bit 7 of the LSB. MSB and LSB of helm address are also checked. I'm still debating if I want to put in really robust checks for header bytes and/or admiral messages. Checking individual bits is more straightforward, but if a garbled packet gets sent out, the chances of it triggering unwanted behavior are much higher.

Stages of checking are:
Check Header --> Check if address is valid (unless iButton) --> execute command
If an invalid header or address is detected, we just go back to polling for packets

Calls for game setup functions (Interrupts, 3s timer, PWM, etc.) are somewhat buried. They are called right after the first valid navigation command is received from the paired helm. The team LED is also lit up at this time (I arbitrarily assigned pin A1 to Red and A2 to Blue).

Code is saved as code/Handshake/Handshake2.asm and code/craft_v0.asm I'll start messing around with stuff outside the debugger tomorrow...hopefully it will still work.

Successful wet run

The duck drives and squirts water from the virtual helm! Here's our duck after a successful run in ...wait for it...



a dry duck!

We found why we were spinning in circles the other night. Even though LeftPic and RightPic were in two different projects, they were referencing the same set of code.


Things to fix:
1. Duck sits low in the water
2. We can't attain top speed in the front (can't decode 0x80, always 0x70)
3. The left motor is backwards (We have to set it to "reversed" to have it go correctly with respect to the helm settings)
4. Cable to the ship XBee is squirrelly
5. Add LEDs to indicate sending and receiving on xbee boards
6. Resolder connections on the helm power board

Congratulations all around!


David out

Killing me softly with NOPs

Sendshit works now. Problem traced to some kind of timing. We firet got really on the trail when we tried to have the pic send the information asynchronously to the e128 bypassing the xbees. Only every other packet was getting through. weird. Could we be filling up the tx and discarding every other packet? Adding a ton (7-10) NOPs between each byte sent out to the xbee fixes the problem. Yaaaay

(Still confusing as to the root cause..)

Helm ahoy!

Today we built the helm....well the non-electronic bits anyways.
Circuitry for the helm has been prototyped, the drumsticks and microphone work pretty well. Basic software for reading the inputs has also been written and somewhat tested by David's test harness.

In other news, xBee and the iButton are now playing together nicely. The problem was I accidentally used "CALL" instead of "GOTO" when jumping to the CheckPing function. Now that this bug is fixed, the code (saved in Pairing2) can read iButtons even when the E128 is constantly sending and the PIC is calling SendShit in response to those sends. It does not use any interrupts, I'm not sure if we want to try adding them or just let it be and only use interrupts in later bits of code.

Christ I'm an idiot....I wasted not only my day, but David's as well tracking down that problem >_<

While debugging I noticed that the PIC doesn't instantly start printing out received data when the E128 talks to it...it will be silent for a few seconds (5-10) then spew data. I'm not sure if the xBees need some time to warm up or if I'm doing something weird. Although, another team did mention that they were having the same issue...hmmm.

Also, SendShit does not seem to be working properly...When I expect to see the PIC respond like crazy to e128 transmissions the transmit line simply idles high. Also, the improved checksum needs to be added to the code in Pairing2.

Last in the lab, but only by a few minutes.
~Laurel

Still working on the iButton

The iButton and ping response integration is still non functional. I thought I had it working, but it was a special case. The issue is that several packets received in a row will cause the iButton to stop responding.

I tried several tactics, such as not scanning for the iButton after each reading of the serial, but the scope line remains obstinately low or high. When it starts out before any packets are received, it will behave ok. After it receives several packets in a row, it will stop responding. First we tried interrupts disabled, but this did not have any effect.

I'll continue with this tomorrow

David

Go for gameplay?

Code for decoding and responding to messages during the craft's gameplay state has been written. The code seems to work in the debugger, and after a few fixes seems to work alright with the simple test harness. We haven't tested all possible cases, or admiral messages.

While I was coding, we had a visitor.
When implementing the continuous send we were having a bit of trouble getting the craft to act properly. One of the motors and the pump weren't responding to commands. Possible causes include loose wires, weirdness in the circuit board (why can't we keep power properly connected?), and bad code...the usual suspects really.

The float overnight test was a success, there was a tiny bit of water inside the duck, but it's quite possible that was simply water that hadn't dried...sadly I dropped the duck right after checking so it looks a bit wetter on the inside now -_-

Next I think I'll work on writing code to sync with a craft. But I can hold off on this if either of you guys want help with your stuff.

Code for Duck

Assembly code for the duck is coming along, I made the arbitrary decision that since we have on/off water, any water value we get that's 8 or above will turn on the water (easier to code than checking for any non-zero value, not to mention that noise in analog water communications would make our water be on constantly). Not sure if this is the best idea, thoughts?

To send messages, I plan to move the desired ME218 bytes and receiver addresses into specific registers then call a SendShit (yes, I'm actually going to name it that) subroutine that shoves the bytes in order to the USART and thus the xBee....speaking of which, I still need to write a subroutine to calculate the checksum...meaning I should also double-check which bytes are included in the checksum.

Next big steps for me:
1) Finish writing up code for the gameplay portion of the state machine
2) Test it in the debugger
3) Figure out how to integrate David's iButton reading stuff
4) Code up the pregame sync with helm part
5) Test pairing of craft with helm

More drumming thoughts

Here's my scheme to encode two drumsticks and two buttons into a navigation packet.

First, we use Benjie's circuit and the A/D converter to read in the speed of each drumbeat. We encode 5 regions: Stop, Slow, medium, fast, and max as 0-4.

For speed, we take both sticks and add the speed region together. The result is going to be 0-8, so we will scale by 2 for the packet. When neither is pounding, speed is 0. When we're pounding away, it's going to be 8.

For direction, we will first assign a sign to each data, with the button on the drumsticks signaling negative. Then we subtract the numbers. If left is full forwards and right is full backwards, we will have 4-(-4) = 8. If left equals right, we will have 0, going straight. If left is full backwards and right is full forwards, we will have -4-4 = -8. We will then have a number from -8 to 8, we will shift to 0 to 15. This is asymmetric, but we can merge two states in the packet (e.g. turn left slowly and turn left slightly faster will be blended)

Thoughts?

David

State of things:
The wired board controls the motor in the test harness with the pic in either spot. Everything is on it, except the i-button is not hooked up to anything although the led is wired on. Do we want to use a pin for that, so it will blink or something when it is ready to be used? That would be a very minor change. Only other addition is whatever specials we need/want.
Also where do we want to mount the i-button. I'm thinking right in the front and center: in the chest, but on the back would also be a good spot.
I am so excited to type at the keyboard and have the board turn the motor.

I was missing some packets though... don't know what was going on. The testbed said "all packets sent" but nothing would happen until I sent it a few more times... The motor was right between the two xbees but I'd hope that it could deal with that. Is there any other reason for it to be ignored?

Anyway. It is bedtime++

-Benjie

Work assignments

Laurel: Work on packet parsing and PIC state machine
David: Work on helm backbone software and iButton integration
Benjie: Finish duck electronics, start helm construction and helm electronics

Everyone: Think about specials and how to implement

Laurel's tutorial on PWM (as recorded by DLL)

Translated Version:
The PWM is controlled by the CCP1MX and P1Mx pins.
CCP1MX controls which pins are active high. We desired 1100.
P1MX controls whether we drive the motor in full h-bridge mode forward or backwards. Toggle these to change direction.

Pin connections: P1B and P1D should be attached to the motor outputs
When going forward, P1B is held low and P1D is modulated.
When going backwards, P1D is held low and P1B is modulated.

Benjie's code starts with a baseline speed from -8 to 8, then adds the direction (for the right motor) since the direction nibble ranges from full left turn to full right turn.

Our PWM period is 0x80. We write to CCPR1L to change duty cycles.

Example:
0xF8 is our input raw motor speed = -8
Our first bit is high, so we want to go backwards.
Bitshift to upper nibble = 1000 = 128 = 0x80
Which mean we go backwards at FULL SPEED


*********************************************************************



Transcript from Laurel re: PWM Pins

To whom it may concern:

The PWM is controlled by CCP1CON. Note that CCP1M1 is not equal to P1M1. \ (>_<) \
(Laurel is unhappy) So, we want CCP1M to be 1100: The magic combination with P1A and P1c active-High, P1B, P1D active -high. This is set for full H-Bridge control, the P1m1 and P1m0 are 11 (reverse) or 01 (forwards).

CCP1Mx enables PWM by setting bits 3 and 2 high. having bits 0 and 1 low makes it so that it's active high, which assume hi is on and low is off.

P1m control direction and whether it's half bridge or full bridge mode. For full bridge forward, we want *01* for full bridge reverse, we want *11*

Current configuration:
CCP1Mx: 1100
P1Mx: Toggle to go for'ard, back'ard

When it's going for'ard, P1B is held low, and P1D is modulated. Higher high times on the duty cycle means it goes for'ards faster!

When it's going back'ards, P1D is held low, and P1B is moduled. Higher high times on the duty cycle means it goes back'ards faster!

P1A and P1C are doing crazy things. IGNORE THEM!!! (or figure out what they mean later)

What Benjie's code does is calculate duty cycle based on direction. It looks at speed and direction bits. The code is currently written for the right motor. Since higher numbers means RIGHT TURN, it adds direction nibble to speed nibble. The higher the direction nibble is, the more we want to be truckin' forward on the right motor. Speed is baseline, goes from full backwards (-8) to full forwards (8). Thus, we add the direction er...directly to the speed and we get our desired duty cycle and motor direction. Negative number means we, the right motor, are going backwards (Hereafter referred to as RIGHT MOTOR)

To set direction, we set P1Mx accordingly. To set duty cycle, we write to CCPR1L.

Raw motor speed: -8 to 8
Look at 1st bit to set direction.
Bitshift to upper nibble
Our duty cycle is ready!

Note that our PWM period is 0x80.

Example:
0xF8 is our input raw motor speed = -8
Our first bit is high, so we want to go back'ards.
Bitshift to upper nibble = 1000 = 128 = 0x80
Which mean we go backwards at FULL SPEED

Example 2:
0x06 is our input raw motor speed = 6 = 00000110
Our first bit is low, so we want to go for'ards.
Bitshift to upper nibble 0110 = 0x60 which is pretty fast for our duty cycle
75% Benjie, you rock!

Sincerely,
Laurel Fullerton, Mechanical Engineering, Stanford University

Countdown to Victoly!

Laurel and I decided on a modified buffer scheme.

Scheme:
Search for a specific sequence of bytes:

0. Start Delimiter (always 0x7E)

1. Length – MSB (should be 0)

2. Length – LSB (should be 8)

3. API identifier (0x81 for received transmission)

Once we received all these packets, we'll assume that the next 8 bytes are valid and will parse them accordingly. We will need storage space for
Source MSB
Source LSB
ME218 Byte0 Header
ME218 Byte1 Navigation
ME218 Byte2 Special

How things can go horribly wrong:
1. We receive a partial packet while checking for our first 4 states- This one's not so bad. We'll just start looking again for the start delimiter.
2. We receive a partial packet while we think we're receiving good data- This one's a bit worse. The current packet is trash, and the next packet is trashed as well because our parsing is off. The good news is that we'll detect the fact that the second packet is bad because the four byte sequence will be off. We'll ignore the rest of the packet until a good sequence comes in. The strength of this scheme is that we can wait any length of time until this happens; a valid packet
could be 1 ms or 1 s away and we would still be able to detect it.

State progression:




Reason *not* to do the timer:
1. Needs a lot of buffers to store all the data
2. Hard to debug/test: no way to indicate why a packet was rejected
3. Timers are squirrelly

Timing on PIC

While writing up code for the PIC to read messages off of the xBee I asked Paul a simple question that's greatly complicated how we should implement the reading of messages.

The original plan was to read 12 bytes of data and shuffle the useful ones into the appropriate registers. Seems simple enough but it's a bit too simple. This method does not protect against the xBee receiving a partial packet. In this set up, if a partial packet comes through, the first byte of the next packet will be read as a middle byte of the partial packet. The packets will be perpetually off and the craft won't be able to parse the transmissions.

Paul's suggestion was that we calculate the time it would take the xBee to shift in the next byte of data (the byte time) and have a timer that signals a timeout if it takes much longer than the byte time to receive the next byte. If this timer expires, we've received a partial packet so we should ignore the transmission and treat the next incoming byte as the first byte of a new packet.

The xBee has a baudrate of 9600, this means that the PIC receives 9600 bits per second. There are 8 bits to a byte, as well as some framing bits. If we assume 10 bits per transmitted byte, it takes slightly over 1 millisecond for the next byte of data to be shifted in. So we need a timer that's longer than 1 ms and shorter than 0.2 s (the time elapsed before the next command from the helm) a few ms should be safe.

Shouldn't be too tough to implement, except the craft only has one timer remaining and it needs to be used for the 3 second communications timeout timer specified in the protocol. (If the craft does not hear anything from its paired helm within 3 seconds, it needs to shut off all motors, water, special commands and just listen for transmissions.) Timers 1 and 2 are used by the PWM system, so we'll need to use another PIC or be smart about how we use timer 0.

Timer 0 steadily increments a register until it overflows from 0xFF to 0x00. It then throws a flag and does nothing until the flag is cleared and another non-zero value is written to the timer 0 register. This register can be read/written to at any time.

I currently have code written and tested that detects when three seconds has passed. It uses massive prescaling on timer 0 (256) and counts ~230 overflows to time 3 seconds. Overflows are handled with a simple interrupt service routine since they happen almost constantly.

I think we can piggyback the shorter USART timeout timer on the 3 second timer. When monitoring for the timeout we need to first record the current count on timer 0, then monitor the timer 0 register as it counts up. If it counts up a few ms worth of tics (about 20 tics) before the next byte arrives, then there has been a timeout on the USART transmission.

Then again, it might be easier to just look at all the incoming bytes...The first few in a packet always have the same values. 218 data can potentially look like one or two of them, but four in a row? (Start Delimiter, Length MSB, Length LSB, API identifier should be constant across all messages.) I'm not entirely sure how to get back on track using this method...I'll have to think about it when it's not 2 am.

Lessons learned while coding 3 second timer
1) Writing anything to the timer 0 register changes the prescale, this is a pain...thankfully reading the timer 0 register should leave the prescale alone.
2) The W in MOVWF is very important, especially when using it to restore the STATUS register on your way out of an interrupt.

Time to crash
~Laurel

XBee progress

I wired up the red XBee board to talk via a molex connector. It takes two jumper wires:
Tie pins 10-13 9-12

Six pin molex
From top:
+5
From XBee Dout
To XBee Din
x
x
gnd

Four pin molex

From top:
+5
From XBee Dout
To XBee Din
gnd

Helm 03 LED red is burned out; voltages look good, though.
Yellow LED is on (ON LED) , Red LED blinks (Associated) which matches Peter and Ted's.

I finished my send menu for the XBee harness. It incorporates checksums, and to the best of my knowledge is sending at 9600 baud (data appears on the SCI line) Decided not to go for interrupts; don't think it'll take too long or that we'll miss messages. We'll put the receive on an interrupt routine.

David out.

Pump and PWM

Bilge pump has been mounted on the duck, thankfully Benjie had the brilliant idea of hanging the pump by its hose. This way we won't need to worry about kinks in the hose or water leaking into the duck. Best of all, we won't have an unsightly hose on the outside of the craft. \o\

Motors are also mounted, though they still need waterproofing. Again, big props to Benjie for finding a way to attach them other than zip ties. Right now we're waiting for the glue to dry on the pump insertion before we try attaching anything else. I'm thinking we'll be spending the next few days gluing at the start of the day then not touching the duck until the next day when we glue something else. Thankfully we have time to do this without rushing.

PWM is working on the PIC, I've fixed the bug that was causing the duty cycle to always be half of what we expected...I think it was a bank select error.

Communications Commitee draft is now out to the public...hopefully the draft isn't too confusing.

Next big steps:
1) Designing/soldering circuitry for craft
2) Writing assembly code to decode/respond to helm messages - I think this will mostly be motor control and water activation. I don't know if they expect us to be able to send out responses to iButton broadcasts...but I could be wrong.
3) Getting xBee to do our bidding

Oh, a possible useful tool I stumbled across:
Decimal/binary/hex converters: eFunda and Some guy named Ron
The eFunda one is a bit better, it shows the number in all binary, hex, and base 10 across the top...if you scroll down you'll get results up to base 36.
~Laurel

iButton, V2

iButton is up and running on the PIC after much head bashing.

Lessons:

1. Make extra sure to check your banksel
2. Reset flags as late as possible. I reset a flag...then reset some timing registers which automatically set the flag!
3. The PIC executes an instruction in the 600-1000 ns range. Plan accordingly
4. The iButton is very time sensitive, especially in its 5 us pause time.

David out

Waterproofing update

The waterproofing test seemed pretty successful, the adhesives that stuck to the test container did a great job of waterproofing (if we replace the seals that didn't stick too well we'll have an orange juice container to drive around). Since we aren't sure what adhesive will work best on the duck, we cut it open (first blood!) and did a test panel of different adhesives on the inside. Six different adhesives were tested, the one that sticks the best will be our sealant.For some reason the silicone sealant we bought doesn't seem to be sticking to anything...strange since multiple people have told me that silicone would be the way to go...

In other news, the Communications Committee has released a draft B of the protocol. No drastic changes, just a few extra commands sprinkled in as well as a final compromise on the 'special' commands. The Pseudocode has been updated to reflect the changes. Unless Matt has any major complaints about the draft (I don't forsee any) we should be ready to get started on coding up communications shuff.
~Laurel

Using speed and direction to steer a tank

I propose the following encoding:

Helm
The helm has two analog inputs (one from the left stick and one from the right) and two digital inputs from the reverse buttons on the sticks. If you use the digital input as a sign bit you get a signed 9 bit number for left and right (ie -255 to 255). We need to convert that into a nibble that represents speed (0 being full back and 16 being full forward) and a direction that is 0 meaning full right and 16 meaning full left. The first thing is to add 255 to each to make a 9 bit unsigned number.

To construct the speed nibble use:

Speed = (Left + Right)/(32)

I think that divide by 32 should concat to just the 4 most significant bits.

Direction = (Right - Left)/(32)

With this encoding pounding on both drums gets full forward, zero turn. Doing nothing is zero drive zero turn. One full forward one full back gives zero speed and full turn. However you should note that with our helm it is impossible to give a full forward and full turn command. I don't believe that this is a fault of the encoding, because I cannot imagine a drumming pattern that I would expect to give that output. To turn you have to slow down. I think this is fine.

Boat

if we interpret the number coming in as -8 to 8, we need to extract a -8 to 8 value for each boat motor.

Left motor = (speed - direction)|limited to +- 8
Right motor = (speed - direction)|limited to +- 8

Incidentally I don't think that our helm will ever require the limit to +-8. I think that it is inherent in the limit in the helm and boat because we are doing tank drive. In the same way what does a drive-rudder boat do with a zero speed full turn? I'd have to think harder to be sure but I think what I said is true. Anyway: whaddyathink?

Microphone

Progress on the microphone as a digital input:
We now have a circuit that takes the two mic leads and outputs a digital signal that can be interpreted as "whether someone is/was recently screaming into the mic.

Here is the signal processing/circuit overview

1. Input signal is the microphone input which I assume to basically be a sin wave centered at ground
2. run through an inverting amplifier (gain of 22), this gives a bigger amplitude and saturates all voltages below gnd.
3. the output of that is run through a diode to charge a RC circuit (R = 1M C = 10uF tau = 0.1 sec)
4. This is run through a buffer
5. and into a standard comparator with hysteresis circuit for a clean digital input.

It's pretty nice in that complicated words usually come out as just being one digital signal for the length of the word.

Also the zigbees are soldered. yaay!

More todo list!

Here's what's keeping me up at night:

Power system design
Pinouts on PIC and E128- Breakout board?
Write code to translate drumbeats through A/D to direction commands
7 Segment display and driver for helm

We can hit these pretty hard even before the communications flurry dies down

David out

Waterproofing test

We're going to need to cut holes in our beloved duck eventually, we should make sure we can plug them before we go too far. Here's an idea I had:

1. Cut holes in a sacrificial Tupperware
   
2. Run cable ties, wires, whatever we think we'll need to run through holes in the actual craft through the Tupperware holes
3. Plug up/seal the holes - we might want to try multiple seals
   
4. Float Tupperware and look for leaks

Other crap to tackle:

• Sending basic messages with xBee
  
• Maybe practice sending/receiving iButton serial numbers once David gets iButton reading working on PIC
  
• Cutting water hose to length and checking pressure of squirted water
• If there isn't enough pressure to squirt water up/over edge of goal, we'll need to design something to hold the nozzle at the right height
• Figure out what specials we want and how to activate them
• Waiting for Comm Committee to make final decision on number/type required >_<
• Solder up H-bridge for controlling submarine motors. We'll need it eventually, might as well get it out of the way now
• Figure out/mess with PWM on PIC
• Make final decision on if/what small ducks we want to order
• Current calculations on submarine motors and pump...along with whatever other sample calculations we can think of
• Remember to eat/sleep
  

Code that isn't

Pseudocode for the helm, craft, general read/write from xBee have been written and are in the team folder. The pseudocode outlines the big picture of what helms/craft should do throughout the course of the game.

Pseudocode for how the craft should respond to commands has not been written (i.e. how to calculate motor PWM duty cycle based on speed/direction commands). This is mostly due to the fact that it's quite possible the communications committee will completely revamp what/how commands will be sent (especially in regard to special commands and water commands) at tomorrow's meeting with Matt.

A document containing all I know about xBee has also been added to the team folder. I have (at least) one question for the teaching staff:
-Will we need to send any configuration commands to the xBee chips (i.e. programming in our address, setting it to API mode, etc.) every time the craft/helm boots up, or is this already taken care of? I think Karl already programmed in the addresses, I'm not sure if the other parameters of interest were also taken care of. Especially since we've covered how to configure the xBee in lecture.

If someone remembers to ask this before I get a chance, let me know.
~Laurel

I, Button.

iButton reading on the E128 is up! The code is in our project directory/currentcode/ibuttonTest

Here's the good news: you load the .h and call ReadSerialNumber() and it works!
Here's the bad news: it's blocking and a little bit squirrelly when you break contact with the button. But the first value seems pretty stable or we can do some filtering or majority voting to fix it.

Here's a small Q &A

1.What is the iButton?
DS1990A Self timed memory storage device
2.What is the iButton reader?
Reads data stored on iButton
Serial transfer on half duplex line (tx or rx, but not at same time) within "discretely defined time slots"
Translation: The clock rate is set, we're doing asynchronous communications
CMOS open drain output, needs 5 kohm pullup
3. How do you power it?
Parasitic power: it steals power from the data line
4. How do you connect to it?
1 data line, one ground line
5. How do you signal you want data?
Commands and data are sent bit by bit (starting with LSB) based on timing
Synchonization based on falling edge when master pulls line low (kind of like slave select...)
33H or OFH (That's the only command)
6. What kind of communications does it use?
Asynchronous style over a regular I/O pin

A big thanks to Laurel for solving my command problem!

Tomorrow: time to program it on the PIC

David out

To Boldly Go (tm)

Our test was a success! Our duck moved quickly enough on two motors (even loaded with one battery and the bilge pump) that we decided they were sufficient for propulsion. We will use two PICs; one for each motor.

Go duck!

David out

Design review

The duck arrived!

Testing:
1. Strap motors to duck, put on bilge pump, see if runs
2. Benjie: Mock up mike circuit, see if triggered by drums
3. Order ducks ASAP
4. David: iButton reading
5. Laurel: Pseudocode for what the duck will need to do

David out

Monster Duck

I checked the tracking and it is supposed to arrive today!
I just checked and it's not here yet.... boo

Drum sticks:

I have decided that I speak in Georgia Font:
As we saw yesterday drumsitck prototype works pretty well.
For the sake of completeness:

• 16 inch aluminum tube
• 5" stiff bare wire
• little blob of foam core
• electrical wires

push the stiff wire through the foam core, and solder the electrical wire to that end. carefully thread the whole thing through the aluminum tube so that the electrical wire comes out one end of the tube and the stiff wire sits in the last five inches of the other end, not touching the sides. Tape another wire to the outside of the tube near the handle. When you strike the stick the stiff wire bends and touches the inside of the aluminum tube, making a connection. This is used to charge an RC drain so we have a basically steady voltage that goes up the more often you hit and slowly drains otherwise. Sweet.

Possible future improvements: use a spring that is less likely to bend over time and touch the side.

Design meeting highlights

1. E128 helm, set of pics at the boat. All the pics listen to all the commands and respond accordingly
2. Fans do not work well, even with ducts. We could try to find an additional Mako submarine for additional motors
3. Without the 12V DC motors and fans, our equipment weights 3.4 lbs, equivalent to 1/2 gallon of water displaced
4. Considered increasing/decreasing drag by lowering objects in the water to steer

David out

OMG options

So...it seems there are quite a few options when ordering 2" rubber ducks
Plain rubber ducks for ~$1.00 each
Insane variety of themed ducks for ~$0.50 each
If we order the Christmas Carol ducks, the price drops to ~$0.25 cents each

In other news, the communications committee seems to have reached a consensus on how the game will be implemented. There are still a few hotly-contested topics, especially the number of bits/inputs that should be associated with special craft functions. Some teams want to implement lots of special features while others are reluctant to add extra requirements to the project. We should be able to finish up a draft of the communications protocol by tomorrow's deadline since most of the issues are relatively small details. I just hope that our protocol doesn't screw over the people that need to implement it...I wish we had more feedback on whether or not we're being stupid -_-

~Laurel

Pon Pon Pata Pon

I'm playing around with sensors to detect when the drum is hit. Currently I'm looking into magnetic switch sensors on the drumsticks and magnets on the drum. The sensors work pretty reliably so long as they get close enough to the magnets. If we use these, we'll need 'HIT HERE" labels on the drum and the stick covers can't be too thick. Otherwise the sensor will be too far away to detect anything. I'm looking into how far is too far and I think distances less than ~1 cm should be alright.

Though I just realized that the user can achieve max speed commands by simply leaving the sticks in contact with the drum....hmmm.

~Laurel

SSP Woes

I believe it was a timing issue. It seems to reliably communicate now!

Next stop: iButton reading.

David out

Communications Committee - Day 1

I'm making my entries in brown Trebuchet font...because I can...

The Communications Committee made some progress, though not quite as much as I'd like.

Main conclusions:

• All admiral commands will be processed by the helms. Crafts respond only to helm commands.
• Project-specific data will be sent in two bytes
• Byte 1: Speed (4 bits) Direction (4 bits)
• Byte 2: On/Off (1 bit) Water on/off (1 bit) remaining bits are reserved for 'special' commands

Stuff we need to figure out:

• Does the received packet contain the sender's address (I think it does) or does the XBee board strip that off and only transmit the data bytes?
• Confirm iButton sync, what's hard-wired/in look up tables what needs to get sorted out initially
  
• We think only red/blue affiliation for each iButton will need to be looked up. Helms/craft will need to transmit/listen for the serial number that matches the one on the iButton they read.

Stuff people are working on until next meeting

• Cornering TAs to talk about XBee and iButtons (I'm working on this with Matt)
• Write up 'Communications Story' outlining what needs to be said when and by whom
  
• Sketching up state diagram of how communications will be carried out
  
• Specifically assigning bits to commands

More updates as we figure stuff out...I plan to read through the XBee user manual tomorrow to see what I can figure out before cornering Karl.
~Laurel

SSP/SPI

I spent the evening reacquainting myself with the SPI interface. The goal was to create an SPI PIC debugger with the E128 slaved to displaying information from the PIC. I have partially succeeded; communications are occurring, but the PIC is not successfully reading its own BF flag (buffer full).

I am currently managing the slave select line myself on the PIC. It should transmit, then set the flag high when the last data is shifted in. Problem is, it never does. As far as I can tell, the BF flag in the status register is never set, and the next transmission doesn't occur.

Ways to approach:
1. Hold SS low all the time for the debugging process
2. Put out the state of BF to a pin and watch it on the oscope
3. Check what the state of BF is normally and verify it does stay low.

Goal for tomorrow: finish debugging, take a look at the iButton. If ambitious, dump the iButton number onto the bus.

David out

Briefing

Goal:
The goal of this project is to provide a framework in which you can apply your knowledge of microcontrollers and multiprocessor communications to a task that will provide an enjoyable experience for the users and the observers.
Purpose:
The underlying purpose of this project is to provide you with an opportunity to gain experience in integrating all that you have learned in the ME218 course sequence, with an emphasis on the new material in ME218c.
The Task:
Design and build a remotely operated Water Craft and a companion Helm (remote controller). Groups of Water Craft will operate in Terman Pond and cooperatively strive to protect their own Base and neutralize the opposition’s Base.

Supply Run

Laurel and I made the first supply run for the SS Ducky yesterday. It was a resounding success!

Highlights:
1. Submersible submarine motors we can use to turn the duck
2. Beefy computer fans we can use to propel the duck
3. A bilge pump that shoots water at 600 GPH, plus the necessary connections
4. A pair of DK bongos we can hack to prototype the helm
http://en.wikipedia.org/wiki/DK_Bongos
5. 2 accessory ducks for flotation
6. Microphone
7. Various PS2 and PSP games which have been placed under lock and key until "we make it through this"
8. Various waterproofing means (silicone adhesive, silicone tape, liquid electrical tape)

Late night testing reveals that the submarine motors, fans, and bilge pumps all function satisfactorily at 12-14 V. Sweet.

David out

Preliminary Sketches

...also known as what Laurel does to put off working on her other classes.


Click on thumbnails for larger image