Investigate Feasibility of Full Autonomy (No Pre-loaded Paths)

[arandell93]

The idea here is that the boat could be placed in any body of water and automatically start mapping it without the need for a set of waypoints to be defined ahead of time. In concept, it would work by putting the boat in a certain control mode (Ref #4) and placing it in the water. It would then being tracing the outline of the lake automatically based on a minimum depth specification provided to it (assuming that you can approximately follow the shoreline of a body of water by defining x (< 1.0) meters deep as the path for the boat to follow. Once the boat has successfully navigated the shoreline, it would then begin doing a zig-zag pattern from one side of the pond to the other (based on the shoreline it has just found) with the lines spacing pre-defined.

Inputs

• minimum depth The depth to use when following the shore. Ex: 0.5 m, but would be dependent on the body of water
• resolution The distance between passes in the grid. Ex: 50 m
• max distance The maximum allowable distance from launch point
• geofences would limit the boat from going too far from the 'home' location (launch point), or would confine the boat to a certain area, not necessarily adjacent to the 'home' location. As a minimum, the geofence would be a shoreline drawn from satellite imagery so that the boat does not enter inflows/outflows of a body of water, as rapids and rocks would be dangerous.

  Function

See the images below of Deadman's Pond and Long Pond for hypothetical applications. For Deadman's' Pond, the red path indicates a pre-loaded geofence in the form of an actual shoreline border. For Long Pond, the red path indicates a live-calculated geofence where the max distance is set to 100m. The boat would be released in water that is at least minimum depth m deep. The boat would then turn right (or left) and go forward. If the water gets deeper, it would continue to turn right (or left) and go forward until the water got back to 'minimum depth'. It would then turn left (or right) to steer back into deeper water. A PID system would be used where minimum depth is the setpoint, the sonar reading is the feedback, and the output is the rudder angle. The boat would follow the shoreline and geofence (green in image) until the body of water is completely encircled, or until it reached the geofence. It would treat the geofence the same as the shoreline and follow it using a modified PID system where the feedback is distance to geofence, the setpoint is zero, and the output is rudder angle. Once a loop is completed, the boat would automatically begin a zig-zag pattern staying within the boundaries it had just found. Firstly, it would go from the home location directly across to the opposite shoreline. It would then turn right (or left) and begin a zig-zag. Another PID loop would keep the boat's zig-zag passes within resolution meters of each other. Once the boat has completed one half of the passes (yellow), it returns home and then repeats, this time doing the other half of the body of water (blue).

Deadman's Pond

Long Pond (MUN)

[FifoIronton]

So I can't really figure out where I should put this, but in the future for navigation we're going to have to implement a Kalman Filter for figuring out the boat's position, even if there is a pre-programmed path. It's pretty much a way to combine noisy data from several different sources (GPS and an IMU?) to better predict the real value of the data. They're used a lot in Unmanned Surface Vehicles, and should smooth out the boat's position estimate even if we don't use the world's most expensive GPS.

There are some starter resources found on the Marine Cybernetics grad course page.

[whymarrh]

I think this thread is appropriate.

Speaking of which, we should try and hash out as many of the requirements for full autonomy as possible ahead of time to allow us enough time to figure it out.

[FifoIronton]

When I look at it it seems like there are two major tasks to get full autonomy, assuming we have a boat that communicates perfectly with its hardware and has a fully capable communication system. We have Controlling and Pathing, two fairly difficult tasks that will have a couple stages to implement (algorithm design, simulation, implementation, tuning).

• Controlling is the use of a controller in the context of Control Theory. This is what takes the inputs of the boat's state (in our case, probably position, velocity, acceleration, heading, whatever the time derivative of heading is called) and the goal (a point along the line that the boat needs to go) and turns it into inputs to the boat's thrusters. To do this, we'll need to tackle:
  • State estimation: How can we turn the sensor input into a good estimation of where the boat is and how it's moving? What sensors will we use to do that? How will we deal with noise in these measurements?
  • Dynamical Modelling of Our Boat: How does thruster input translate to changes in our state? We need at least an okay idea of how our boat works so that we can move forward with testing controllers
  • Controller Implementation: We then try out different controllers (like P, PI, PID or that LADRC one Calvin was looking at) to route our boat towards our set points. A good controller can make up for a shitty model, but we need to have some intuition as to how inputs will affect our state.
  • Tuning: This is the part where we put the boat in the water and play with the knobs until the boat handles in a way that isn't stupid. We gotta try it in the wind, in still water, in current, see if we can nail down one good controller for all conditions, or design different behaviors for different conditions.
  • Alternate Behaviours: Autonomous robotic systems are generally behaviour based, meaning that the controller of the robot is more than one mathmatical equation. The robot should be able to switch between several completely seperate behaviours based on it's conditions. For example, if the robot realises it's stuck, it should change from the "Go to goal" behaviour to the "back up" behaviour.

After figuring out controlling our boat, we need to figure out Pathing. This is the part that has to do with tracing out a shoreline with our boat (or boats) and figuring out how to attack the problem. We need to make something that won't just trace a shoreline, because there could be islands or sandbars or a big rock that will ruin our boat's day. We need to figure out what's easy for our boat to do, and design a way around the lake that minimises hard things. I don't have much intuition on how this is done, and I've been a little slack in reading up on it in the past few weeks... so we'll have to see how this goes. I classify it as secondary to controlling right now.

Right now, once I get motivation, I'd like to look into some basic controlling of robots using MOOS IvP, because I feel like we have a bit of a way to go before the controller is ironed out. MOOS IvP is primarily a tool for controlling swarm ASVs and USVs, but there are simulators in it too. It runs like crap on the Ubuntu virtual machine I have on my computer, but I'll work on it. With this, I can try designing boat behaviours, and then see about pathing in swarms.

[arandell93]

[...] in the future for navigation we're going to have to implement a Kalman Filter for figuring out the boat's position, even if there is a pre-programmed path.

While I agree in theory with this, in practice we are going to be limited by whatever GPS module we use since the update rate (the rate at which you receive new position data) is usually between 2 and 10 Hz. Since we also need to have a fast (relatively) control time base (say 0.5 seconds for discussion's sake), the benefits of filtering our inputs will be hampered if we don't have enough samples in the Kalman filter.

Since the boat will be moving, we also need to be careful not to take too many samples as input. Over the period of a second or so the boat may move several meters, further diminishing the appropriateness of a filter on our position.

I'm not saying it's not possible to do, but that we need to understand and address the limitations of the system before attempting to apply pre-processing to our control system.

[arandell93]

Dynamical Modelling of Our Boat: How does thruster input translate to changes in our state? We need at least an okay idea of how our boat works so that we can move forward with testing controllers

This is something we could probably set up relatively easily once we get the appropriate instrumentation onboard. Having this information is going to be very important once we start any sort of autonomy including the very minimal autonomous in Rev 1.3. We can empirically derive the model of the boat through testing. I am going to create an issue to move this discussion there #25.

[whymarrh]

This discussion should be merged into #75