1.8 m. This required turning off the LiDAR safety flag in the configuration file for AMOS, in order to allow the software to ignore the fog and drive the boat normally. Ordinarily, I guess it is OK that AMOS would not drive in the fog, but I'm wondering if the same problem would also happen with rain, or maybe snow? I suspect it would, which could be a bit of an issue with this particular sensor I guess. Reading briefly on the subject of LiDAR issues with various types of weather, it seems that some hardware is better than others in this respect.
The boat proceeded towards the northeast corner of a 9 x 11 point grid that it was supposed to sample, although it did not quite make it. The software crashed, and the boat veered off to the northeast. When it crashed, the exit code was actually zero, so the software did not automatically restart as it was supposed to. I'll need to find some other way of detecting that a crash occurred I guess. Even if the software did restart though, it would have started back at the original GPS coordinate, which would have taken too long, given that only the morning was available for the test. I have since added a command line option to the program to allow it to continue at the last known step of the previous program instance. Looking at the ship's log later, it seems that the crash was likely related to some code for correcting magnetometer headings using GPS data. The code did not appear to be working correctly anyway, so for now at least it has been removed.
Recent improvements to logging code for the server have shown that numerous entities from the Internet seem to enjoy trying to connect and send data to the server. Typically they do not stay connected for a long length of time, and so far have not caused any noticeable harm, but potentially they could tie up the server, or even issue a random command to the boat that causes it to crash or become unresponsive. To remedy that, I have added a simple password requirement to the server, so that both the boat and the boat captain (i.e. mobile app) need to send this password within 10 seconds after connecting, or otherwise be disconnected. This seemed to work when tested today, as it bounced numerous unwanted connections all day long.
A repeat of the grid test was attempted again today. This time the weather was clear, so it was possible to test the LiDAR safety function. I maneuvered my kayak in front of the boat's path several times, and each time the software would stop the thrusters until I moved out of view. Success!!!
This time the software did not crash, and the boat had time to take one "line" of samples before it became necessary to head back. The next version of AMOS will need to be much more hydrodynamic. It took about 80 minutes for it to drive itself almost 2 km to the sampling grid; and was quite difficult to pull back, as I only allotted 30 minutes for the return trip 😓.
While idling along in the kayak behind AMOS, I realized that the grid sampling software needs to be improved: currently it always uses the same east-west direction for each of the sampling lines. However, it would be more efficient to alternate the east-west direction for each line. Getting out in the boat is always the best way to find improvements. Luckily our weather has been good and the water is still warm, but probably there are only a few weeks of good weather left, so I'll have to squeeze in as many tests as possible!
(NOTE: I believe the curvy blue path in the eastern part of the above image is due to the thruster wires sometimes getting jostled so that they are in close proximity to the magnetometer. Current flowing through the wires interferes with the magnetometer, which in turn causes the software to detect an invalid heading and fire the thrusters erratically, which in turn causes more heading errors, etc. The result is a characteristic, jerky, weaving path. The same thing also happened during some pool testing this past weekend. Some time soon I want to fix up the jumble of wires comprising the innards of this boat.)
No comments:
Post a Comment