Hello! I am rebuilding an old APMBoat from a few years ago, and at the time was unable to find a way to get the boat to hold position. When it reached the final waypoint, it would just stop and float with the current/wind. The only thing I was able to do is have it change speed and repeat a pattern with the DO_JUMP command very slowly.
But that wastes power - is there a way to get it to return to a location if it drifts a set distance away?
I was thinking I would use a geofence, but it looks like that capability is not implemented iwth APMRover.
Any workarounds, suggestions?
Thanks!
You need to be a member of diydrones to add comments!
Replies
I think you're missing how a proportion-derivative-integral (PID) controller works, what the inputs are to this particular controller, and how those input are driven by the system and the environment. The wind and water current will push the USV off the desired station keeping position, developing an X-Y position error with the actual position from the USV GPS. The X, Y position error generates a desired heading and a heading error, using the USV compass, to get back to the station keeping point, and a distance back to that same point. Then a thrust command is generated from the position error, and a rudder angle command is generated from the heading error. The PID structure of the controller minimizes the station keeping error, to the point where the USV could effectively hover on a point with continuous low-level thrust and rudder commands, even with variable wind and current conditions. The force vector sum of the wind resistance and the water current will be countered by the thrust command, with the rudder commands holding the bow into the direction of the vector sum. No additional sensors are needed beyond the GPS and the compass that the USV already has. And like I said in my first post, this controller has been tested on real boats in real off-shore conditions in the Gulf Stream, so it does work without additional sensors.
Now, energy optimization is a different matter that these papers didn't get into. The integral controller in the controller presented here would drive a continuous, low-level thrust and rudder, which may be the optimum. However, if that were not the optimum for energy usage, an algorithm could be laid over this controller that would allow the USV to drift a given amount and then drive with an optimum thrust back to the station keeping point before shutting down to drift again.
I'm agree with this vision.
Go step by step with a first firmware version without external sensors, just the GPS and compass.
Then, why not adding wind/current sensor in next version for optimising and reduce the USV drift.
But i'm convinced that this first simply firmware version is more than sufficient for most uses.
Steve,
(this on-line web form cut off second part of my reply)
1.Underwater part of the power boat is exposed to ocean current
2. Above the water part of the power boat is exposed to wind
Power boat has a single symmetry line, no symmetry center.
"
The force vector sum of the wind resistance and the water current will be countered by the thrust command, with the rudder commands holding the bow into the direction of the vector sum. "
So there is no simple vector sum of he wind resistance and the water current since the reaction of the boat to the wind (speed, direction) is a function of
3 variables:
1. angle between wind direction and symmetry axis of the boat
2. wind speed
3. wind direction
F (angle1, speed1, direction1)
alike
reaction / response to underwater current is a function of angle between current direction and the symmetry axis of the boat, current speed, current direction
G (angle2, speed2, direction3)
so we don't get direct vector sum of acting forces but the superposition of
2 functions, F and G
The boat alone has its own signatures describing turn left/turn right operations, using motor and rudder, time delayed.
So the desired heading to follow operation is time delayed.
Exactly the case I have studied developing horizontal vs. vertical axis wind turbine.
Horizontal axis wind turbine cycles turns around to direct against the wind,
rotor gets going as long as wind direction is steady,
if changed rotor stalls, wind turbine turn around again to direct against the wind,
rotor gets going.
Exactly the opposite in case of vertical axis wind turbine, featuring vertical symmetry axis.
Since a response to the wind and water current is a function of the angle between the boat heading and the wind direction, the water currect direction respectively
we get highly complicated math-physical model to simulate actions of the boat exposed either to the wind or water current.
Boat specific signatures should be embedded into control algorithm to build efficient, energy friendly solution.
I would suggest you highly intelligent solution implemented by a R&D Group from MIT
(non-GPS fixed-wind plane indoor controller, featuring obstacle avoidance sensors (sonar, radar))
A boat will drift at a max speed of 0.5 m/s,
We only need a 2m radius, that's four seconds to respond.
You could even put it back into auto go to waypoint every time it drifted outside the waypoint diamatar.
Do you mean any specific boat and wind, water current conditions, speed, direction ?
If wind speed is 5 m/s so what sets max drift speed of 0.5 m/s
or you mean water current speed only ?
Even full size boats don't drift much faster unless there is high winds, in which case the size of the waves would be hazardous to a model boat.
@Grant,
@AntimatterCrusader,
I can implement any new feature like geofencing, hold position building math-phys model to control a drone in 3D virtual environment, test in wind tunnel and get new feature finally implemented into real drone model.
The issue is new hot features get things more and more complicated and processor's power is not unlimited and building DroneOS new features, add-ons are sacrificed to get basic operational safety working (fail-safe).
Just imagine my 10" Android tablet is your Top Drone.
If I install many applications and let them run in parallel I am low on memory and
Android starts to crash, stall, entering into self-reset mode.
Implementing 10+ more sensors, 10+ Hot add-ons can make DroneOS to crash easily
not to speak about battery health management.
Tethering a drone to make it fly for hours is a nice testing procedure, already implemented.
@jean-luc, this is the breadcrumb functionality you are talking about. Copter's are very interested in this too and there has been lots of discussion in various places. Its actually more complex then it seems but it is on the list albeit not very high.
Thanks, Grant.
Grant, just my vision for the RTL mode on sea:
When the boat go in RTL mode (by failsafe or by remote action), there are two possibility for the boat:
-If the Rally point exist, it's going to the nearest rally point and waits in loiter mode.
-If the Rally point do not exist, the boat stop and waits in loiter mode.
Then, if we want to see the boat come back to the home position in RTL mode, we just need to create a Rally point at our home position.
Regards,
jean-luc;
I disagree. If the Rally point doesn't exist the boat does a RTL. There may be times a GCS is not being used, therefore, coming home would be the only option. No GCS, no ability to program a Rally point.
Regards,
David R. Boulanger
-
2
-
3
-
4
-
5
-
6
of 7 Next