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 with...so 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:
- Vertical Speed
- Throttle Position
- Throttle Setting
- 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.