An ROV revelation
Phil Pilgrim (PhiPi)
Posts: 23,514
Okay, this may be old news to some of you, but I just had an AHA! moment regarding guiding an floating ROV via GPS. But first, a review of terms:
Typically, for navigation, you can compute an error angle, which is course - bearing and use that, along with the speed, to modify your thrusters, rudder, wheel speed, whatever. But in floating craft, there are factors like wind and currents to contend with. In most cases the above relationship works fine. But what I've found in the field is, if the environmental forces are pushing you backwards from your intended target, course and bearing will be in different quadrants, more than 90 degrees apart. So the error term will be very large, and the obvious reaction is to turn sharply -- which is the exact opposite of what you want to do, because it does not change the error angle.
My working assumption regarding any compass is that it will be inaccurate, regardless of any care you've take to calibrate it. But it will be approximately correct all of the time. And here's where the heading reading from the compass becomes useful. If the course and heading values are more than 90 degrees apart, you're probably being pushed backwards. So the thing to do in that case is to add 180 degrees to the course (mod 360), and negate the speed figure. Then, you can compute a new error angle and forward thrust correction that gives you a better reaction to the situation, i.e. to speed up rather than to keep turning and getting the same huge error angle.
D'oh! or Aha! ? Not sure which, but I'm gonna run with it and see what happens.
-Phil
heading: The direction the robot is pointed.
course: The direction the robot is moving.
bearing: The direction to the robot's destination.
speed: The velocity in course direction.
course: The direction the robot is moving.
bearing: The direction to the robot's destination.
speed: The velocity in course direction.
Typically, for navigation, you can compute an error angle, which is course - bearing and use that, along with the speed, to modify your thrusters, rudder, wheel speed, whatever. But in floating craft, there are factors like wind and currents to contend with. In most cases the above relationship works fine. But what I've found in the field is, if the environmental forces are pushing you backwards from your intended target, course and bearing will be in different quadrants, more than 90 degrees apart. So the error term will be very large, and the obvious reaction is to turn sharply -- which is the exact opposite of what you want to do, because it does not change the error angle.
My working assumption regarding any compass is that it will be inaccurate, regardless of any care you've take to calibrate it. But it will be approximately correct all of the time. And here's where the heading reading from the compass becomes useful. If the course and heading values are more than 90 degrees apart, you're probably being pushed backwards. So the thing to do in that case is to add 180 degrees to the course (mod 360), and negate the speed figure. Then, you can compute a new error angle and forward thrust correction that gives you a better reaction to the situation, i.e. to speed up rather than to keep turning and getting the same huge error angle.
D'oh! or Aha! ? Not sure which, but I'm gonna run with it and see what happens.
-Phil
Comments
This is a delightful glimplse of the need to think like an ROV to get it to navigate well. I have been pondering something similar with autonomous flight vehicles and the 9DOH sensors. A lot the issues are similar and problems related.
Just because it gets into visualizing navigation, it gets very exciting and fun.
The maths behind why we use quadrants, and why we have to be careful with info from the adjacent quadrants is significant. It might be a little hard for a newbie to grasp.
-Phil
If you had a GPS with cm accuracy I think that would work. With standard GPS the variations are so large that I think you will get a zig zag course with that method. I think you need to be constantly checking your distance from the course line and steering to stay on that line. Describing that line mathematically is what I am curious on how to do.
Pri PointToSegment(ptx, pty) : d | vx, vy, wx, wy, c1, c2, b, pbx, pby, i ' s1 from s2 is to i := curSeg vx := F.FSub(pX[i] , pX[i-1]) ' depends on segment only vy := F.FSub(pY[i] , pY[i-1]) wx := F.Fsub(ptx , pX[i-1]) ' depends on point wy := F.Fsub(pty , pY[i-1]) c1 := F.FAdd(F.FMul(wx , vx) , F.FMul(wy , vy)) if (F.FCmp(c1 , 0.0) == -1) ' d := Distance(ptx, pty, pX[i-1], pY[i-1]) 'point is closest to beginning of segment d := 0.0 ' turning at the begining of the segement gets confused by returning distance to point return c2 := F.FAdd(F.FMul(vx , vx) , F.FMul(vy , vy)) if (F.FCmp(c2 , c1) == -1) d := Distance(ptx, pty, pX[i], pY[i]) curSeg++ ' point is closer to end of segment than to line return b := F.FDIV(c1,c2) pbx := F.FAdd(pX[i-1] , F.FMUL(b,vx)) pby := F.FAdd(pY[i-1] , F.FMUL(b,vy)) d := Distance(ptx, pty, pbx, pby) if F.FCmp((F.FSub(F.FMul(wx , vy) , F.FMul(wy , vx))) , 0.0) == -1 ' pos if on left of path return d else return F.FNeg(d) return Pri Distance (p1x, p1y, p2x, p2y) : d | tx, ty tx := F.FSub(p1x , p2x) ty := F.FSub(p1y , p2y) d := F.FAdd(F.FMul(tx , tx) , F.FMul(ty , ty)) d := F.FSqr(d)John Abshier
The ROV was programmed to leave the dock, slew to the starting point at 2.0 kts, go down the channel at 1.5 kts until it reached the end of the second float past the long pier, turn around, and come back to the first waypoint at 2.0 kts. At that point it stops and waits for me to take over with the RC. Everything is recorded on an SD card, black-box style, for further analysis.
I have endured a lot of zig-zag tracks to get to this point. Some were so bad that they looked like puzzle joints between sub-waypoints. What I've found is that they're mostly due to over- or under-correcting the turning. For a given platform, the straightest tracks are had when the turn rate and speed are in the best ratio to each other. I'm also using a PID loop. P- or PI-only have proved inadequate.
The platform I used for the above track has no fin, skeg, or chine. It will turn on a dime and is rather difficult to control with the RC transmitter. I added a small strap-on fin for added stability, and it completely changed the dynamics. It was much easier to guide under RC control; but under program control, I got the zig-zag track again, and I haven't taken the time to adjust the speed/turnrate ratio with the fin and have removed it for now.
My biggest problem currently is suspended strands of seaweed clogging the thrusters. We've put screens in front of them to keep the weeds from tangling in the prop. But now they pile up against the screens. As soon as that happens, the ROV starts spinning, and I have to bring it limping home under RC control. Because of the seaweed, I've have yet to make a good test of the topic that started this thread, even though the wind and currents lately have been ideal for the challenge.
One design objective of the platform is that it has to perform in a 2 kt. current. That's because the sea stars being monitored inhabit a narrow channel separating the mainland from an island, and the tidal currents can be extreme. That's a pretty tall order, and at this point I'm not sure it's doable.
-Phil
Edit: I'm surprised no one has suggested PhiPi change the thread's title to "A ROV-elation".
Someone has now.