(a)NO4D1620 (b)Trondheim
Figure 4.5:Two-dimensional array of points based on DEPARE from NO4D1620 with higher res-olution in shallow areas. 10m·10m in shallower that 20m, 50m·50m for depth between 20m and 100m, and 75m·75m for depths deeper than 100m.
For further reducing the amount of data handled with this method, just including the depth ranges that are interesting can be done. For the purpose of anti-grounding, depths above a certain threshold can be ignored, because the vessel is only interested in knowing if it’s entering a shallow area.
The workbench to extract vertices from S-57 polygons is shown in figure B.3. The vertex extractor is doing the actual work in this bench, while the other transformers filter the the data, makes vertices denser, gives the coordinated the names Lat and Lon; and converts the coordinate angles from degrees to radians.
4.4 Discussion
While this chapter has considered data covering the ocean, the FME workbenches for working on DEPARE objects from S-57 ENCs is also functional on shapefiles4. The Norwegian Water Resources and Energy Directorate uses shapefiles in their database of Norwegian lakes larger than 2500 m2, with some 600 of the lakes having available depth information [79]. Operating the Otters in lakes is a possible future scenarion, where these shapefiles may be used to create a DB for the Otter.
4.4.1 Choosing the Resolution
For the two dimensional grids and for the DEPARE vertices, finding the balance between spatial resolution and the amount of data is an important topic. On the one hand, better
4By exchanging the S-57 reader for a shapefile reader
(a)Trøndelag (b)Trondheim
Figure 4.6: Vertices on contour around depth areas (DEPARE) from NO4 ENCs. DRVAL1 and DRVAL2 is defined for all the red points.
resolution will lead to smaller features such as narrow portions of the navigable area being detected. On the other side, larger resolutions will make searching the data slower, and for motion planning on the two-dimensional grid, path searching is made more computation-ally expansive. The 50m·50m grid shown in figure 4.4 was made more as a demonstration, and is not considered feasible for operations close (<50m) to the land.
Another aspect of choosing the resolution should be based around the expected accu-racy of the GPS/GNSS. According to the the producer, the estimated accuaccu-racy of the v104s is 1m at95%of the time with SBAS augmentation[80], which is supported over Europe and most of Northern America5. Based on this, the grid resolution should be above 1m.
A definite conclusion of the most suited resolution for the Otter is not made in this thesis, but a 2m grid is experimented with in section 5.4.1 for path planning purposes.
4.4.2 Optimizing Database Performance
In order to increase the querying speed, Latitude and Longitude have been defined as the primary key in all extracted data. In addition to this, a index has been added to depth information fields to allow fast queries that restrict depth. Adding the extra indexes makes the database file larger, and a decision therefore has to be made at a later point if this is merited or not.
More specialized ways of optimizing the database performance is to change the SQLite3 file parameters PARAMS. For instance, SQLite3 databases can be used as in-memory databases, potentially increasing its performance. Storing the database in memory could also be possible throughramfsortmpfsin the OS. None of these suggestions have been implemented in this thesis, but is worth exploring in future works.
5The v104s SBAS supports operation in the EGNOS and WAAS areas [80].
4.4 Discussion An entirely different approach is to change to a database format that is optimized for storing and querying spatial data. An interesting candidate is SpatialLite, which is an ex-tended version of SQLite but with spatial indexes and spatial querying algorithms already implemented. SpatialLite also has the benefit of supporting storing and searching through polygon objects. In hindsight, using this might have provided a better solution than the one presented in this thesis.
A final measure for optimizing the database performance is that only the data relevant for a mission should be included in the vessel. For the NTNU Otter, restricting the area of the grid is one example of this.
4.4.3 Weather Forecast Services
As a part of searching for available data, publicly available APIs for weather forecasts was explored. The desired forecasts were for wave, wind and current in services covering Norway. As the services may prove to be useful in the future of the Otter project, they are included here:
• Barentwatch API:https://code.barentswatch.net/wiki/display/
BWOPEN/API-Documentation
• Ocean Forecast from The Norwegian Meteorological Institute: https://api.
met.no/weatherapi/oceanforecast/0.9/documentation#/
• Weather forecast from Yr, with a list of more APIs from The Norwegian Meteoro-logical Institute:https://developer.yr.no/
A potential use for these in the fish tracking system, is as a way to contextualize the weather conditions while a fish is being tracked. While not used in this thesis, they may be integrated to the online data visualizing solution explored in 7.2.
Chapter 5
Utilizing the A Priori Data in LSTS Toolchain
To make use of the a priori data gathered in chapter 4, the DB has to be available on the vessel, and DUNE needs to be able to read and make use of the data. The libraries written to accomplish this is described in section 5.2. Tasks that uses these libraries are then created, consisting of two methods of anti-grounding in section 5.3 and a global path planner in section 5.4.
In addition, a short introduction to a Neptus implementation developed by Alberto Dallolio is given in section 5.5, showing how the same database and SQL queries has been used to increase the situational awareness for the operator.
5.1 Implementation Design Choices in DUNE
When implementing new functionality for DUNE, a decision has to be made if it should be as a task, or as a class that is used by tasks. Two example designs of implementing it as a task is: 1) that all functions using the DB, is cobbled together in a single task, or 2) that other task can access the information through IMC messages being requested from a reader task. For use cases requiring many queries, like the path planning described in section 5.4, this would add a lot of overhead, and come with a significant performance penalty. Instead, the functionality has been implemented as a set of classes in the DUNE library1.
This comes with the challenge of possibly having multiple threads accessing the same DB file at once. While SQLite has multi-user support, performance could suffer if multiple users/threads commits changes at the same time. This is not considered a problem in the work presented here, because none of the classes using the database needs to permanently alter the DB, which means that the DB connection mode can be set to read-only.
1Source folder: src/DUNE/SituationalAwareness