Knowing where I am (GPS)

Currently I'm working on two aspects of the software: simulation (for tests and position estimation) and navigation. Today it was time to get some information from the GPS.

I'm using GPSLib4J which is a bit old and needs some tinkering. First off, I needed to modify the source to work with the Gnu version of the serial comm library (easy). Second, I needed to add a bunch of getters to the PVTDataPacket (or so) class to access information on estimated error, altitude, speed, and some more (easy, too).

To do:

• build an adapter that listens to GPS update messages and send positional information to the bridge (the remote control)
• implement the navigational system and listen to GPS and compass messages
• implement the simulation system to estimate ship position and motion from sensor and actuator input
• make the navigational system make use of information from the simulation system
  

Additionally, I was investigating Java threads. I noticed the GPS thread sometimes crashes on startup since the underlying library "feels unwell". So, how do I detect a thread crash? Basically I have two options. a) the thread restarts itself when it catches an Exception in its main loop. b) a watchdog thread periodically checks all running threads with isAlive(), and restarts a thread if necessary.

I think a) is the way to go for self-contained modules like the Basic Stamp or the GPS.

Discovering Eagle CAD

Basic Stamp, schematic I was reading a story on some other interesting project and came across a program called Eagle CAD. At that time I thought it was "just some CAD program", but I soon found out it is a) free for non-commercial use, and b) it is made for designing PCBs (printed circuit boards). So, I used up the whole Sunday afternoon and learned how to work with Eagle CAD. And - wow, nice program!

At first you design the schematics. The pretty large library didn't cover the Basic Stamp so I designed my own library with a lot of help from a tutorial on the web. Once you get the hang of the not so modern GUI everything is pretty straightforward. At first I used wires instead of copper routes - which is not the same. The latter are printed on the board while the former, well, are wires.

Basic Stamp, board Though I didn't actually need to create a PCB I did one anyways. Eagle CAD is able to create a board from a schematics file. What you have to do yourself is arrange the items. The program than automagically creates the routes. Neat! I just could not figure out how to enforce the use of a single layer board - it seems that two layers is the minimum (hence the red and blue routes).

Basic Stamp board
The layout of the board reflects the current state of my Basic Stamp board - the fat Basic Stamp in the middle, a power driver to the east, a piezzo buzzer (and a resistor on the flip side) in the northwest and lots and lots of connectors all around. The photo is a bit older and does not show the power and serial connectors.

Tuning packet size

A few days earlier I implemented the IP transport via UDP. Is that efficient? How many bytes do fit in one packet? I wouldn't want to create messages exceeding the size of one package (awkward handling, what if one of them gets lost etc.)!

So, with some help from the global database (aka Internet) I tried out different ping packets sizes (doing a binary search if you know what I mean: "512? higher! 768? lower! 640?...) and found 1.472 bytes is the maximum packet size before fragmentation occurs.

That's plenty even for serialized Java objects, and tons for custom binary encoded messages. Since always a whole packet gets sent size in this case doesn't really matter, as long as the payload is less or equal 1.472 bytes. What I don't know - if the payload is less than 1.472 bytes, does the packet shrink to fit?!

Increasing wireless range

I did not even test the WLAN range yet, but just to be sure I investigated what I could do to improve reception, both distance, reliability, and bandwidth wise. So: there are implementations of drafts of the wireless "n" standard around. Since this is in the draft stage marketing chose the label "MIMO" instead to avoid trouble. Netgear advertises their stuff as "RangeMax".

Does it work? It looks like as the technology does help, possibly quite a bit. Depending on the outcome of outdoor trials I will wait until proper "n" implementations are out, or I might jump on board of some proprietary implementation. One problem is "how to power a hub in the field". Since Netgear hubs take 12V AV for input I figure it should be possible to open up a device and hook the right spot up to a lead battery (actually, input might even be 12V DC which would make things easier - what does the equal sign with the lower line dashed mean again?).

Going wireless

Finally I wrote the IP implementation of the transport class. A Transport object is able to receive messages from a remote source (many), and send messages to a (single) remote target. Or should this be broken up into sender and receiver? Can't decide yet; splitting this up would be easy.

The Java networking tutorial had a nice example on how to use datagrams (UDP), and it took me only an hour or so to send and receive messages via UDP. So far I'm using serialized message objects as the wire protocol. Since the message size for "set value" and "heartbeat" messages is under 200 bytes I'll leave it there for the time being. I need to send a whole packet anyways, so there is no point in trying to decrease message size as long as the message fits into a single packet. Right? Or does the packet size "shrink to fit" the user data size?

Looked at the JXInput lib for accessing joysticks. The software makes a solid impression to me, and actually is used in space for the Canada Arm! Impressive. The (German) guy has implemented keyboard controls as well.

Power to the Basic Stamp

Yesterday I found two PCs on the Sperrmüll ("large items garbage collection"), and now I have two nice power supplies. The 250W unit I left intact as a source for my potential robot arm project, the 300W unit I dissambled for parts and cables.

After taking a male plug apart and soldering on one of my new 4 pin power supply cables I've got a nice long extension from the 12V power supply on the ship to the Basic Stamp. The Stamp got a new power connector which fits the floppy size power plug of the cable. Now I can run the Stamp on ship or on accumulator power (I've got a small 4 x AA pack for the latter).