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

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. >_<

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

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.

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..)

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

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

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.

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

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

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

SSP Woes

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

Next stop: iButton reading.

David out

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