OptoBlog

Deepsea Challenger - Part 2

Posted by Ben Orchard on Mar 17, 2015 6:00:00 AM

Faster. Ever faster.

There are around 180 devices on the submarine that the Opto hardware needed to communicate with.

Since every signal could not have its own physical wire, all the devices used a serial protocol. Each device had an address and a set of registers that could take commands or report their status back to the control program.

The interior of the pilot sphere remained at atmospheric pressure (around 14 psi), so there was no decompression requirement for the pilot. The outside of the sphere however took the full brunt of the mass of all the water above it. At the Mariana Trench, that was around 16,000 psi.

Serial data, power, and video camera feeds went in and out of the sub via very (very) special connectors called penetrator ports, electrical and fiber optic cables that had been cast in glass.

See the Deepsea Challenger page on Wikipedia

Since pretty much every system was built for redundancy, each part of the sub was split into roughly 5 parts.

Port (left), starboard (right), top, middle, and bottom. This way, if any one system failed, it did not take the whole system it was connected to with it. This meant we had many serial ports, 12 physical and 2 or 3 UDP/TCP network ones from memory.

The system needed to be tuned to take any command, be it one from the pilot's touch screen or one from any of the pilot controls, and convert it to the appropriate device's serial address and command register.

On top of that, the software had to take into account any device failures.... For example, here is one of the power switching boxes after a deep dive and some water ingress.

benorchard-blog-30

The lead programmer wrote some code that timed how long any given serial port took to communicate with all its devices when everything was up and running as it should, taking that value as a "good health" value. If any device took longer than it had in the past, it was skipped. This way, no matter what devices failed, or in what mode they failed, the system response never varied. This consistency was important for the pilot, as he would get used to the response of the submarine. The feel of it in the water became very important to him.

Take for example the thrusters.

benorchard-blog-5

Here are 3 vertical and three horizontal thrusters. (Only two of the verticals are visible in this shot).

Like every other device, the thrusters were on more than one serial bus. Each thruster could be commanded for a given RPM (thrust) and data on its status could be requested - things like what it thought its current RPM was, its DC current draw, water ingress sensor status, temperature, and so on.

At first the thruster response was rather laggy. Like most throughput issues, there is often no one ("magic") fix; it's a combination of things.

First up, the joysticks were connected to an analog input module. They started out using the 8 input module, which has a data freshness of 280 ms. We swapped it for the 4 input module as it has a data freshness of only 20 ms.

By turning off the control engine in the PAC-R controller and using it as a high-speed I/O rack from the main PAC-S2 controller, we picked up some more speed.

Putting the PAC-R and the S2 on their own network rather than the sub's Ethernet network picked up some more. (This is just one of the many cool things you can do with Opto 22 controllers, since each has two separate Ethernet ports).

Ensuring the software never waited longer than the usual healthy time for a response helped as well.

Bit by bit, we got the speed of the system to the point where the pilots were very happy with the response time. The changes we made ensured that it stayed consistent throughout the whole dive program.



The need for speed

Not every system needs to run "fast." Air-conditioning in an event hall simply does not need millisecond response times. Neither did Deepsea Challenger for that matter. Sure, it needed better than the ~800 ms we started with, but there was no need to get it much below 100 ms.

As tempting as it is to always run everything flat out, it's worth stepping back now and then and asking "Just how fast does this really need to be?"

In Part 3 we will take a look at the graphic interface the pilots used via a touch screen to control a lot of the functions of the submarine.

Till then, cheers Mate.

Topics: Deepsea Challenge

Written by Ben Orchard

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all