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.
the heading. Well, at least that’s the answer to your introductory question.
Crossing a flowing stream is a dynamic problem and you already answered your question by suggesting that you will need to have some form of variable speed/direction control to get from one side to the other. What about using a GPS interface for a microcontroller and somehow programming a set of waypoints to follow a predefined coarse? Maybe this project could be of use.
When your medium (water, air) is not providing a fixed frame of reference, you cannot rely on your heading to match your true course. (BTW bearing is always from an object, like “your bearing from the lighthouse”).
This could even be the case on ground. Consider the island an obstacle that moves in non-predictable fashion through the same medium. That’s like a second vehicle driving in the vicinity. What you are asking the software to do is predict how an obstacle (island, mountain, giant block of cheese) will behave, in reference to your medium: water for the boat, air for the plane, regolith for the lunar rover.
So your program needs to be told a little bit about these obstacles. Islands tend to “move” differently than cheese blocks do. The same is true for destinations (shores, airfields, craters). Obviously the (in)predictability of islands lies in the randomness of the water currents. The fact that water and islands tend to interact, makes predicting the island’s path extra hard.
In a feedback loop with better known variables, you would consider the difference between heading and course. Call it error. Alter the settings for your actuators (speed, direction) to compensate. Taking into account the known relation between error and correction. PID control loops are famous for it. But they make it look easy because they tend to know exactly how to predict the difference between error and correction. Your water current might be predictable, but from your question I gather you are not relying on that.
Darn, I did nothing but explain why this could be so hard. Hope it helps anyway. Good luck on your project. Feel free to ask more questions like this one. Or tell us about your interesting project. Maybe we can start an open brain storm.
As for measuring current etc. I can’t tell you much. I can however, give you one term that might open up some new information… If an airplane needs to keep a certain heading and there is a cross-wind, you do what is called “crabbing” or you “crab into the wind”.
To figure out how much you need to "crab", there are actual equations and pilots use them all the time. The math is solid and has been used in airplanes almost as long and airplanes have flown. This math, while it might not be exactly what you are asking here, might point you in a new direction in terms of solving your problem. --Just a thought.
rik - “regolith” - I had to Google, so you furthered the education of an over 50 nerd with an over 100 word. Nicely done. As far as bearing being “from an object”, okay, but what if none of the objects in the scenario are fixed? This is not a hypothetical question. My understanding is that bearing means from current position to destination.
Chris - Crabbing is a term I kinda knew, but I did not know that it would unlock those magic formulas if I Googled for them. Wow! It will take me a while to digest that and figure out what applies to water. I think a lot (like nearly everything) applies. Terminology is a big deal when you search; the right term is very much appreciated.
Alamo - Semantics maybe, but I disagree. Heading as I understand and use the term requires motion. In the example, I mentioned an orientation (a possible term to use) of 60 degrees might cause me to move at 90 degrees when offset by current. In that case, I would consider 90 degrees to be the heading.
I agree with Alamo, GPS will I agree with Alamo, GPS will give you good feedback for where you are. Of course, you need to know where you want to go. I believe Yaw is the technical term for crabbing. If you don’t know where you want to go, you could use GPS of where you are, and if you want to go east across river 100 feet to the other side, you could calculate where you want to go (double it to 200 feet), then as you proceed, you use GPS to see if your following that line, then increase or decrease the yaw left or riight.
GPS is a fundamental part of this, as is a tilt compensated compass. The tilt compensated compass tells me which way I have the boat pointed regardless of tilt from from front to back, which it reports as “pitch” or tilt from left to right, which it reports as “yaw”. I already knew those terms; the one I am struggling with is what relates the compass bearing with the actual heading under power. I think doubling the distance would increase the size of the curve and make me hit shore at the wrong spot. Hitting shore at the right spot is a requirement; what I am trying to figure out is how to limit the distance to shore in moving water.
I need to give more context. This is a microntroller based project and it uses a GPS to determine where it is and in what direction it is making progress. It also uses an RF transceiver to communicate with another unit which provides the GPS coordinates of the target location which may change slightly during the trip and is not the same on each trip. I can’t precalculate routes. It also uses a tilt compensated compass to determine which way the boat is pointed. On still water with little or no wind, the compass direction under power with no turning applied is the same as the course reported by the GPS. In actual use, wind and current are highly likely.
The primary use for the compass is to point in roughly the right direction before applying much power. If you try to do it all with GPS, you potentially have to start by going in a fairly wide circle to get enough granularity in GPS positions to get course readings that are useful. With a compass you spin until you are at the right bearing and then take off straight. It’s a bit more involved than that in practice because of the steering servo speed (coming out of a turn and going straight is anything but instantaneous).
**I’m not thinking of an arc. ** I’m not thinking of an arc. If you have a beacon on the other side sending coordinates of where you want to go, can you start by pointing exactly act it, then proceed. Keep taking your gps coordinates, then adjust your yaw upstream just enough to keep you on the line. If your loosing ground(drifting down river), increase your yaw. If your yaw is too much you will go too far upstream so decrease yaw. The only time I would alter motor speed is if yaw upstream no longer yields progress. Do you have all the hardware built? At this point, you just have a software problem to solve. Develop a plan and try in a body of water without current, like a swimming pool.
I may not know much about computer systems and electronics, but I can definitely explain flow riverine flow measurement is done on the fly. The way we do it in the field is with a doppler profiler. Basically it’s a sonar unit that records water velocity in a vertical profile as it transverses the stream and Flow = Velocity * Area. So… in this case, you could measure relative velocity between the vessel and the water if you had a sensor that could measure the velocity of the water as the vessel moves through it, much like a pitot tube on an airplane, and you had a small sonar to track the velocity of the vessel in relation to the river bottom, as long as the bottom isn’t a moving bottom, (or use a gps-based speed) and add/subtract (depending on whether you travel upstream or downstream) the two to get the water velocity. Using water velocity in relation to vessel speed, you would have information as to adjust the power to attain a desired vessel speed and hmmm…don’t know if I helping.
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!
We have hardware, but I hesitate to call it fully built and can’t go into a lot of details as it is a funded product under development. We are pretty far along and we are doing tests in calm unobstructed water. All they prove is that we wired it right and that I can do math sometimes. Those are important hurdles, but I fear I could destroy a prototype in a harsh condition test.
I misunderstood your suggestion to aim beyond it. I was thinking X and you mean Y (upstream).
The NDA makes it difficult to explain as I can’t tell you exactly what I am doing, but one thing that complicates things is that it is very important that I get to my target quickly. The boat is very responsive. A bad decision about direction could be catastrophic.
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 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…
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?
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.
As far as bearing being “from an object”, okay, but what if none of the objects in the scenario are fixed? This is not a hypothetical question. My understanding is that bearing means from current position to destination.