[HN Gopher] NASA believes it understands why Ingenuity crashed o...
___________________________________________________________________
NASA believes it understands why Ingenuity crashed on Mars
Author : thunderbong
Score : 86 points
Date : 2024-12-11 18:01 UTC (3 days ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| chtitux wrote:
| Getting the device speed right seems way more difficult without a
| Global Positioning System.
|
| Hopefully it will eventually be deployed [0]
|
| [0] https://techport.nasa.gov/projects/146938
| anothertroll123 wrote:
| Doubtful and unnecessary
| mannyv wrote:
| They need to drop beacons on all the surfaces to make navigation
| easier.
| tonyarkles wrote:
| You know... something I'd never really considered before now is
| that Mars has an absolutely pristine RF environment that would
| be pretty much impossible to find anywhere on Earth. I'm not
| sure how the overall noise floor would look with the lack of a
| global magnetic field but I would guess that you could set up a
| really great positioning system using small low-power beacons
| since you could use any frequency you want instead of trying to
| compete with, say, all the 2.4 and 5GHz noise on Earth.
| throwup238 wrote:
| It's been studied somewhat, at least with satellites:
|
| _> Assuming a dish antenna with 1-m diameter, for a
| downward-looking antenna the total noise temperature is about
| the same as the Earth's for all frequency bands of interest,
| with +-15 percent deviations. For an upward-looking antenna,
| the noise temperature is less than half that of Earth._ [1]
|
| [1] https://ipnpr.jpl.nasa.gov/2000-2009/progress_report/42-1
| 49/...
| PittleyDunkin wrote:
| > In short, the helicopter's on-board navigation sensors were
| unable to discern enough features in the relatively smooth
| surface of Mars to determine its position, so when it touched
| down, it did so moving horizontally.
|
| I'm a little surprised there isn't something more accurate than a
| camera for this.
| tonyarkles wrote:
| That's actually a pretty hard problem when you don't have a GPS
| constellation to assist you. Accelerometers, gyros, and
| magnetometers are used on Earth but all of them need
| calibration and drift compensation. We don't really have much
| available for sensors that can directly detect position or
| velocity, it's all estimated by double integrating acceleration
| data (which has noise and bias). On Earth most UAVs use GPS as
| a coarse position sensor and can use that to correct for
| accelerometer error but if you don't have that constellation a
| camera is probably your best bet.
| bri3d wrote:
| The latest UAVs also use ToF LIDAR and SLAM for GPS-rejected
| navigation / inertial dead reckoning correction. I'm not sure
| that would work well on Mars either, though, as the
| environment might be too featureless for that approach also.
|
| I think the best approach would probably be to equip the
| "base station" / lander with an RF beacon. Ideally, you could
| drop some RF beacons throughout the environment as you went,
| but even a single beacon with some directional receivers on
| the drone should work pretty well (here, the featureless
| environment becomes a benefit as you have to contend much
| less with radio reflections).
| tonyarkles wrote:
| SLAM is likely exactly what they were doing on Mars (it
| falls apart if there's no image features to register
| against on the ground) and ToF lidar works great for
| vertical position and velocity but doesn't help much for
| horizontal position or velocity if there isn't much terrain
| variability for the lidar to reflect off of nearby.
|
| 100% agree on the RF beacons. You might not even need the
| directional antennas. Using things like RSSI might be
| enough to augment the local sensors. Alternatively having a
| digitally-controlled phased array could probably result in
| quite excellent positioning.
| bri3d wrote:
| > SLAM is likely exactly what they were doing on Mars
|
| I think the system on Ingenuity just used feature
| detection based 2D optical flow rather than a more full-
| scale 3D environment-reconstruction type SLAM setup.
| Which is fine since neither would work in a blank
| environment like that.
| tonyarkles wrote:
| Ah yeah that's true. I'd forgotten about that step in the
| middle. I suppose too... very valuable lesson learned
| there for the team: you'll need to come up with something
| to augment the optical nav system in that environment!
| wafflemaker wrote:
| I don't really get why there is no constellation around Mars
| already. That's literally the first thing you do when sending
| a mission to another planet - establishing a simple 3 sat
| comm network.
| ceejayoz wrote:
| We have a comm network there - several satellites serve as
| comm relays. https://www.nasa.gov/centers-and-
| facilities/jpl/the-mars-rel...
|
| They just aren't GPS satellites. At some point we'll likely
| get some there, but it's a) a good amount of payload and b)
| not something we've _really_ needed there so far.
| michaelt wrote:
| GPS uses a lot more than three satellites (you need at
| least four a fair bit above the horizon to be able to
| navigate), and they have to be in different orbits.
| Earthbound GPS also uses a network of base stations at
| known locations to figure out the satellites' locations.
| mandevil wrote:
| A comm sat network is very very different from a
| _positioning_ satellite network. You 'll notice that here
| on earth those missions are done by very different
| satellites in very different orbits, they are not
| substitutes for each other.
|
| Every NASA science mission to Mars orbit for over 20 years
| has had a communications relay on it, for relaying messages
| from rovers back to Earth, but the one in the best orbit
| for communications (Mars Odyssey) is also the oldest and
| most likely to fail. The other NASA science orbiters (MRO,
| ME (ESA), MAVEN) all also have relays, but the orbits all
| leave something to be desired for communications purposes
| (they are in the right orbits for answering their
| scientific questions, e.g. MAVEN is in a highly elliptical
| orbit for studying the Martian atmosphere).
|
| There was a proposed Mars Telecommunications Orbiter- a
| satellite whose primary mission would have been beaming
| back information from rovers on the surface- proposed back
| around 2005, but it was canceled in a budget crunch, when
| actual science producing satellites were prioritized. That
| would have been in the right orbit.
|
| Building a positioning satellite network around another
| body is going to be significantly harder, incidentally.
| Even something like TRANSIT (aka NAVSAT) (1) is going to be
| significantly harder on another body because we haven't
| mapped their gravity fields due to density fluctuations as
| well, the upper atmosphere is not as well studied for drag
| effects, and we don't have fixed locations that can
| determine orbital parameters very precisely by either
| visual or radar observations after every orbital
| maintenance burn. Small uncertainty in orbital position
| lead to gigantic uncertainty in your position, and none of
| the techniques we use here on earth to remove that
| uncertainty would work around Mars.
|
| 1: Instead of the "see multiple atomic clocks and use
| triangulation and the speed of light to determine distance
| to each of them, then our location from their known
| locations" which is how all modern satnav systems work,
| TRANSIT used a single satellite passing nicely overhead
| every so often. When it was right above you, you could
| listen to the Doppler shift and know when it reached
| exactly the zenith above you. If you knew it's orbit very
| precisely you could tell where it was in space when it
| reached that zenith, and therefore where you were.
| skissane wrote:
| > A comm sat network is very very different from a
| positioning satellite network. You'll notice that here on
| earth those missions are done by very different
| satellites in very different orbits, they are not
| substitutes for each other.
|
| Not necessarily. Starlink can be used for positioning -
| not with the same accuracy as GPS can, but it definitely
| can be used. According to [0] a research group was
| involved with discussions with SpaceX about officially
| using Starlink as a positioning system, but the
| discussions were terminated because Musk didn't like the
| idea. And then the researchers went ahead and did it
| anyway - even without the ability to decrypt the signal,
| the unencrypted synchronisation data embedded in it is
| sufficient to get a position fix to within 30 metres. If
| SpaceX was actually cooperating and using data in the
| encrypted signal for this purpose, it could likely be
| made even more accurate. I suppose Musk's point is that
| however accurate it is, GPS is going to be even more
| accurate, and having Starlink offer a "just like GPS but
| less accurate" service has minimal commercial value and
| great potential for bad PR ("look how inaccurate SpaceX's
| GPS alternative is!")
|
| SpaceX is proposing to build a "Marslink" constellation
| around Mars [1]. Likely SpaceX wouldn't have the same
| opposition to using it for positioning as they do for
| Earth Starlink, given there is no existing GPS to compete
| with.
|
| > because we haven't mapped their gravity fields due to
| density fluctuations as well, the upper atmosphere is not
| as well studied for drag effects, and we don't have fixed
| locations that can determine orbital parameters very
| precisely by either visual or radar observations after
| every orbital maintenance burn. Small uncertainty in
| orbital position lead to gigantic uncertainty in your
| position, and none of the techniques we use here on earth
| to remove that uncertainty would work around Mars.
|
| This is all true, but anything is better than nothing - a
| Martian GPS with significantly less accuracy than Earth
| GPS will still be superior to no Martian GPS. And it will
| be a step towards building the necessary research
| infrastructure to answer many of those questions about
| variations in Martian gravity and atmospheric drag. So
| the accuracy of the system is likely to improve over
| time.
|
| [0] https://www.technologyreview.com/2022/10/21/1062001/s
| pacex-s...
|
| [1] https://www.pcmag.com/news/spacex-pitches-nasa-on-
| marslink-a...
| mandevil wrote:
| Comm sats in LEO like Starlink are never going to have
| orbits precisely known enough to be near GPS-quality
| without a lot of waiting. Because Starlink is in LEO they
| have to burn regularly (much more often than the MEO
| orbits preferred for positioning systems), and the
| uncertainty on each burn creates greater uncertainty on
| the orbit, and at 8km/s small uncertainties explode your
| accuracy greatly. For dedicated positioning systems they
| use ground based tracking to precisely update the orbital
| parameters after every burn, to account for that, but
| that is impracticable for Starlink.
|
| The only approach that you can do is a Doppler based
| NAVSAT approach (since the Starlink satellites don't have
| their own atomic clock for distance calculations), which
| can't really handle movement by the ground station well
| in the first place, and to account for the uncertainty in
| orbits you end up needing to wait for several to pass
| overhead without moving and trust that with enough passes
| the uncertainties cancel out. NAVSAT was never designed
| for real-time tracking, it was designed to zero the huge
| mechanical gyro's on the inertial frame for nuclear
| ballistic missile submarines.
|
| This approach wouldn't help a helicopter here on Earth-
| because it needs multiple zeniths without moving for the
| uncertainties to cancel out, this system would not
| provide much help for systems that are moving. It
| definitely would not provide much help for a helicopter
| on Mars. If you build a system for other reasons and can
| piggyback this off of that, sure, do it (I know that
| other spacecraft at least have the ability to measure
| Doppler shifts and so could use this system) but it isn't
| ever going to solve the original problem of the
| helicopter not able to tell what its horizontal velocity
| was, and it is always going to be very very rough.
|
| And of course SpaceX will want to pitch a Starlink for
| Mars. Quite honestly, I suspect that upgrading the DSN
| sites here on Earth would be far more bang for the buck,
| more of the 34m BWG's would go a long way, since they are
| already a limiting factor and if Artemis is really going
| to happen we're going to see dramatically more data
| produced that the DSN is going to need to listen for.
| skissane wrote:
| > For dedicated positioning systems they use ground based
| tracking to precisely update the orbital parameters after
| every burn, to account for that, but that is
| impracticable for Starlink.
|
| But why isn't it practical?
|
| Also, can't the inter-satellite laser links provide an
| additional source of information in measuring their
| orbital parameters?
|
| > since the Starlink satellites don't have their own
| atomic clock
|
| They might get them at some point. And even if the Earth
| constellation doesn't, maybe the Mars one will.
|
| The atomic clocks used in GPS satellites are fiendishly
| expensive, but the gap between them and much cheaper
| chip-scale atomic clocks [0] is likely to continue to
| narrow.
|
| [0] https://en.wikipedia.org/wiki/Chip-scale_atomic_clock
| tonyarkles wrote:
| To clarify a little further, years ago I worked on a
| software package for high-resolution (spatial and
| temporal) simulation of GNSS orbits. While it seems that
| this would be straightforward (Kepler's laws have been
| well-known for a while), it turns out that there are a
| number of correction factors required to deal with the
| non-ideal aspects of Earth orbit.
|
| For the MEO GNSS satellites, the last correction factor
| that I needed to implement in order to meet the system
| requirements ended up being Solar Radiation Pressure.
| Since the accuracy of a GNSS system depends on knowing
| the precise positions of the SVs at precise times, any
| error in the orbital position calculation is a direct
| error on the position; SRP, as it turned out, was enough
| to knock the real orbit off by about 1m over a...
| surprisingly short period of time (I don't remember the
| exact period, somewhere around 30min to 6h).
|
| Down in LEO you've got way less predicable correction
| factors with significantly larger magnitudes. Even at
| 300km there is still a little bit of atmosphere and your
| satellite experiences drag. Factoring in the huge number
| of SVs in the Starlink constellation and it's going to be
| a nightmare to model their orbits accurately enough to do
| decent positioning.
|
| But as I was writing that, a fun thought came to mind.
| All of the end-user GTs could be used as tracking
| stations. If the Dishys have a GPS receiver and can
| assume it is in a fixed static position (accelerometer to
| cross-check?), it can self-survey its own position on the
| ground probably to 1-2mm accuracy over time (higher-end
| consumer grade parts like the UBlox F9P can do this) and
| use the antenna phasing to get a good idea of the SV
| relative to the GT. Collect all of those high-resolution
| coordinates and the ranging data from _all_ of the end-
| user GTs, set it up as a huge linear algebra problem, and
| throw it at some GPUs. It might work?
| mandevil wrote:
| So back in the 1990s, online I talked with someone who
| worked in the GPS constellation. He said that they wanted
| multiple passes of a Navstar over their tracking
| locations to correct the orbital parameters after every
| orbital burn. Since they were in MEO, drag was a smaller
| deal, so burns were infrequent. In LEO drag was so much
| larger that regular burns are necessary. However, on
| reflection I don't know the precision of the Hall Effect
| thrusters that the Starlink satellites are using. If they
| are precise enough in their thrust application then the
| only thing you'd need to observe would be the effects of
| exoatmosphere drag, which are still a big deal. Steve's
| operational experience was only with chemical thrusters,
| electricals were still bleeding edge in the 1990s.
|
| Basically, because of drag MEO will always be >>> than
| LEO for navigation purposes. That's why all the dedicated
| navsats are there! It is possibly to piggy-back and get a
| large enough scale to compensate for the loss of
| accuracy. Eyeballing satellitemap.space for my location
| (roughly 35N), it looks like you'd get a zenith every
| minute or two from Starlink. Again, fine for stationary,
| not sure about moving, given the need for multiple
| zeniths to correct uncertainty.
|
| As for the laser link SpaceX is very tight-lipped about
| that as far as I can tell, and that is one where the
| precision is all going to be measured operationally.
| Something like LAGEOS shows that it is possible to do
| things incredibly precisely with light, but the question
| is, does Starlink have the mass, energy, and compute
| budget to actually do it in practice.
| zokier wrote:
| We are barely only planning a pnt constellation on Moon[1].
| Setting up Martian constellation is significantly more
| complex simply due the distances involved; pnt is not fire-
| and-forget system, you need constantly track and tweak the
| satellites to make sure they know when and where they are.
|
| [1] https://tempo.gsfc.nasa.gov/projects/LCRNS
| magicalhippo wrote:
| Since it's communicating with the rover, I was thinking it
| could use latency and/or Doppler effect as an input to narrow
| down the position, assuming the rover knew where it was,
| potentially by getting told by the satellites we have there.
|
| However I assume that would require special radio software,
| and they were using commercial Zigbee modules. In addition, I
| guess perhaps the helicopter and potentially rover wouldn't
| have accurate enough oscillators for this to be viable in any
| case.
| f33d5173 wrote:
| You can use radar or similar technologies to determine
| velocity. Point it straight down and you can see how fast
| you're falling. Point it at an angle, subtract vertical
| velocity, and you have horizontal velocity.
| adriancr wrote:
| alright, radar at angle, unknown surface but all looks the
| same, no landmarks to track against, unknow radar
| properties of surface, how do you translate that into
| directional speed?
| zokier wrote:
| doppler effect.
| nomel wrote:
| A doppler shifted _reflection_ requires a feature,
| significant in size to the wavelength, to reflect off of,
| somewhat perpendicular to the direction of movement. For
| RADAR, I don 't think a smooth sand field would have such
| a thing. Doppler LIDAR could probably detect it, but I
| naively assume lidar is hard in dusty environments,
| without oodles of large moving optics required to
| penetrate a dusty, optically clear, window.
| touisteur wrote:
| To get a Doppler-shifted reflection you can also... move.
| Ground-based surface radars can work (somehow) with just
| no Doppler info, cataloguing, mapping fixed reflectors
| and very often just building ground maps. If your radar
| has multiple vertically and horizontally spaced receptors
| (eg. phased-array) or you can aim your beams, you can
| also somehow build a 3D map or at least map surface
| features/masks. This is _before_ anything moves.
| magicalhippo wrote:
| > I'm a little surprised there isn't something more accurate
| than a camera for this.
|
| Another thing to keep in mind is that the helicopter was made
| using off-the-shelves parts[1], including for avionics, to see
| how well they held up on Mars.
|
| As such I think it did amazingly well.
|
| [1]:
| https://en.wikipedia.org/wiki/Ingenuity_(helicopter)#Design
| Brian_K_White wrote:
| I thought one of that devices explicit experimental purposes
| was to intentionally use relatively commodity hardware, still
| NASA-fied but not nearly as much as usual, and see how far you
| can actually get with something relatively cheap and almost
| off-the-shelf. That's why it runs linux for instance. So an
| ordinary phone camera (relatively, relative to other nasa
| hardware) would be expected and deliberate.
|
| So it never had a goal to last as long as possible, it had a
| goal to see how long it lasts when you don't sink 100 million
| into every screw.
|
| I thought anyway.
| PeterWhittaker wrote:
| I'm not particularly surprised: they planned 5 missions, all
| short in time and distance. Since every gram has to be
| accounted for (how many grams of fuel to a gram of sensor to
| Mars?), my guess is they equipped it with the bare minimum
| sensor package for the 5, and hoped maybe to get a few more
| missions in.
|
| My speculation is that the next one will have a host of
| sensors, given how much more likely double digit missions of
| greater length now seems.
| pnw wrote:
| On the bright side, the mission goal was five flights and
| Ingenuity completed 72 flights in three years!
| bpodgursky wrote:
| It was genuinely impressive and I don't mean to downplay that,
| but NASA always massively lowballs "mission goals". In
| practice, probes either fail completely, or wildly outperform.
| cogman10 wrote:
| I assume it's because the things that make stuff fail early
| are also the things that if addressed will make a project
| live for 75 years.
|
| For example, solar panels for the rovers are overbuilt
| because you can't clean them if a chance dust storm is a bit
| too dusty. But that overbuilding also means that as long as
| the panels stay reasonably free of dust, the rover will last
| a long time.
| amelius wrote:
| https://en.wikipedia.org/wiki/Bathtub_curve
| UltraSane wrote:
| The two most recent rovers are nuclear powered.
| angry_moose wrote:
| Yes/no.
|
| The design spec is something like "95% probability of
| completing 5 flights" - that is, the minimum threshold to be
| successful.
|
| That leaves a lot of extra margin to keep going well past it
| - 90% for 10 flights; 80% for 20; etc.
|
| (made up numbers)
|
| You also get the "bathtub curve" in most mechanical systems.
| Once you get past the early design defect failures, things
| tend to last a long time, until they start wearing out.
| Mistletoe wrote:
| It's insulting honestly. If any of us made estimates that off
| we would be fired.
| rozab wrote:
| As I understand it, the reason for this is it would be much
| harder to get funding for a years-long mission up front.
|
| Ingenuity funding was not actually included in the original
| Mars 2020 program and there was huge internal opposition to
| it, due to potentially infringing on the science goals of the
| mission.
| mrandish wrote:
| Yes, it so wildly exceeded its mission goals they were past all
| the "bonus round" goals and coming up with new targets. Since
| they tend to sequence goals by potential value for a given
| risk, I imagine they were knowingly accepting more mission risk
| and stretching the risk envelope. Not quite explicit 'test to
| failure' but either way you eventually end up finding a failure
| point.
|
| Identifying this as the likely failure mode strikes me as
| pretty valuable for informing future designs, at least compared
| to the alternative of it just never being heard from again one
| day.
| quotemstr wrote:
| Just like an early optical mouse on a featureless plastic table
| nomel wrote:
| It would be funny if it was just a lack of normalize(image)
| before passing it through the correlator.
| gclawes wrote:
| I wonder if Marslink will have positioning capabilities for craft
| like this
| padjo wrote:
| Was reading about the Wright brothers recently. It still blows my
| mind how rapidly we went from the invention of powered flight to
| powered flight on another plant
| lesuorac wrote:
| Exponential growth is wacky stuff.
|
| Although the thing that bothers me is that basing stuff on AI
| isn't really standing on the shoulders of giants. One big thing
| that held back human flight was that the published tables for
| lift were wrong so everybody that was using them couldn't fly
| even when they "should've" been able to (according to the wrong
| data). The Wright brothers had a good idea to re-compute the
| table and came up with different answers and were able to build
| a working plane.
___________________________________________________________________
(page generated 2024-12-14 23:02 UTC)