The sonar and display are operational

I added a new command to the BS software - "display a char on the display". Passing a whole string does not work since I (A) run of out registers and (B) each command must have the same number of parameters to prevent serial interfacing troubles. Since I can only pass one char per main loop execution texts arrive pretty slowly. But, it works!

Tidied up the BS software. Removed superfluous variables to free up registers. Tidies up code. Improved variable names.

I put the ping (distance) sensor on the web cam turret, wrote a program that slowly turns the turret while recoding distance measurements, and added a panel to display to display distance depending on the turning angle. Voila - a sonar!

The resolution is pretty course, through: the sensor is able to measure distances down to the centimeter (I checked this with a large flat surface), but the "beam" is quite wide meaning details get "blurred". Still, this is good enough for picking out obstacles over a 180°C angle, and determining which direction is the best to go.

Improving communications

Removed lots of PMD and Checkstyle complaints. Create own PortCom class to encapsulate repeatedly needed COM functionality, especially blocking reads with time-out. Added calibration functions to the servo class. Refactored the package structure (less deep, and more meaningful). Put simulation classes into their own package. Debugged the SensorIntegrator. Added an optional "return to zero" function that decays the current value to 0 when the input value is 0.0.

Created x and y component sensors for the POV switch. Did not realize the "idle" position of the POV switch is indicated by a negative value, not 0 (which stands for "Up"). This caused the integrated value to run away, and the "idle" position was not recognized properly.

I noticed that steadily increasing servo position values resulted in jerky advance of the servo position. Fixed problem with transmitting servo position: I had created a command string using "+ char(value)" to add byte size values, and used String.getBytes() to get a byte representation to write to the controller output stream. This goes wrong for a number of values: the default encoding seems to get into the way. Now, I still use a string converted to a byte array, but I change the values in the byte array, not the string - works! This inspired me to try again for the baud rate switching of the servo controller (see below).

Increased the integration timer tick from 20 times to 50 times per second (decreased loop delay from 50ms to 20ms), surprised it worked at that rate. The value changes much smoother now.

Managed to switch the servo controller to fast baud rate, though I'm never able to receive the complete switch confirmation message (the last byte is always missing). The software detects by time out if the controller is in slow mode, and tries to switch to fast mode accordingly. The result: the reaction time of the servos has clearly improved (really smooth movement closely following the stick input).

Full end-to-end hardware integration

Today I created the software components needed to encapsulate the computer to Basic Stamp communications. At the center is the Basic Stamp device class with its endless receive/send loop thread. It receives messages from the BS and sends queued commands to the BS.

Incoming messages get decoded and change the value of sonar and compass sensors. The latter is a special sensor which combines x and y components into a single angle value. The compass sensor just passes on the angle. Later, calibration will be handled by the sensor as well.

On the other side BS output actuators for the masts white and blue LED groups translate value set requests into I/O output commands for specific pins that get queued and executed by the BS device class.

I had to merge the InputDevice and OutputDevice classes to allow for sensors and actuators attached to the same device. This required a bit of dickering with the code, but went smoothly. At one point I hit a snag when the ACmotion class got instantiated, and then instantiated itself once more - singleton with unprotected constructor :-( The effect was a serial port being requested twice, which did not work.

Sorting out communications

The glue did NOT work - "Epoxy rulz".

After lots of testing with the BS editor debug window and the Windows standard terminal program I realized this problem with the BS not seeing data being sent by the Java program had to do with the Java program, unfortunately. Didn't I read somewhere about one stop bit not being enough? In a final desparate attempt I set the number of stop bits to two, though the port was set to one, and - it worked.

Some Googleling brought me to BASIC Stamp RS232 serial notes. It seems that between reading the three vars (or the individual chars? - DEC foo requires some medium intelligent parsing) the stamp needs to do some thinking, and that takes longer than the one stop bit takes to be sent.

Now I was able to successfully send commands to the BS, switching the mast LED groups on and off.

Power controller board. In my treasure chest I found some screws long and slender enough to fix the luster terminals to the board, and after drilling 9 holes by hand everything was neatly in place. Much better!

Basic Stamp, this is Java calling

Finally: communications between the Basic Stamp and the Java program. I started out with getting the Basic Stamp code into shape. I had copied together bits and pieces from the test programs I wrote last year. Now, the code got sifted through, and the sonar and the compass send decent messages via the DEBUG command.

Looks good in the BS editor debug window. Then I wrote a Java test class that receives messages from the Basic Stamp. First, I got bits and pieces because the messages weren't properly separated. Now each messages is followed by a newline, and input is read line by line.

Works! Next step: Receiving messages from the Java program. I played with the SERIN command, and it took about 2-3 hours before I understood the following: The Basic Stamp has no input buffer. It the Java program sends data while the stamp is not listening, the data simply is lost. Solution: The stamp signals "ready", and after a short wait the Java program send its data.

This worked from the debug window and the Windows standard terminal program, but not with the Java programm. I got rare and sporadic results when I put all three read operations into a single SERIN command (command code, argument, and value), but this did not really work.

Further: I glued the luster terminals to the board that holds the power controllers - let's see if the glue (not epoxy) works.

Renovation of the power grid

Realizing the AMP plugs don't really work (too much unisolated parts even after using lots of shrink tube, too many loose cables) it redid pretty much all electric power cables in the ship.

• The batteries got nice Tamiya style connectors, and thick (ex-loudspeaker) cables: no exposed contacts, fits only one way (no polarity mix-up).
  
• Groups of luster terminals connected to Tamiya plugs for the batteries now provide 6 slots each for GND and +6V, and 4 slots for +12V (combination of two batteries in a row). The "power busses" connect to the inputs of the three power controllers.
• Luster terminals to connect the power controller output with the engines.
• The bow thruster cable got extended.
• The stern thruster cable got shortened.
• The main engine finally got a cable.

This required some serious 75W and 25W soldering (25W don't heat thick copper cables enough), AMP plug removal, cable cutting, insulation removal, and took me the whole freaking day. I'm happy with the result, though: now I can use the joypad to run the thrusters left/right front/aft, apply power, and steer. Cool!

New sensors

I wrote a sensor which encapsulates another sensor, integrating its value over time. A central ticker provided ticks to all integrating sensors. At each tick (currently 10 times per second), a portion of the input sensor value is added to the output sensor value. The portion can be selected.

A couple of days later I spotted a nice idea on the net: as long as the input is 1.0, the value keep increasing/decreasing. As soon as the input is 0.0, the value (slowly) returns to zero. This eliminates the need for a "zero" key; otherwise in example neutralizing a rudder would be difficult.

The purpose of the integrating sensor: digital 0.0/1.0 input in example from a keyboard or a digital joystick (like the POV button on the joypad) gets translated into pseudo-analog input. I created keyboards sensors which now can be used to in example steer the ship with W-S-A-D BF2-style :-)

8 servos are too much

4 standard and 4 mini servos I connected all 8 new servos to the servo controller (which already served the 2 cam and the rudder servos), and saw some electric Parkinson happening. As soon as I tried to control one servo all others started to adjust their positions erratically. Hm, why was that?

I started disconnecting the servos and found that a total of four worked OK. After some research I found a standard servo pulls up to 0.6A. Oops! I seriously doubt AAs deliver 11 x 0.6A = 6.6A without some dent in the output voltage...

It seems that when too high a current is drawn the voltage drops significantly. The servos interpret this as a change in position (after all, position gets measured as a voltage drop over a variable resistor), and an adjustment orgy ensues, with more servos moving and more current being drawn, until complete breakdown of civilized behavior.

Either some D batteries are due, or I better use the 8 new servos in a stationary project with a PC power source (a 300W supply with +5V/12A should suffice).

Serious shopping

Lead battery charger Shopping at Conrad at Mainz! I bought 4 micro servos, 4 standard servos, 5 Tamiya style plugs, a lead acid battery charger, a multi purpose measuring instrument, a quadruple AA battery holder, a servo cable extension (for the rudder) and - that's it, I guess. The servos were cheap (8 Euros a piece); I somehow felt inspired using them for an arts project or something.

Making a stand

No, no revolution in progress. I just found some plywood in the Sperrmüll (big items garbage collection) and used it for making a stand for the boat. Purpose: Avoiding scratches in the gel coat (once its on), ditto in the underwater windows, keeping propeller and rudder from touching the ground.

Building the software

I started writing software that communicates with the Parallax servo controller. First, I had to get accustomed to the Comm API. Things I encountered:

• There seems to be a Sun and a Gnu version. I work with the latter since this works with the GPS (tried that out some time ago).
• When I read the response to a command, I get fed my own command as well.
• It takes some time to get a reply. I actually keep polling the number of available chars until I get what I'm supposed to get.
  
• I first used an unspecific comm adapter class, then changed to a specific serial adapter class. Much better: more options, including change of baud rate.
  
• Alas, changing the baud rate does not work. I send the change command, change the port setting, and can't send or receive anything after that. For the time being I'm stuck to 2400 Baud.
• At some point the serial port was not available any more. Ran into massive USB to serial driver problem. Tried a lot of things (Windows kept telling me the most current drivers are installed, and that the USB device is not recognized), than this worked: Installed the new FTDI (?) 2.0 drivers as EXE, not ZIP. Disconnected the USB cable on the board side - on the computer side did not help (what the?!).
• Sent commands to rudder servo, but only half of the command were executed. Reason: Aaramp rate of 0 does not seem to work! Then, of course, if commands get sent rapid fire the commands don't get executed one after another only after the previous command has been finished, but as soon as possible. That makes sense; you don't want to wait for the servo to finish a turn if you changed your mind in between.
  

So after all that, querying the version ("1.4", not described in the manual!), sending servo commands, and polling servo positions does work, albeit at 2,400 Baud, and with a ramp rate of 1. Next step would be communicating with the Basic Stamp. On the other hand, none of the functions the BS provides is needed for operating the ship "with no brains" (i.e., no compass).

Found nice plywood leftovers in the Sperrmüll that I will convert into a cradle for transport, display, and work.

To Do list

This list, of course, will change over time, but a permanent link to the page will be provided in the side bar.

• Simulate physics of rudder
• Figure out of WLAN can be used to create a home-brew differential GPS
  
• Implement fail-safe mechanism when heartbeat is missing
• Get black foil to cut out letters for "AC.motion"
• Check range with laptop and wireless USB adapter with both laptops in park
• Get resin filler to fill concave corners on stern before applying fiber
• Fill concave corners with thickened resin, self-made shaped spatula
  
• Build gear for rudder and servo connection
• Decide on positioning of Ping sensor (on web cam?)
• Problem: Plugs on mast cable won't fit through hole.
• Plexiglas window in lid for LCD display? Another thought: Keys that can be operated from outside, serviced by Basic Stamp?
  
• Figure out what struts are needed to fix stamp to front board, LCD display to lid, Ping sensor to cam
• Check out effect of lid on GPS reception
• Buy dual channel A/D converter, to measure battery voltage via a voltage divider
• Buy relay to cut off power through Basic Stamp when BS receives no heartbeat messages
  
• Is there a Java API for BlueTooth, and what is the range? Could be used as backup
• BTW, the Basic Stamp could connect to the servo controller through the serial interface, assuming USB and serial operation can be done in parallel
• Water sensors (how)?
• On start up of Loihi, launch "operating system" (the AC.motion on board software)
• Use beep codes, LCD display output to "illustrate" start-up and current state
• Web interface to ship state for monitoring, "onlookers"
  

Done:

• Increase number of parameters (chars) when talking to BS -> changed to binary transmission
  
• Buy 1-2 Notebook QuickCams (Notebook Cam is out of production :-( bought "Live" cam)
  
• How could I use the Netgear improved range stuff with a laptop (that is, on battery power)? (did some research; 05.08.2006)
  
• Add clean ports to Basic Stamp for power
• Write Basic Stamp communications module (26.07.2006)
  
• Power bus, fixed on board to reduce cable salad (see point below)
  
• In general: plug system is not safe (too many blank parts; solved by using luster terminals; 23.07.2006)
• Extend cable to front thruster, shorten cable to rear thruster (done; 23.07.2006)
  
• Give Basic Stamp proper serial connector (pins on board, a pin/serial plug cable; did just that, works find with USB to serial converter and laptop; 23.07.2006)
• Main switch to disconnect battery poles (solved by adding Tamiya style connectors to each battery; 23.07.2006)
  
• Check if +5V power is connected to the right pin of the Basic Stamp (it is - either apply 5.5 to 15V on the unregulated pin, or 4.5 to 5.5V on the regulated pin. 22.07.2006)
• Create integrating sensor that adds up digital input over time (22.07.2006)
• Program key sensors as fallback for the joystick (see point below)
  
• Create keyboard input sensor as joystick fallback (22.07.2006)
  
• Charger for lead acid batteries (bought at Conrad)
• Buy servo extension for rudder servo (bought at Conrad)
• Build cradle for ship for work, display, and transport (i.e., rudder and propeller need to be protected and free)
• Redesign software components

Test-rigging electrics, material tests with gel coat

I drilled a couple of holes into a piece of plywould covered with gel coat. Found that wood bits cut smoother holes than metal bits, which tend to "rattle" when cutting into the top layer, while the wood bits cut into the resin cleanly.

Currently it's way too warm to work with resin: above 30°C the gel coat hardened in half the normal time, and gluing in the drive shaft with epoxy glue almost ended in desaster when the stuff thickened rapidly after mixing resin and hardener. So I test-rigged the electrics and electronics, and, boy, it does get crowded inside.

Test-rigging electrics. In order to get a away from free floating components I cut out a small board which now holds in place the three power controllers and the servo controller, and will be placed on top of the two 6V lead acid batteries. Much better, but still too many loose cables. A nuisance: the rather large ferrite bits at both ends of USB cables. The Basic Stamp and its components will need a similar board which would sit on top of the 12V battery.

Fired up Loihi (the board computer), and successfully tried out the servo controller. I first could not remember how servo power is provided, but this is conveniently done by the main power controller (and now I remember why I disabled power supply by the two thruster controllers). I could communicate with the Basic Stamp; looks like a loose COM cable. Some decent connection system is needed, and that applies to every connection on board.

Main engine mounting. At some time during this week I finished the main engine mounting, cut a hole into the stern (using the 3D model I created with SketchUp as a guide), and glued in the drive shaft. At 30°C the epoxy resin gellied after 3min!

Working the gel coat

The gel coat hardened nicely into a rock hard service. End the end it was quite runny; the top surfaces look better than the sides. On the top, the fabric is hardly visible; on the side, the fabric is clearly visible, and overlapping fabric sticks out. So, sanding down the surface before applying the gel coat will be important.

Then I tried to sand down and polish a sample. That worked quite well, though I probably want a small electric sander since the surface is pretty hard. On the other hand, by the time the surface was smooth is wall almost gone, too. This implies two things:

1. Smooth the surface before applying gel coat. This implies that I should use two layers of fabric; otherwise there is nothing to sand down.
2. Use two layers of gel coat. It's a good question if I should sand down and polish the gel coat - the surface looks very nice as it is (glossy), and should look even nicer if the base has been smoothed. It does not need to look as smooth as glass for me!
   

Gel coat trials

Tried out the gel coat today. This is a special died-white resin for applying a final, UV-resistant finish. I sanded down the web cam turret a bit (not to complete smoothness), and prepared 27g of gel coat.

Gel coated cam turret The stuff was quite a bit more runny than I thought, and definitely will run and collect on edges. I painted the turret, and had quite a bit left over. I applied some get coat to the inside of the boat (the slats the hold the lid in place), and covered a piece of plywood for cutting and sanding tests. After 20min (it was 30°C) the stuff became very much like cold honey, but still even course brush strokes became absolutely smooth.

The next day: The stuff is rock hard. Filing works. The structure of the glas fiber shines through quite a bit, so sanding to smoothness is mandatory for smooth finished. Especially the overlapping parts are very visible. I noticed "pin holes", the leftover of small bubbles. They are probably the result of retouching the surface when the gel coat became goey.

Still, the end result is going to be very nice; the plywood sample looks very decent, albeit a bit "wavy". I curious what sanding and polishing will do. If this all sounds a bit negative: if the whole ship is going to look like the web cam turret, I shall be happy with the result.

I'll have to to some research on:

• How many layers of glass fiber should I use (probably 2)
• How many layers of gel coat should I apply (is one enough? for polishing?)
• How should I cover (if at all) the thruster openings?
• How should I deal with sharp convex corners (bow/stern)? Concave corners (some backfilling?) Probably want to make a sample.