So Tired

We've been awake for 40+ hours.  But the boat and controller are working great!  Pictures and video to come.  Presentation tomorrow!

When Hulk and Thor decide to smash something ...

... It gets smashed. Here's our controller. Half the team non-stop for five days - worth it. Behold.

Science!

Check out all of our boat and controller electronics (minus compasses) working!

Reporting For Duty

An army of MOSFETs to run our 8 fans.  And some voltage regulation on the left for PICs and the servo.  This board should handle all of the boat-side power distribution.

Final (?) Design

We hate the balloon, so we've decided to drag it on its own raft.  The raft is constrained radially but not tangentially so it will rotate to be at our "aft" no matter which way we drive.  The bumper is low now - at the water line - to keep it away from our fans and poppers.

Off the pot. Onto the compass.

Instead of a synthetic potentiometer input, we now have engine light-up (well, LED light-up) running with real live compasses.  Jubilation prevails.

Only downside - the code has to be fine tuned for each individual circuit, which has to be fine-tuned for each individual compass.  But, four unique bin levels isn't all that bad.

I just hope the boat's vibranium coating will cut down on signal noise like we expect.

Switch -> LED. Emphasis on the '->'

We have a functional balloon monitor!  One of the more ridiculously complicated switches I've seen.  Some really subtle bugs, and at least one fantastically stupid one.  On to real project stuff!

Woot.

Compass + Command = Light Engines

Hey folks.  With simulated compasses (pots) and a simulated command direction (switch input to port B), we now have code that outputs the correct engines to light up.  Aw yeah.

Accelerometers on a PIC

Well, just one accelerometer, I guess. While trying to write the whole controller code at once, I realized it would be wise to break it into pieces... and then spent way too long trying to get the accelerometer to play friendly with a PIC. Here you go.

Its Official

 

We love this park.

Glasses

Got 2 layers layed uo with a band around the top for extra hoop strength (hoop strength is my new rap name, btw.) placed it face down on a piece of aluminum so that the lap line is flat for a gasket.

Cheaper is Better

Thanks to Russell and Co, we got our hands on a $3 Jameco brushed motor.  Thanks to an anonymous donor, we got a broken boat propellor.  Thanks to superglue and a power supply, we found a solution to our problem.  Woot.

Turbines to Speed

We tried out the fans today - and got a little nervous.  At 14 volts, we were making small corrections to the direction we were being blown by the wind.  Upping the drive voltage to 21 volts helped:

Small awesome motors helped more:

But they cost twice as much.  And we're still not super responsive.

Basic A/D module

I have a basic A/D module written up.  I left justified the input so ADRESH can be read directly as an 8-bit value.  Outputs 0-7 on 3 LEDs (connected to C0-2) based on the input voltage to A0.  It's saved in Code -> PIC Code -> Analog_to_Digital_Basic.asm, so feel free to use it as a reference/base if you're writing A/D stuff.

Here's the video:

And now there's also a version of the code which does the same thing but slicker - with tables: Code-> PIC Code-> Analog_to_Digital_Basic_Tables.asm. Also a good place to start for this stuff.

Compass Maths II

The arrangement of our fans determines how finely we can control our direction.  With eight evenly spaced radial fans, we can create motion in sixteen unique directions using simple on-off control.  We can either turn on four fans at once, which gives us eight useful combinations, or three fans at once, which gives us eight more distinct combinations, for a total of sixteen drive directions.  More resolution would require fine PWM control and a lot more math.  At present, I'm happy with sixteen. 

The direct result of this known resolution in drive means that we need to be able to determine compass heading to the same depth of resolution.  The figure below includes a table of the different values expected from the compass if we could receive a noise-free signal at each of 16 different headings.

However, this direct interpretation of results is very sensitive to small distortions in signal.  As you can see from the second table, distinguishing between the maximum signal strength and the signal strength from a slightly off axis reading requires distinguishing between 1 and .92.  And determining where to make the decision as to whether the signal is a 1 or a .92 is not in itself straightforward.  One could simply split the difference between the two, but that imposes a linear assumption on a function that is markedly curved at that point.  Since it's a sine wave, you could split it at the angle halfway between the two readings, and this is what I've done in the smaller table above.  However, this only leaves the signal between .98 and 1 as a legitimate "1" value, requiring stable signal resolution down to 1% of the full range.  This is not ideal.  Additionally, since 9 distinct values show up in both tables, it's also over-kill.  Two 9-valued inputs have 81 distinct combinations - we only need 16. 

The solution I've come up with is to make coarser distinctions between values.  Ideally, we could cut the possible inputs into four ranges in such a way that our outputs would span all 16 unique combinations.  However, I have not yet found a convenient way to do that.  I did find a way to split the signal inputs into 5 ranges, making cuts in the places where the slope of the function was steepest and the distinctions were clearest.  In this model, all values above .55 are lumped together as "++", all values betwen .55 and .20 are "+", all values between .20 and -.20 are "0", all values between -.20 and -.55 are "-", and any signals below .55 are "--".  As you can see from the corresponding tables below, this makes for much broader, less noise-sensitive detection bands while still creating a unique map from signal in to direction out at a resolution of 16 headings/revolution.

So, there you go ... compass maths produces 16 unique headings.  Now that we have those headings, we can map a heading input to which engines should be turned on.  The following table shows which engines need to be turned on based on a goal direction from the controller (top row) and a knowledge of the boat's current heading (left column). 

It looks intimidating, but it turns out to follow an extremely simple and predictable pattern, which is summarized in the table below.

And that's the current state of the art for compass maths.  Next task - combine x-y accelerometer data and controller compass heading information to produce North-South and West-East 8 bit transmission values.

Das Boot

The current state of our mechanical design.  A servo in the center rotates to flick all the poppers up. They normally rest in cutouts in the foam float. The 8 radial fans allow us to strafe in any direction. The two tangential fans allow us to pivot.  Some bumper interference and a location for the balloon are the main issues right now.

Compass Maths

So I sat down yesterday and tried to figure out how to use our single-axis compass give us the information we want.  Assuming that the (scaled) output ranges from +1 (we're aligned due North) to -1 (we're aligned due South), I discovered that it will require two single-axis compasses to give us the information we need.  Included below are the diagrams of how this works, including two ways of mapping inputs to outputs.  Pretty fantastic.

Accelerometer Tests

I got an accelerometer Monday morning and have been trying to understand it by prototyping with an Arduino. Got a little visual display running in Processing to test the control system. In this demo, tilting the accelerometer adjusts the speed of the ball on the screen.

Takeaways:

• We need to set a "dead zone" where the boat won't drift left or right.
• We need to have an indicator of when the controller is level.
• The accelerometer currently controls a fairly tight speed range - this might need to be expanded.
• It's a bit twitchy - expanding the speed range and then breaking it into discrete steps could help this.

Initial Fan Boat Test Inconclusive

While this test didn't provide much information, it made up for its lack of results with a high risk of electrocution and death.

Xbee Wonderland

The Xbees are soldered and blinking... but not talking. We're currently stumped and are basically scoping whatever is possible.

Concept Art

Here's a look at how a general HZV can operate.  Communications committee - take note.

With this in mind, here's a rough sketch of what kind of information is transmitted back and forth between HZVs and LUCs

And based on the project specs, here's a rough draft of the LUC state chart.

Opening Day: Brainstorms

Our first brainstorming session ranged from the awesome (the Millenium Falcon) to the unacceptably boring (pink foam) to the legitimately cool (spinning mace of death - not trying to be ironic here).

In the end, we decided that making our boat as simple as possible was the best way to relieve stress, while making our controller as awesome as possible was the best way to funnel the cosmic fury of our collective vision.

The picture below represents the only evidence we left behind.

Welcome to the Project

Completed Lab 10 today, looking forward to the project.  It's all looking up from here.