3 ms·

What is fantastic here is that the telemetry was received for nearly the entire descent, up to a few seconds before the crash. The could reproduce the exact sa

by xgbi 10y ago

What is fantastic here is that the telemetry was received for nearly the entire descent, up to a few seconds before the crash. The could reproduce the exact same scenario in simulation by replaying the telemetry as inputs to their firmware and see what happened in the software. This is tremendous advantage for debugging, it's like a wireshark replay of network packets for debugging an error in the TCP stack. This orbiter/descender architecture is really paying off for future missions. If the orbiter hadn't been there, earth wouldn't have received any telemetry at all.. Let's hope that this "real world" telemetry is saved for simulating successive versions of the guidance software of future probes.

fest 10y ago
I've worked on sensor fusion systems and I fully agree. Replaying the sensor inputs and evaluating new estimated state is a really good way of debugging failures (because you can't just stop the system mid-air and evaluate internal state). It also helps with regression test suite and trying out new algorithms quickly.
- deleted 10y ago
  [deleted]
- vvanders 10y ago
  We'd do the same for debugging networked games. Incredibly useful. If you build it right you also get a replay feature for almost free.
ragebol 10y ago
If you use ROS to do robotics, there's ROS Bags [0] that also allow this. Very very useful. [0] http://wiki.ros.org/rosbag http://wiki.ros.org/rosbag
- mikepurvis 10y ago
  There's a lot of interest in supplementary tooling around this format, too. See MARV robotics (formerly bagbunker), about which there was a ROSCon talk this fall: https://github.com/ternaris/marv-robotics https://github.com/ternaris/marv-robotics https://vimeo.com/187705380 https://vimeo.com/187705380
  - ragebol 10y ago
    I know, I was there :-). Bagbunker sounds much more awesome than "MARV Robotics" though
peeters 10y ago
> The could reproduce the exact same scenario in simulation by replaying the telemetry as inputs to their firmware and see what happened in the software. They already have: > This behaviour has been clearly reproduced in computer simulations of the control system’s response to the erroneous information.

by xgbi 10y ago

fest 10y ago

I've worked on sensor fusion systems and I fully agree. Replaying the sensor inputs and evaluating new estimated state is a really good way of debugging failures (because you can't just stop the system mid-air and evaluate internal state). It also helps with regression test suite and trying out new algorithms quickly.

deleted 10y ago
[deleted]
vvanders 10y ago
We'd do the same for debugging networked games. Incredibly useful. If you build it right you also get a replay feature for almost free.

ragebol 10y ago

If you use ROS to do robotics, there's ROS Bags [0] that also allow this. Very very useful. [0] http://wiki.ros.org/rosbag http://wiki.ros.org/rosbag

mikepurvis 10y ago
There's a lot of interest in supplementary tooling around this format, too. See MARV robotics (formerly bagbunker), about which there was a ROSCon talk this fall: https://github.com/ternaris/marv-robotics https://github.com/ternaris/marv-robotics https://vimeo.com/187705380 https://vimeo.com/187705380
- ragebol 10y ago
  I know, I was there :-). Bagbunker sounds much more awesome than "MARV Robotics" though

peeters 10y ago

> The could reproduce the exact same scenario in simulation by replaying the telemetry as inputs to their firmware and see what happened in the software. They already have: > This behaviour has been clearly reproduced in computer simulations of the control system’s response to the erroneous information.