Let's Make Robots!

Adjusting for air/water current

First a terminology question:

What do you call the direction a boat/plane is pointed?

Yeah it is a silly nit, but I am documenting a design and people will pick nits. A simple example is a boat crossing a river. For simplicity, consider the river flowing from N to S and boat crossing from W to E. So the bearing/heading is E. But if point the boat due E you will go SE, so you have to point the boat NE. When I learned to kayak, this was called ferrying and the angle was referred to as "set", but I hate using such an overloaded term.

Now I will complicate things; if there is an island in the way, then the bearing is still E, but there will be more than one heading as there will be a waypoint. Unless it has a southern end much larger than the northern end, I want to go S of it because it disrupts the current so it is far more efficient. I will be able to point the boat to the E, maybe slightly S of E to account for the reverse eddy current and make better time and/or use less power around the southern end.

So why I am posting in programming? Well, I am hoping someone has dealt with this in water or air (has similar problems) and can advise me in a general direction that works best. If I do this purely by adjusting my heading to match the bearing on some interval, then I will end up crossing the current in a path that is an arc (probably not a true arc; more of a partial spiral). I could try to use heuristics with that to spot the pattern and try to compensate by overcompensating if that makes any sense. In other words, if I find that I have to correct by pointing further N 3 times in a row then instead of pointing the nose at the target I start pointing it a few degrees beyond it. Going back to the island problem, what if it did have a large southern end and I am going around the north end? A path to the waypoint that curves S would be a disaster!

The really hard part would be figuring out that certain combinations of throttle and steering translate to specific bearings. For example, maybe full speed at 60 degrees will cross the river in a straight line a 90 degrees. And just about the time I get enough data to figure this out,  I ram into the island because there is a slower reverse current behind it.

The other option tat occurs to me is trying to measure flow. I really want to avoid that if I can.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Will obstacle avoidance be handled locally by the boat or remotely by the unit that issues the GPS coords?

The simplest control method I can think of that would still be somewhat robust is to run a proportional control loop along the lines of what rik has already mentioned. Full power to the engines (maybe throttle down just after launch and just before landing?), controlled output variable is the rudder/prop angle/etc, error signal is the difference in angle between direction of progress and intended direction of progress.
There will be a bit of testing required to come up with the perfect proportional constant, which will be a factor of the boat's turning dynamics, but also the speed at which you can acquire accurate GPS data to calculate the updated direction of progress after each iteration of the control loop. Fortunately the other half of the error signal, the intended direction of progress, only requires the current and target GPS coords so it can be updated frequently and reliably.


The plan is that obstacles will be mapped in blocky (an oval island with irregular shoreline would be a rectangle) no go zones to minimize the amount of processing and storage required and sensors for avoidance would be used to turn back to avoid destruction, but we are learning as we go. I am trying to avoid getting too much education all at once though. I am actually finding that I can get and apply GPS data too often if I am not careful. Even in calm water, I am pretty much never precisely on course. To exactly correct to a given heading without shifting enough to once side or the other to change the heading by a degree or two when it is recalculated is almost impossible. I am playing with different values, but I think I am going to settle on 3 or 4 degrees off before I correct. Otherwise you keep turning back and forth across the desired heading.

Having a robot navigate around a book or a chair on your kitchen floor is one thing. Having a robot navigate a large boat in uncharted river water, where human life is in jeopardy is very different. This reminds me of visiting my brother in Washington state where we repeatedly crossed the Columbia river on a ferry charging $10 per vehicle. The pilot knew the river and the islands and he could do it in his sleep. It sounds like your talking about an application where the launch site and landing site might vary. To successfully navigate around an island, you definitely need a depth finder common on most fishing boats. Regarding plotting beyond the intended landing point, I actually was thinking of X across the river, not Y, upstream. That only works if your going mostly straight across. GPS only has an accuracy of what, 10m? When you get within 20m, you probably want to switch to some other sight targeting method. Something with 3 devices, 1 pointing straight, while the other 2 point outward left and right. This costs more than 1 on a sweeping system but I suspect cost is not an issue here. Then steer to maximize center readings. Or use use 2 transmitter to beacons flanking your landing site, wide enough apart to have a variance and steer until both have same readings, yielding the center of desired landing site. What your doing is harder than docking the space shuttle to the space station!! in space there is no current dragging you off course. You may want to study how they do it. I think they do rendevouz burns to get them within 60m, then they use radar for distance, and human eye to keep the 4 needles lined up (up down left right)

I hate asking questions restricted by an NDA, but that's life. I can't be incredibly specific. A shallow river is one but not the only scenario. In some of the scenarios, a depth gauge would be beyond useless. The target is not always the shore, either, but in all scenarios it is homing. I have been testing matching GPS units and getting substantially better accuracy than 10m, but my RF transceivers do have RSSI if I find I need that to complement the GPS. I hope not, as it would likely cause me to also need an offset attenuator. Everything snowballs...

humans are usually at the helm ;) 

So, you know the heading of the vessel via the compass unit. You have can get a speed via GPS, and you know the course via GPS. You have a shore station that could provide a homing signal to lock in on and help navigate. You just need a way to avoid things like islands that may get in the way it sounds like. Pardon me, I'm just brainstorming here. What about some form of a sonar sounding unit that could report depth. That would help you stay in the deeper water or at least tell the controller there was something in the way because, as you know, water gets much shallower near islands. It would also tell you if the water was too shallow for the draft of the vessel. When I was on board ship in the Navy, I know we had a sounder to help navigate channels. This is a very interesting problem!

it sounds like you have addressed everything.

you started by mentioning a terminology problem.     is that it?   

what did you learn from your controlled-water testing?     what problems are you still trying to solve?

you mentioned crashing into an island.   did that happen in your testing?       you said depth finder would be useless.    early warning saves the day.    how far out can you detect an island without a depth finder?    are you using a lasar range finder measuring out 100-200 feet to spot the island?

whats left to solve?

The NDA keeps making me hold back info. I apologize for that, but it came with the territory when I signed on to the project.

What I learned from controlled water is that if you aim toward a location and run the engines, the GPS course will match the compass bearing you are on with some possible small corrections and you just have to back off the power as you get close.

I have not crashed into an island yet. One example where depth is not helpful is pilings. I am not using a laser at this point. What is left to solve is deciding on the product/technique to use for obstruction detection and it would still be nice to figure out a way to counteract current to hold a position in moving water (if my target is a point in moving water).

BTW, waves will certainly cause rocking up and down. Another question that will come up in detection is how quickly I get pitch and yaw readings from my compass (CMPS09) over the I2C interface. The problem with serial data is that by nature it can only report what was, not what is, though if the interval is short enough data is considered current. Could I fire the laser when the boat is level based on that?

I had one epiphany (a nice way of saying I quit being stupid for a little while) during this discussion. In most cases, I should not look at both the compass and the GPS course. The compass helps me point the boat in roughly the correct direction before accelerating off (hopefully) toward the target, but once moving and getting good readings from GPS, I should only use GPS and not concern myself with which way the nose is pointed, just which way the boat is going. The compass is an interesting distraction while under way and the last thing I need to do is infect the robot with my ADD...


If you find that the compass readings are turning up too slowly relative to the rocking of the boat, at least for the purposes of synchronising a ranging laser, you may have to build a predictive model to estimate where the boat is 'now' based on the data you've received so far from the compass. If the compass data is only lagging slightly behind, a linear prediction will be enough (linear within the rotational coordinate system that is).

Are you averaging/trending your GPS readings? You mentioned earlier that you were getting 'too many' readings from the GPS - if you group and average batches of readings then you can use this to your advantage instead of it being a nuisance.

my little compass bot has taught me you need to average th compass readings as well.   minor variations can cause it oscillate wildly, especially inside a metal box like a car, or going over / under a bridge, or just certain parts of town.   I havent written that into the code yet, but I was planning on keeping a rolling average of the last 5 samples.    there does not seem to be a problem with getting it to read fast enough - many times per second is possible.   there are some compasses that are tilt-compensated. 


I have a tilt compensated compass on board. The thread is about trying to resolve between it and actual on a USV when wind, current and waves can make the direction you are aimed and the direction you travel in different from each other. And I have that other thread about trying to figure out when "actual" (GPS course) really is actual.