The header bar consists of the following main elements:
Clicking on the burger menu (in the top left of the screen) provides access to various configuration options:
It is possible to set a display name for the current mission/operation from beside the burger menu.
A default mission name is randomly selected each time Cockpit is opened/restarted. The default names are not used for saving files/recordings, but modified names are. While modifying the mission name it is possible to restore the previous name (e.g. if you change you mind or make a mistake).
Alerts received from the autopilot (STATUSTEXT
), as
well as application notifications (like loss of connection to the vehicle) are displayed in the central alerts
pane, which can be hovered over to access a scrollable history of alerts:
Some alerts can be read aloud on arrival using text to speech technology, which can be configured.
When space is available, mini widgets can be placed on the right side of the alerts display.
The current time and date is displayed in the top right corner.
Cockpit's interface consists of a configurable widget system, with
A "profile" is a collection of views that are relevant to a particular use-case or operator.
If one control station computer is used by multiple operators (e.g. within the same organisation) at different times then it could be useful for each operator to have their preferred interface saved on that computer, and they can switch to their profile when they open up Cockpit.
Alternatively, if the same control station computer is used to control different types of vehicles (e.g. a boat, an underwater ROV, and a drone) then the operator can load the appropriate vehicle control interface when they connect to a different vehicle type. It will soon be possible to store and load profiles from the vehicle itself, instead of only on the control station computer, which makes it easier to connect a different control computer to a vehicle and load the familiar control profiles for that vehicle.
Cockpit includes default profiles for submarine and boat use-cases. It is possible to restore to these (as a known reasonable interface) in case something goes wrong with your custom profiles, but be aware that the defaults may change between different Cockpit versions, so may end up restoring to an interface you haven't seen before.
A "view" is like a page that widgets can be displayed in. It is possible to configure multiple separate views and switch between them during operation, which is useful if you have different interface preferences for when you're performing different operations.
As an example, you may have one view tailored to general navigation, and another that's designed around inspections. The first view could then be used while getting the vehicle to the inspection site, and then the second view can be switched to once it's time to actually perform the inspection.
It is possible for different devices or browser instances to access Cockpit at the same time (e.g. using separate browser profiles, or one display in incognito mode, but currently not multiple tabs of the same browser instance), with their views configured independently. To use the same component layouts across instances you can export the desired view(s) from one and import into the other(s).
Multiple simultaneous tabs from the same browser instance will be supported in future.
There are several types of widgets available, and in future it will be possible to create, import, and use custom widgets as well.
The attitude HUD widget displays the vehicle's pitch and roll as a heads-up display overlay:
It is possible to configure which components get displayed, as well as the line colour:
The virtual horizon widget displays the vehicle's pitch and roll as though on the gauge in a plane:
It is most useful for guided and/or autonomous control, where the main display is of the vehicle's position.
The compass widget displays the vehicle's orientation as though looking at a compass in your hand:
It is most useful for guided and/or autonomous control, where the main display is of the vehicle's position.
It is possible to configure the vertical direction to be fixed to North ("North-up") or to the vehicle's forwards direction ("head-up").
The compass HUD is a first-person compass view, as though inside a compass and looking in the direction the vehicle is pointing (its heading):
It is possible to configure whether the exact heading angle is shown, whether to use a -180 to +180° range (default is 0 to 360°), and the colour of the lines:
The depth HUD indicates the vehicle's current depth as determined by its external pressure sensor:
This is primarily useful for underwater vehicles.
Configuration determines whether the exact depth value is shown, and the colour of the lines:
The iframe widget provides an inline frame that can display another HTML page within the Cockpit interface. This is particularly useful for showing the interfaces and displays of BlueOS Extensions (e.g. for a sonar viewer):
Configuration determines the URL to fetch the page from, as well as the overall transparency of the iframe:
The image viewer widget shows an image that is accessible to the control station computer via its network.
Images from the internet can be included (e.g. a logo for branding) as long as the computer has internet access when Cockpit is started.
This is most useful for images hosted on the local network, and was designed to display the output of a self-replacing mjpeg like from an ESP32-Cam. It could also display images hosted by a BlueOS Extension.
For vehicles with a positioning system, the map widget displays the registered home location and the vehicle's current position, with an option to track the vehicle's path over time.
There are buttons to
In future it will be possible to set the current vehicle position, and click to guide the vehicle to new positions.
The video player widget displays an available WebRTC video stream. BlueOS uses the MAVLink Camera Manager to automatically create a WebRTC stream for applicable video streams.
Multiple video widgets can be added to display different video streams.
Configuration allows selecting which video stream to display, flipping the stream image, and choosing how the frames should fit within the widget:
It is also possible to select the video source IP, which is recommended especially if there are multiple available connection routes (e.g. if there is a wired route through a tether, as well as a wireless connection, you should select the tether IP and remove the wireless one to avoid video stuttering from transmission over wifi). A warning is provided when multiple routes are available:
Video recording is possible using a mini widget, and directly records the incoming stream (not the scaled and cropped display of the widget). Cockpit can be configured to log some telemetry values, and record them as a subtitle file for convenient video playback:
The URL video player widget displays a video from a URL. This is useful for testing IP cameras that are not being redirected via BlueOS, but can also be used to display online videos if that is for some reason relevant.
Configuration allows selecting which URL to stream a video from, as well as options for whether to play the video automatically, whether it should loop when complete, whether it should play sound or be muted, whether playback controls should be exposed, and choosing how the video frames should fit within the widget (as described in Video Player.
The mini widget bar widget is a rectangular container for storing mini widgets.
Mini widgets are small, generally single-function widgets that can be drag-positioned in the header bar, footer bar, or any mini widget bar.
They are editable by selecting "Mini Widgets" in the bottom left corner of edit mode, then either dragging a new mini-widget (from those available along the bottom of the screen) into a mini-widget bar, or configuring or removing one from the "current mini-widgets" list in the bottom left corner.
The current options include
NAMED_VALUE_FLOAT/INT
messages as well
as any variable that is inside any MAVLink messageCockpit's behaviour can be configured via the burger menu, with the following tabs:
Connection configuration allows specifying custom endpoint addresses for Cockpit to communicate with. When Cockpit is hosted by a vehicle running BlueOS these are usually correct by default, but if using it standalone or connecting to some external services it may be necessary to specify different addresses, and refresh the page to establish the desired connection.
Cockpit is intended to work with arbitrary joystick types, and allows mapping joystick buttons and axes to various protocol functions, which can send inputs and commands to the vehicle, or trigger interface events. Once a function mapping is configured it is possible to export it to the computer and/or the vehicle, which can then be imported later to new Cockpit instances/devices.
Support is built in for simultaneous input from multiple sources, including multiple joysticks, and by default each joystick can provide up to 8 axis ranges and 32 buttons.
When mapping the functionality of a joystick button or axis, there are multiple protocols to choose from:
MANUAL_CONTROL
MessagesMANUAL_CONTROL
MAVLink messages are
automatically sent to the vehicle at 25Hz, which is not currently configurable.
Button functions are determined by the autopilot firmware - e.g. in ArduSub they correspond to
BTNn_FUNCTION
parameter values.
As a few caveats:
MANUAL_CONTROL
handling
MANUAL_CONTROL
protocolThe function mapping decision process is designed to minimise intrusiveness to existing setups. When mapping a
MANUAL_CONTROL
button function to a joystick button, Cockpit
BTNn_FUNCTION
configured to enable Stabilize mode, a Cockpit button being set
to enable Stabilize mode will map to that existing function bitBTNn_FUNCTION
sMANUAL_CONTROL
function when there are no buttons left it
will display an error message about insufficient buttonsIt is permitted to map the joystick button functions without a vehicle connected, in which case any relevant
autopilot parameters will be automatically remapped once the vehicle connects. If more MANUAL_CONTROL
button
functions have been assigned than are supported by the vehicle then the extra ones are removed, and a warning
is raised to notify that the configured mapping is not fully as designed.
Joystick buttons can also be configured to run more general functionalities, like modifying the interface or sending a single MAVLink message. The current supported Actions are:
go_to_next_view
go_to_previous_view
toggle_bottom_bar
toggle_full_screen
mavlink_arm
mavlink_disarm
Modifiers allow sacrificing one button in order to add an extra functionality slot for every non-modifier button. Pressing a button while a modifier is held runs the modified function instead of the regular button function.
Currently only a single modifier is available (Shift). As a special case, when a shift functionality slot is
configured as a MAVLink MANUAL_CONTROL
protocol function, it will activate BTNn_SFUNCTION
s rather than the
regular BTNn_FUNCTION
s, which allows additional MANUAL_CONTROL
button functions to be configured. Functions
from other joystick protocols are unaffected, and can be arbitrarily assigned to regular or modifier-based
functionality slots.
Currently only used for the "No Function" option.
Adding support for a new joystick type requires providing an SVG file with particular element IDs (for function mapping, and so the elements can be dynamically filled when the corresponding button is pressed):
path_b*
is used for different button numbers, numbers can currently be from 0-31
path_b10
/b11
are currently used to denote the joystick axes
Once Cockpit has a suitably registered SVG file for the desired joystick type, it is possible to perform the relevant "Joystick mapping", from the button IDs presented by the physical joystick to labels that match the corresponding buttons in the SVG file. This mapping can then be exported to the computer and/or the vehicle, and imported to new Cockpit instances/devices later.
Cockpit can optionally record some of its received telemetry values, which can then be turned into subtitle files when recording videos.
Currently the possible variables for logging are pre-defined, and the output format is determined automatically.
If left unconfigured, the variables that are recorded by default are those from active widgets in the selected
Profile. It is possible to override which variables are logged via the configuration page, but
custom widgets like the VeryGenericIndicator
cannot currently be logged.
Logging is at a fixed rate of 1Hz. When a video recording completes, a corresponding subtitle file is generated by slicing the raw log from the start to end timestamps of the video.
💡 Recorded video and subtitles are in separate files, so the browser will typically ask for permission to "download multiple files", which must be accepted to get access to the subtitles corresponding to a video recording.
It is possible to select the desired text-to-speech voice, as well as configure which alert severities are read out loud: