Curiosity rover writes Morse Code of JPL everywhere it goes(blog.jgc.org)
blog.jgc.org
Curiosity rover writes Morse Code of JPL everywhere it goes
http://blog.jgc.org/2012/08/curiosity-rover-writes-morse-code-of.html
4 comments
They have very detailed physics-based models of terrain-wheel interaction ("terramechanics" is the general term). The tread depth must be one of the design parameters.
Slip is something they watch closely, and 100% slip is something they worry about a lot. I worked on a project using a small prototype in that same yard (metal wheels with metal tread) and was really f-ing hard to get the thing to slip with anything like a reasonable load and slope.
Slip is something they watch closely, and 100% slip is something they worry about a lot. I worked on a project using a small prototype in that same yard (metal wheels with metal tread) and was really f-ing hard to get the thing to slip with anything like a reasonable load and slope.
Why don't they just put a camera filming downwards to determine the ground speed? Wouldn't it be simpler and more reliable?
Light heartedly off topic, but at a decelerators conference last year I had a chance to talk to one of the JPL Entry Descent and Landing peeps, and he mentioned that in Q&As, no single audience utterance carried more foreboding than 'Why don't you just...'
To answer your question more helpfully, having closed loop machine vision stuff is quite computationally intensive, though there is already some on the rover (to help negotiating obstacles or stop if it sees something like a trench (MERs would famously stop at the same time every day, thinking that their now-infront shadow was a pit)) but it's power intensive and expensive (both mass and cost of a dedicated odometry camera, for example) and the lighting conditions are very variable. The MERs developed a technique whereby they would 'shimmy' their steering every so many meters, and then with the rear facing camera snap a photo of their tracks (with shimmies) and infer distance travelled and slippage and so on. This stuff is often easier with humans in the loop as the terrain still throws up unknown unknowns when driving. Here's a pic of the tracks:
http://photojournal.jpl.nasa.gov/jpeg/PIA14129.jpg
I guess another point is that while it might be a perfectly sensible suggestion technically, there's only so much 'new' they want to risk per mission (the Entry Descent and Landing phase contained a whole lot of 'new' as we know) and they maybe just wanted to carry on doing it in a way they know works ok from before.
To answer your question more helpfully, having closed loop machine vision stuff is quite computationally intensive, though there is already some on the rover (to help negotiating obstacles or stop if it sees something like a trench (MERs would famously stop at the same time every day, thinking that their now-infront shadow was a pit)) but it's power intensive and expensive (both mass and cost of a dedicated odometry camera, for example) and the lighting conditions are very variable. The MERs developed a technique whereby they would 'shimmy' their steering every so many meters, and then with the rear facing camera snap a photo of their tracks (with shimmies) and infer distance travelled and slippage and so on. This stuff is often easier with humans in the loop as the terrain still throws up unknown unknowns when driving. Here's a pic of the tracks:
http://photojournal.jpl.nasa.gov/jpeg/PIA14129.jpg
I guess another point is that while it might be a perfectly sensible suggestion technically, there's only so much 'new' they want to risk per mission (the Entry Descent and Landing phase contained a whole lot of 'new' as we know) and they maybe just wanted to carry on doing it in a way they know works ok from before.
As I understood it that's exactly what the camera is doing, and the morse code is just a helpful pattern with a known distance to make more precise measurements of ground speed.
With no patterns one could think of a situation where the surface sand/terrain would be displaced but your actual position was exactly the same.
With no patterns one could think of a situation where the surface sand/terrain would be displaced but your actual position was exactly the same.
All true. JPL has been a world leader in development of visual odometry ("VO"), which is key to estimating slip, which in turn is key to not getting stuck in sand.
The method hinges on establishing correspondence between visual features in before/after images. Then, since you know (through stereo ranging) how far away things are in both images, you can match points and see how far you've gone. This works better the more visual features (tiny edges and corners) you have to cue off of, and presumably these treads are generating more distinguishable features. They ran VO on Spirit and Opportunity, and they will on Curiousity as well.
A summary is in the first page of this little white paper:
http://www.lpi.usra.edu/meetings/marsconcepts2012/pdf/4053.p...
and one full description is here:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.104....
The good thing is that VO requires no extra hardware, because you already have stereo cameras.
By the way, they do make commercial velocity sensors of the kind described in the GP comment (special camera looking down):
http://www.corrsys-datron.com/optical_sensors.htm
These may not use VO, they might just use optical correlation. Sometimes they're used in robotics.
The method hinges on establishing correspondence between visual features in before/after images. Then, since you know (through stereo ranging) how far away things are in both images, you can match points and see how far you've gone. This works better the more visual features (tiny edges and corners) you have to cue off of, and presumably these treads are generating more distinguishable features. They ran VO on Spirit and Opportunity, and they will on Curiousity as well.
A summary is in the first page of this little white paper:
http://www.lpi.usra.edu/meetings/marsconcepts2012/pdf/4053.p...
and one full description is here:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.104....
The good thing is that VO requires no extra hardware, because you already have stereo cameras.
By the way, they do make commercial velocity sensors of the kind described in the GP comment (special camera looking down):
http://www.corrsys-datron.com/optical_sensors.htm
These may not use VO, they might just use optical correlation. Sometimes they're used in robotics.
Sometimes they're used ...in optical mice. By the millions.
Correct. See 1:15 into the video in the OP that explains the visual odometry system.
For that matter why not use the same technique a laser/led mouse uses to know how far/fast it's been moved?
They could have one on each wheel and then another set of sensors pointing down, so wheel slippage vs ground movement at that axle.
They could have one on each wheel and then another set of sensors pointing down, so wheel slippage vs ground movement at that axle.
Wouldn't the ground not being perfectly flat mess with a measurement like that?
Reasons I can think of include: the ground does not consist of a regular pattern of known length so image processing might be more difficult; looking out over the track allows more data points to be interpreted; an outward looking camera can fulfill more additional roles or be repurposed to compensate for other failed instruments more readily; a downward facing camera is more likely to gather images within the rover's own shadow; other outward facing cameras could use the same algorithm should the distance measuring camera fail.
What happens if the ground moves?
In that case certainly the wheel marks will be unexploitable as well? I'm thinking about scenarios such as heavy wind blowing the sand away or sand "avalanches" on slopes.
Besides, a camera would work on hard ground, while this method wouldn't. I don't know if that's a problem in practice on mars of course.
Besides, a camera would work on hard ground, while this method wouldn't. I don't know if that's a problem in practice on mars of course.
It should have been DEI.
With a 14-22 minute ping time, it better be able to handle most situations on its own...