More Cockpit UI Philosophy


Brian Adams recently got some code working with OpenROV that allows plugins to be added to the system very easily. This means that if you have an idea for something particular you'd like the ROV to do, you can just write a small block of code for that particular thing and it should work with the existing software. (You can read more about the work he's doing with plugins here).

This has gotten me thinking a lot about the potential for people to experiment with different UI and UX architectures to see what works best in the field. I love thinking about this sort of thing, so I decided to take a few moments to show you guys what's been going through my head.

As you may recall, I made a blog post several months ago on "UI and UX design for OpenROV Cockpit." In the post, I included an image of a concept cockpit that was very complex but showcased a lot of the UI/ UX concepts I had been thinking of. Here's what that image looked like, in case you forgot:

The purpose of this demonstration image was to communicate a collection of concepts that could be used selectively for a Cockpit display, but I knew that something less busy would be needed for most practical applications. Recently, I've been thinking a lot about what an ideal Cockpit would look like without such a verbose amount of information, and I'd like to share what I've come up far..

The first influence on my design is the notion that with an observation-class ROV like ours, the primary mission of most deployments will be to examine the video feed coming from the ROV, therefore, the video feed should be the largest, most featured thing on the screen. Assuming that the pilot will still want some telemetry information from the ROV for navigation, etc, the best way to take up as much screen as possible would be for telemetry to be overlaid on top of the video.

There are several problems with this though... For one, overlay requires contrast between the thing you're showing and the background video it's on top of. For deep ROVs that are mostly surrounded by black, this isn't a problem, but as you can see here, if you're flying near the surface where there's lots of sun, the overlay can quickly become hard to see. Of course, you could program the overlay so that it dynamically changes color in order to contrast its background, but doing this quickly starts making the display a little hard on the eyes.

There's also a second problem with overlay, which is that as more data needs to be displayed, you start loosing a lot of useful viability from your video screen. Your picture gets covered with all the gadgets and gadget associated with effectively communicating data from the ROV.

I decided that if I were flying, I'd prefer to have my data on a small, dedicated strip of screen that is not for video. This way, I'd always be able to easily read the information I need with out contrast issues and without the data impeding what I use most for flying- the video.

I made a list of the most crucial pieces of information needed to navigate and fly an ROV. The first things that came to mind were heading and depth, but I also recalled several other things that I could remember always wanting to know when flying. In the end, this was my list:

  • Heading
  • Depth
  • Vertical Speed
  • Throttle Position
  • Throttle Setting
  • Time
  • Amount of Dive Time
  • The status of several things such as if the ROV is communicating, if a gamepad is plugged in, if heading or depth lock are engaged, if scaling lasers are on, and if the LED lighting system is on.

There were also several things that I didn't need to always see, but that I'd need to be aware of if they went outside of nominal, such as battery voltage getting too low, or electronics getting too hot.

Coming up with the list of what I wanted to see in a practical Cockpit was fairly easy, but figuring out the best way to communicate that data was what had me thinking for quite some time. I came up with the Cockpit screen shown at the top of this blog, but let me give some reasoning behind how everything is designed:

This is just a first-cut try into something that I think will be a constantly evolving and improving design. Like many designed things, there probably isn't any one-size-fits-all answer to having an ideal Cockpit: depending on the use case, there will be different strokes for different folks.

I can recall thinking about this problem with Bran Sorem even before we had OpenROV working at all. He and I talked about being able to toggle between a video only cockpit screen, a minimal data cockpit, and a verbose cockpit. Perhaps if a computer has several monitors, these things could even be split up so that a pilot can fly with a verbose screen while a scientist only looks at the video.

The possibilities are endless, but what is really exciting is that we're getting to a point where anything can be tried.

Feature: New UI theme based on webcomponents


Great writeup on your ideas! I agree with you on the contrasting side bar and I think what you have some up with is excellent. I know I would use it "as is". Do you think this is something we could see for the 2.6? Or for the next version?

For the verbose/video only argument, I know I would personally use the multiple monitor arrangement. Piloting is definitely going to be done on a ruggedized laptop, but having another screen with nothing but a 1080p video feed is inherently useful, especially if you are looking for or trying to identify something. You'll also get more people involved if they don't have to crowd around a tiny laptop.



Hey Kevin,
All good points. Definitely software that can be upgraded from a 2.6!



The top cockpit display looks awesome. You could have the cockpit display customizable to a certain degree or for those things that you don't want or need to check contunously you could bring up in a sub menu. Just like in a video game when you want to switch out gear, not all data is needed at all times but should be accessable when you want it.


The way that overlay contrast is dealt with in some video games, is to use a font that has both black and white. If the digits are white then have them bordered in black, that way when the screen is bright you see the black part and when the screen is dark you see the white.



You can actually do the multiple monitor thing now. With the HomePlug tether, you can have multiple topside units connected to the tether at one time, and each has its own cockpit display. There is an issue if both try to command the ROV, but I suppose that can be worked around.

Something that might also work is to have a single topside laptop, with two instances of the cockpit open, one for the driver and one for the observer. Set up the laptop with an external monitor, and adjust things in Windows so that the external monitor displays the observer cockpit, and the laptop display has the driver's cockpit.

Hmm. Something to try the next time I'm at OpenROV HQ.



I made some modifications to Cockpit based on the feedback posted here and some in-person feedback I got.

Here is the jist of what we came up with in off-forum conversations about the design:

  • Heading and Depth lock should be very obvious
  • Parenthesis are not needed for units
  • Units for depth should indicate calibration for fresh water or salt water
  • Units for heading should indicate true or magnetic
  • Throttle limit indicators should be more visible
  • Time should show time zone in units
  • Voltmeter for batteries should be shown (just a too-low) indicator is not sufficient

I made these modifications a while ago but forgot to put this on the forums. What do you guys think?


It looks really good. I noticed that if I make the browser fullscreen (F11) there is a lot of space at the bottom of the screen. Perhaps a second tier of info could be put there?

It should be noted that I have never used fullscreen while flying the rov, and I don't know if any one does. It might be worth it if there was data you wanted on screen.