Simulations

by Dermot Tynan in Microtransat

---

Posted on Wednesday, May 15, 2019 at 17:51

---

Carpenters like to say "measure twice, cut once." In the software world, we make extensive use of unit tests and end-to-end tests. But the North Atlantic is no friend to small boats, and there's not a lot of end-to-end testing which can replicate the vagaries of the wild Atlantic. To that end, we use simulations. Simulators can be used to throw all kinds of real-world problems at a piece of software, and measure the response.

It's worth looking at what is known in software circles as the "Happy Path". In the happy path, everything works like it should, and the boat returns home, a wandering hero.

But let's take a cash machine (or ATM) as an example. If we write code for a cash machine, it would go along the lines of:

• Load card
• Read card ID
• Prompt for PIN
• Prompt for cash amount
• Send PIN, card ID, cash amount to main bank
• Receive authorization
• Count cash
• Return card
• Issue cash

But just loading the card is fraught with issues. What if it isn't actually a bank card? Does it have a chip? Did the card make it into the machine properly? And so on. The eventual code for the cash machine could be many times larger than necessary to deal with all of the weird and wonderful ways that things can go wrong (and indeed will go wrong). So, coding up the "happy path" is relatively trivial. Making sure you've dealt with every possible anomaly or exception, is both time-consuming and not very interesting. However, without that additional code, the cash machine won't survive in the wild for too long.

Which brings us to robotic sailboats. In the case of 4B88 - Beoga Beag, the computation is split between the upper-level processor (Mother) and the lower-level processor (Otto). This was documented pretty extensively in The Software.... In short, the idea is that Otto just focuses on sailing the boat to a compass or wind heading. He controls the sail trim and the rudder. He also monitors some of the environmental information too. Mother, on the other hand, runs sporadically every couple of hours, to check how the boat is doing as per the defined course, the next waypoint, and so on. Otto is based on an Atmel AVR chip, with firmware programmed in C. Mother is based on a FreeBSD Unix operating system. Writing code for Unix (in Ruby) is a lot easier than the challenges of writing real-time control software on the Atmel. It allows for such luxuries as an interpreted language (Ruby), floating point, multiple processes performing different functions in the tradition of Rodney Brooks. But it also has a huge advantage over a single processor architecture.

It is possible to mimic the functionality of Otto, the GPS, and the satellite modem. It is possible to run all of the Mother code in a virtual machine, and simulate exactly how the code will run in the real world. So far, I have only really had a chance to perform basic testing of the navigation functions. The end intent is to be able to simulate things such as strong tidal currents, rudder failure, loss of the mast, and an endless variety of conditions which exist out there. Because the Otto functionality is relatively straightforward, it doesn't concern itself with GPS, with waypoints, or with how the boat is doing on-mission. It simply steers the boat to the appointed course. As a result, it is a lot easier to perform end-to-end testing on the low-level code. But being able to emulate what Otto is doing, in a high-level language such as Ruby, means that it is possible to create all manner of failures as the boat attempts to navigate across the Atlantic.

One of the common traits of autonomous sailboats is the dreaded attempt to sail in the wrong direction to a waypoint. If, for example, there is a strong tidal current bringing the boat further east and north (assuming a west to east attempt at the Microtransat), it can happen that the vessel over-stands the waypoint and because it has not satisfied itself that it has reached the waypoint, it will turn around and sail back to it. I wrote a paper on this very subject, and some research around using attractors and repellors rather than actual waypoints. However, testing that the functionality works as advertised, requires a simulator to create a fake tide which forces the boat well beyond the waypoint. Similarly, failures such as a compass calibration need to be detected. Electronic compasses can go out of alignment by up to 180 degrees. If the boat is attempting to follow a compass course, it will sail in exactly the wrong direction. The easiest mechanism for detecting this is to examine the GPS track and the compass heading. However, this is a non-trivial problem and requires a lot of simulation work to have any confidence that the mechanism is working properly.

Simulations are wonderful mechanisms for analysing the boat in what would appear to be real-world conditions. However, to be used effectively, they need to be part of a testing cycle. In other words, it is important to record real-world telemetry data from a boat at sea, and use that to inform the high-level system. GPS readings come with an implied error. Likewise, electronic compasses can give mis-readings due to boat heel, or movement of the hull. By combining real-world error data in the normal telemetry stream, it is possible to examine how the high-level code performs. This can then be fed back to the actual boat, and combined with on-the-water testing to enhance the accuracy (or "bug compatibility") of the simulator.

---