rafaellehmkuhl
commented
11 months ago Thanks for the detailed proposal!
We indeed have a mission planning mode, although it is very limited right now (only regular waypoints are available). You could do a transect with it, although the main problem I think would be maintaining altitude. It accepts setting altitude, but I've never tested it.
@Williangalvani do you know how the ROV interprets the altitude value on the uploaded mission? We have it for GLOBAL_RELATIVE_ALT by default, but we can also have GLOBAL and GLOBAL_TERRATIN_ALT.
UAV drones permit mission planning. It's core to UAV operations to ensure autonomous and methodical surveying. Something similar is needed for below water. I'm aware there are challenges with underwater positioning and some decisions on how your implement this would need to be made. If we can assume that the ROV's position (lat, long, altitude) is known through a DVL/USBL/'Sensor Fusion', can you develop a way to programme missions for the ROV such as a transect (a line between two points) or a lawnmower pattern (where an area needs to be surveyed)?
The inputs you might expect for the ROV could be: Altitude to maintain Max speed (Optional) Frequency of still camera trigger
The inputs for the survey areas would normally be done using a georeferenced file. In GIS, we typically use something called a 'shapefile' but this can be a little complicated (it's a group of files). Instead you might prefer to use something called GeoJSON which is generally preferred for web applications.
GeoJSON would simplify the file types. Normally when we work with a 'shapefile', only one data type can be used, typically:
Anyway, whatever you choose, for transects: I would expect that cockpit would need to navigate a line between two points. Perhaps a multipoint line if the transect needs to change course. That could be for later.
Suppose you want to survey a wide area and get a visual on 100%. In that case your survey area can be described using a polygon. Ideally cockpit would examine the user provided polygon and draw a planned lawnmower flight path, perhaps with a % overlap required for the imagery. This is what drone mission planning software does.
Less important but worth mentioning, suppose there is a target with a known location and you wanted the ROV to navigate to that point. In this case a point data type could be uploaded for the target.
Critical to all of these is providing the user with a desired altitude that needs to be maintained. I think 0.6 - 1.0 m would be a good default. You can imagine how important this is if you're surveying a reef for example and must not touch it.
It is worth pointing out that lat and long is usually expressed in degrees (preferably in decimal format) using the Co-ordinate Reference System WGS84. However, every country has its own CRS and usually infrastructure will be in the local CRS. One drawback to GeoJSON is that it only handles WGS84. I believe a lot offshore projects use WGS84 so this probably isn't that big of a deal but it's worth making you aware of this. Using only WGS84 will simplify development for you because it can be used globally. I think you will need to refer other users seeking their local CRS (which will include us from time to time) to use other tools alongside cockpit such as QGIS.
I think all of these are valuable to various industries but I might selfishly propose transects if you're thinking to prioritise any of these for initial testing.