Home-made differential GPS

GPS information is deliberately "dumbed down" by adding an artificial error - only the military gets the exact data. The artificial error is random and changes every couple of minutes. So, what can be done to get more accurate positions?

A fixed base station with an exactly known location receives GPS data. It calculates the difference between the GPS location and the real location and transmits the error as a broadcast. A GPS receiver can receive the broadcast and deduct its exact position from its own GPS location and the error.

Neat! What what do you if you don't have a base station and a GPS-receiver that supports differential GPS? My laptop will serve as the base station. While I control the ship the laptop will stay put and receive GPS information. Any "jumping around" in the location is general GPS positioning error plus artifical error. The total error - how would I separate general from artifical error? - is transmitted to the ship via WLAN. The ship takes its own GPS measurements and uses the transmitted error information to improve the accuracy of the position.

That's the theory. Will it really improve the accuracy, or will the general errors of two receivers just add up and increase the blur? I am going to try this out by using two laptops with GPS receivers on a walk in the park.

Back to "how would I separate general from artifical error?". Maybe I could integrate the position of the base station over a longer amount of time. If the artificial error only changes every couple of minutes (verify that!), that might help.

How does a ship turn?

Another question that turned out to be not as simple as it seemed! Let's assume the ship moves along with no engine power, and the rudder is used. The resulting torque will turn the ship - which does not say anything about the direction of movement yet!

Without interaction with the surrounding water the ship would keep moving in the same direction, just an an angle. Since water resistance along the ship is much lower than across (that is, moving the ship sideways), the resulting drag force will change the direction (and amount) of the speed vector in direction of the lower resistance (that is, in the direction of the long axis of the ship).

Now the same scenario with engine power: this would work even in space. The torque turns the ship and with it, the direction of force produced by the engine. This results in a force and acceleration pointing in a different direction than the current speed vector, and the direction (and maybe amount) of the speed vector will change.

What happens if you push she ship through the water at an angle and let it go? Will it turn in the direction of movement and generate less friction, slowing down the turn, or will it turn away and experience more friction, accelerating the turn?

As described above the friction will change the direction of the speed vector. But will the ship body turn as well? If the center of mass (which is the point the ship rotates about) divides the ship in parts with equal resistance the ship will not turn. So, what if that is not the case?

I would think that a lot of mass is in the stern of the ship (engine), and that the center of mass lies within the rear half of the ship. Further I believe that the stern with its rudder creates a larger sideways friction than the bow. Since torque depends on force and distance from the center of rotation, which torque will be larger?! I don't know; it might depend on the ship!

Simulating the rudder

The rudder is quite an interesting thing, force-wise. When the ship stands still, no force is generated at all. When the ship moves, the force depends on the amount of deflected water which depends on the speed and the position of the rudder. It actually depends on the direction of speed, too, since it makes quite a difference if the ship moved "normally" or sideways (in example, when the bow and stern thrusters are used).

Then the force depends on the force produced by the engine as well. When the ship stands still and the engine goes full ahead, the water accelerated by the propeller will produce some force when it hits the rudder though the ship is not moving yet. This effect is often used when a ship tries to dock or undock: the captain revs the engine for a short time to make the ship turn without moving it (much). Or, another option: one end of the ship is moored while the engine is run to turn the ship.

I assume, too, that when the engine is run backwards the stream of water passing the rudder will be much more diffuse, producing less force compared to running the engine forward.

Summary: The forces produced by the rudder depend on the angle of the rudder, the speed and direction of the surrounding water, and the speed of the water jet produced by the propeller.

More on simulation

I spent quite some time figuring out the physics of the motion of the ship. Torque proved to be a more complex problem than I thought since the ship is not rotating around a fixed point; it floats and therefore rotates around its center of mass (that alone took me some time to google).

Interesting, too: When the bow and stern thrusters push in the same direction the produced torques cancel each other out and produce a linear thrust. I could not find anything about that on the net and filled a lot of paper with drawings and formulas before I found something that could be passed on as a solution.

The general idea: calculate two separate sums of left turning and right turning torque. The difference will be torque indeed and accelerate the turning rate of the ship. The canceled out part will provide a translation force acting on the center of mass.

I refined that idea by calculating for each engine the amount of force directed to the center of mass (translation) and perpendicular to that vector (torque).

Operating the ship

New thought today: The navigational software and the "operating system" (OS) of the ship are two different and distinct things.

The OS handles receiving and transmitting messages, executes commands, reads sensor information, and activates actuators. The navigator uses the OS as a base for implementation on a higher abstraction level.

Navigator Level 1 "Direct Control"

The controller and the navigator act like a normal remote control. Joystick input is transmitted "as is" to specific actuators. In example, pushing the joystick forward increases engine power; moving it from side to side will turn the rudder. The ship follows blindly the commands sent by the controller.

A couple of nice features can be implemented even on this level. In example, the ship could be steered by keyboard, mouse, joystick, joypad, or a combination of those. Imagine using two joysticks: the left one for thrust, and the right one for the rudder. The joystick can be twisted? We could use that for the thrusters to turn the ship.

Input might be integrated. Instead of directly translating joystick position into a thrust setting, the joystick position might be translated into increasing or decreasing the thrust setting at a rate proportional to the position. Leaving it in the middle maintains the current setting.

How about different modes? When you press a joystick button the control mode is changed. Instead of turning the rudder, a side-to-side movement of the stick might use the bow and stern thrusted in parallel to move the ship sideways. Another button click, and the same movement uses the thrusters in opposite directions, turning the ship on the spot.

Endless cool possibilities to do things a normal remote control just can't do!

Navigator Level 2 "Immediate Goal Control"

The controller transmits goals such as "set speed to 10km/h" or "turn to 215°". The navigator uses sensors, goals, and a strategy to achieve these goals to influence actuators. In example, when the ship is standing still the engine power is increased to full until the desired speed is reached, and then throttled, guided by sensor input and maybe helped by predicted performance, to what is needed to maintain speed.

Similarly the command to follow a specific heading will be interpreted by taking into account the current heading, and setting the rudder accordingly.

At this stage the navigator already should possess enough brains to not do "silly things". It might be not a good idea to give full rudder at full speed (might make the ship keel over), and setting the rudder to anything when the ship is not moving will not make the ship turn (use the thrusters instead, or get the ship movings slowly).

Level 2 enables modes such as "stick to the stick": The ship follows the stick movement forward/ backward, sideways left/ right. Point the stick in any direction: the ship will move in that direction; move the stick back to zero: the ship stops.

Navigator Level 3 "Advanced Goal Control"

The controller transmits goals such as "go to position", possibly with a list of waypoints. Or, the navigator knows the "lay of the land" (like, shape of the lake, shallow areas, piers, bridge pillars) and avoids areas where the ship better not go.

Adding sensors such as ultrasound distance measuring provides additional safety against obstacles that are not on the map. Such a feature may be added even at Level 1: The ship might cut thrust or even reverse shortly at full power to avoid slamming into something hard.

Simulating the environment

My current thoughts on the subject.

The simulated ship has a definite

• position
• heading
• velocity vector (speed and direction, which might not be along the heading!)

The environment acts on these parameters:

• Inertia (linear and rotational). When you turn an engine or thruster on or off, the ship won't start or stop moving/ rotating at once.
  
• Resistance (linear and rotational). Velocity and form (it makes a difference to push the ship forward or sideways) creates drag which slows down movement.
  
• Wind. Wind might push the ship through the water. The speed of the water moving could be measured.
  
• Current. Currents take the ship along though the speed relative to the water may even be zero. Can be measured only by GPS.
• Waves. Waves probably cause effects similar to wind and current: they push the ship around a bit.
  

There may be other influences such as hitting an immobile obstacle, pushing around floating objects, or pulling a snagged line.

Sensors such as a compass and GPS are mounted on the ship. In an ideal world the compass gives us the heading of the ship, and the GPS the location. In reality, sensors produce jittery data since measurements carry a certain error, and individual measurements will "jump around" even if nothing changes. GPS for civil use even has a built-in inaccuracy as demanded by the US military.

A compass might provide false readings due to electromagnetic interference. The GPS position sometimes jumps around erratically, shows movement when stopped of the other way round, or provides no data at all due to bad reception. The ship will have to make sense of all that.

The simulators for compass and GPS will take the heading and position of the simulated ship and introduce typical errors by configuration or on request.

On the other side there are actuators such as the engine of the ship, the rudder, and the bow and stern thrusters. In an ideal world the effects of actuator settings leads to a certain behavior of the ship (accelerate, turn). In the real world there are small waves and turbulences which influence the actual performance.

The simulated acceleration and speed of linear and rotational movement will be slightly "uneven". More massive problems can be simulated as well, such as obstruction of movement (the ship is immobilized by external influences), loss of actuator power or control (stuck rudder, lost or stuck propeller, power controller not working at all, "misbehaving", or "stuck" in a specific position).

The simulated actuators act on the simulated ship.

In example, if the engine is producing a certain thrust the ship will accelerate depending of the force provided, mass of the ship, and resistance of the water. The movement will change the position of the simulated ship which in turn will change the position delivered by the simulated GPS.

As another example, the rudder or thruster setting will turn the ship depeding on force provided, rotational inertia of the ship, and resitance of the water. The rotation will change the heading of the simulated ship which in turn will change the heading delivered by the simulated compass.

Once the ship has been built actual performance data such as acceleration and speed for certain power and rudder/ thruster settings can be measured, and likewise sensor behavior.

Back to the start

Three years ago this project had started, to linger for a long time after some furious action at the beginning. I'm currently looking at the software that I wrote mostly about two years ago. As usual, some concepts look foreign, some aspects don't sit quite right, and it's time for a redesign.

What I want to do next is design/ write the software that steers the ship at the same time as the simulation environment. The ship software will not know if it is attached to a real GPS, compass, rudder, engine, and thrusters or the simulated items. This hopefully will improve the odds the boat won't get "lost at sea (lake)", or worse even run into something hard. I'll keep the updates posted!

What about the ship? I still have to get resin and fiberglass on! "What kept you?" Well, there are a couple of spots where I just don't know how to laminate best. There is the rather sharp bow, and I would not like the fibers to lift and make a hollow bulge. At the stern I have the opposite situation: how to I prevent the fibers to lift out from the hollow?

I simply did not want to run into problems that might force me to redo the body into which I put quite a number of hours so far. Meanwhile the resin has expired and I'm thinking about building a replica of the critical spots, and trying out laminating with the old resin and the replica to get a feeling for the real thing.

AC.motion is not dead!

I am just posting this to announce the project is not dead, but very, very delayed. Meanwhile smaller PC boards are out (the size of which was a defining factor for the width of the ship), the resin I bought is too old to use, and I have to read my own notes to understand what to do next.

Since this year we have a new apartment and a garden to care for I'm not too optimistic on how things will be progressing. But I still very much want to get the thing in the water... So, let's keep our fingers crossed.

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.