The uncharted surface of the moon makes for challenging robot teleoperation. Each movement made by the rover must be carefully planned and documented in order to account for the minimal visibility and unpredictability of the environment. To do this, engineers need the ability to meticulously plan and edit routes, taking into account robot trajectory planning.
The breakdown of routes into more specified components allow engineers to make targeted changes for more precise path planning. All routes can be visualized on the route manager, and edited directly so the impact on other adjoining routes can be immediately realized. Adding and editing individual routes can also be executed through either absolute or relative paths based on the situation in order to avoid obstacles, change directions, or circumnavigate a ‘point of interest’.
The developed app, though not released on any app store, was presented in a poster session and reviewed by Carnegie Mellon University students and faculty. The following responses were collected from people who tried out the demo.
The mission comprises of various teams with designated roles to ensure the rover successfully launches, lands, and deploys. The CubeRover tele-operations team becomes involved once the rover has deployed, and works in conjunction with science cartographers to acquire more information about lunar regolith through characterization of blast ejecta.
Since our team took up the work from a previous team, we tested the early designs with engineers to determine if there were any features that were missing, flawed, or unnecessary. User testing revealed that the interface did not reflect the inputs and outputs needed to differentiate between absolute and relative path planning. As the engineer attempted to explain absolute versus relative path planning, he had a difficult time articulating the differences, inevitably leading to more confusion once his verbal explanations turned into scribbles on the board comprised of mathematical variables and diagrams.
Referring back to early interviews, we were able to derive a few insights:
Navigational engineers lack uniform vocabulary needed to communicate granular path planning details.
The situational context of the rover affects how the path should be considered and planned.
To improve the shared map within the layer manager, I broke down routes into defined granular components. This would allow navigators to make more precise modifications when planning routes.
My teammate and I also experimented with creating various icons visualize the differentiation between segments and circumnavigation in routes.
Routes can be edited by clicking on the pencil icon on the layer manager page. The user can specify which segment to edit by accessing a dropdown. Modification to the segment parameters, and how the modification affects the overall route, is visualized on the map prior to planning.
Properties of lunar material will be analyzed by taking pictures of regolith buildup of nearby objects (points of interest). Once identified, the rover will circumnavigate the object, taking a specified amount of photos from various angles in either a clockwise or counterclockwise direction.
Learning and applying common terminology used by engineers when tele-operating robots was key to understanding how to design for the users. After talking to various engineers, and conducting “paper missions” to test early prototypes, adjustments to the shared map interface were made based upon robot localization and positioning.
Interviews with engineers helped to clarify the main distinctions between absolute and relative path planning. Absolute positioning only takes into account the rover’s start position plane and the desired end position. For the map interface, this positioning is based on a Cartesian plane.
Unlike absolute positioning, relative position is always based on the rover, and the particular direction it is facing. Absolute positioning only takes into account the rover’s start position plane and the desired end position. For the map interface, this positioning is based on a Cartesian plane.
Due to the nature of remote teleoperation on unknown terrain, there is uncertainty that accumulates for each segment, and each route that is executed. When planning segments, it would be useful for engineers to be able to visualize this projection of uncertainty. Similarly to the way weather forecasts display hurricane paths as an expanding cone, the next segment the rover must travel could also display the probable path the rover will take.
Another addition I would like to make would be for more interactivity on the coordinate grid directly. Currently, elements and paths on the grid can only be altered through input fields in the righthand menu (excluding 'points of interest'). It would be useful to be able to select start and end points of segments directly on the grid, instead of having to locate the segment name in the layer manager.
I would like to be able to carry out prototype testing with users that are more representative of the actual users: navigational cartographers. Though we were able to do user testing with engineers at CMU, the lack of specific experiential knowledge can only provide so much insight into how an actual mission would be carried out and executed.
