Driving Ambition Options

[slinted]

This recently published work describes in great detail the driving software used for the MERs with a specific description of all the various driving modes (directed, blind waypoint, autonav, guarded, vis-odometry, etc).

M W Maimone J J Biesiadecki, "The Mars Exploration Rover Surface Mobility Flight Software: Driving Ambition," March 2006 IEEE Aerospace conference proceedings, Big Sky, Montana, USA, 8 march 2006.

One of the interesting points to me was the difficulty of matching features in the L/R Hazcam images for Opportunity. From the sounds of it, the Hazcams were intended to be the only auto-nav cameras, with the Navcams aiding planning on the ground. But, with the bare uniformity of the sands at Meridiani, they had to reconfigure the software to use the Navcams instead. I just find it incredible that such a dramatic change was within the flexible parameters they set up initially, even though the Hazcams were the tested solution to the navigation problem.

[Guest_Richard Trigaux_*]

I just find it incredible that such a dramatic change was within the flexible parameters they set up initially, even though the Hazcams were the tested solution to the navigation problem.

when we have a well designed software sytem and interface system, such flexibility is achieved automatically, unless we purposely put barriers to it. The hazcams create image files, which are analysed by the navigation software. But the navcam too create files, which are stored in the same way and same place than hazcam images. So a reconfiguration, even as much unforeseen, can be done simply with some name changes.

But I recognize that for somebody who don't know how computers work, this is astonishing! Imagine you have to change the place of the bathroom in a house: that would require weeks of tedious and dirty work, connecting tubes, making holes in the walls...

[Cugel]

Thanks for posting that document! Nice resource for a robot builder.
Interesting quote:

Visual Odometry has been used ever since as a Slip
Check to ensure we never command more than 5 meters of
driving without a guarantee of motion; this new safety check
helped out on Sol 603, when Visodom measured 44% slip
while climbing a similar dune, and stopped the drive before
getting further bogged down. Opportunity was able to back
out easily during its next drive.

Never heard about that event before.
I guess Visodom will proof pretty useful in racing to Victoria!

[Tesheiner]

Never heard about that event before.

See posts starting here.

[Guest_Richard Trigaux_*]

Thanks for posting that document! Nice resource for a robot builder.
Interesting quote:

Visual Odometry has been used ever since as a Slip
Check to ensure we never command more than 5 meters of
driving without a guarantee of motion; this new safety check
helped out on Sol 603, when Visodom measured 44% slip
while climbing a similar dune, and stopped the drive before
getting further bogged down. Opportunity was able to back
out easily during its next drive.

This in the other hand was not just changing names. It was really a new feature added, which needed its own development. But again, this was possible with relatively low work because the overal system is rational and standardized. In the instance it proved useful, as on Sol 603: otherwise the robot would be bogged again, with no waranty of getting out.

[Tesheiner]

I suspect that the drive number is incremented whenever an internal mesurement is taken (rover orientation, etc) not when a picture is taken at a new position.

I think I found the answer to this with the help of MER Analyst’s Notebook and the document "The Mars Exploration Rover Surface Mobility Flight Software: Driving Ambition" already mentioned at the beggining of this thread.

The site and drive numbers contained on all MER filenames are taken from what is called Rover Motion Counter (RMC). The RMC “Site Index” is incremented by command only; when incremented it zeroes out the “Drive Index”. The RMC “Drive Index” is incremented when a one or more steering/wheel actuators are moved. so a typical driving maneuver increments this field twice - once when running the steering actuators and again when running the wheel actuators.

The actual rover’s movement on a driving sol is composed of a series of driving primitives: low level driving (TURN and ARC) and autonomous driving (e.g. GOTO_WAYPOINT); autonomous driving primitives are internally decomposed by the driving software in a series of low level driving primitives.
Each low level driving primitive typically consists of two actuations: 1) move the steer actuators to position the wheels at a desired/calculated angle, and 2) drive the wheel actuators to move the rover.

Here is an example from driving sol 516 (Drive East Around “Purgatory Ripple”):

CODE

Command                        Site/Drive (before --> after)
ARC -0.500m, 0.050 rads            55/1000 --> 55/1002             (55/1000 = 55Z0)
ARC -0.500m, 0.050 rads            55/1002 --> 55/1004
ARC -0.500m, 0.050 rads            55/1004 --> 55/1006
ARC -0.500m, 0.050 rads            55/1006 --> 55/1008
TURN_ABSOLUTE -1.623 rads      55/1008 --> 55/1010
ARC -0.500m, 0.100 rads            55/1010 --> 55/1012
ARC -0.500m, 0.100 rads            55/1012 --> 55/1014
ARC -0.500m, 0.100 rads            55/1014 --> 55/1016
ARC -0.500m, 0.100 rads            55/1016 --> 55/1018
TURN_RELATIVE 0.314 rads         55/1018 --> 55/1020
TURN_RELATIVE 0.314 rads         55/1020 --> 55/1022
TURN_ABSOLUTE -0.438 rads       55/1022 --> 55/1024
...
ARC 0.200m, 0.000 rads              55/1072 --> 55/1074
...
TURN_ABSOLUTE 2.380 rads        55/1078 --> 55/1080
...
INC_SITE_INDEX                        55/1080 --> 56/0

[jamescanvin]

That makes sense, thanks for looking it up.