Live data from Hacker News

My $500M Mars rover mistake

chrislewicki.com

131–140 of 361 posts

Re: My $500M Mars rover mistake

#131

The story is compellingly written, but I thought it was also confusing. It sounds as if this team made several mistakes, not just one mistake. It's also not clear if the result of these mistakes was that there might be real damage to the spacecraft, or if the result was just wasted time and hours of confusion about why the spacecraft wouldn't start up. The first mistake is they didn't realize that the multimeter was…

It started up fine. The multimeter was connecting up the telemetry, so they weren't getting any information from it until they restored that circuit.

The power absolutely did feed into that circuit, they were trying to decide if it would have damaged it (but a motor driver is going to be able to handle power coming from the motor, so they decided that it probably didn't damage it).

Re: My $500M Mars rover mistake

#132
post #63

Earlier quoted context omitted.

I've worked on satellites, and yeah - everything is super bespoke, very low quantity, very expensive. There is probably a qualification unit, or a flight spare that may be available for many subsystems, but maybe not. Integration is a long and complicated process. Pulling apart this bot, with however many fasteners, joints, etc, and then reassembling it correctly would be a decidedly non-trivial project that could ea…

Any idea why they would use brushed motors? When every gram counts I would think ditching the mechanical commutator would be a no-brainer, but maybe adding another leg to the H-bridge is a bigger penalty?

In 2003, small brushless DC motors were way less mature and available as they are now, particularly for low-speed/high-torque applications*. Brushless controllers are much more complicated than brushed controllers, particularly on the control software front, so sticking with simpler and more reliable brushed controllers for a space application makes sense (remember, it probably needed to be radiation hardened - doing that for an H-bridge is much easier than a BLDC controller).

*A notable example of this is in the world of RC cars, where rock-crawlers only very recently have started switching to brushless motors using field-oriented control to deliver acceptable very-low-speed behavior. Until FOC controllers became available, brushed motors offered much better low-speed handling.

Re: My $500M Mars rover mistake

#134
post #63

Earlier quoted context omitted.

I've worked on satellites, and yeah - everything is super bespoke, very low quantity, very expensive. There is probably a qualification unit, or a flight spare that may be available for many subsystems, but maybe not. Integration is a long and complicated process. Pulling apart this bot, with however many fasteners, joints, etc, and then reassembling it correctly would be a decidedly non-trivial project that could ea…

Any idea why they would use brushed motors? When every gram counts I would think ditching the mechanical commutator would be a no-brainer, but maybe adding another leg to the H-bridge is a bigger penalty?

I'd guess it's mostly because it was 2003 and decent BLDCs were not super common-place yet. There were some older forms (steppers, PMSMs, etc) but they generally didn't have very good torque/weight performance. Brushed motors would probably have been the answer at the time.

Re: My $500M Mars rover mistake

#135
post #29

Earlier quoted context omitted.

That stood out to me as well when I read the article.

The multimeter in the photo has the probes plugged into the volts/ohms jack, though. Maybe it was a different meter. I figured this was going to be a story about trying to measure voltage with the meter set up on the 10A current range.

yeah i don't think he took a photo of the multimeter to use in the article before unplugging it. he didn't yet know it was important

Re: My $500M Mars rover mistake

#138

Earlier quoted context omitted.

Verbatim from my current code: if strings.Contains(dbname, "prod") { panic("Refusing to wipe production database!") } Truncate(db)

Everybody replying to you that this is fragile is missing the point. This kind of code isn't the first line of defense—it's the last.

Exactly- it's layers of prevention rather than being just one screwup away.

Re: My $500M Mars rover mistake

#139
post #118

Earlier quoted context omitted.

Verbatim from my current code: if strings.Contains(dbname, "prod") { panic("Refusing to wipe production database!") } Truncate(db)

This is bad because if someone forgot to add prod or for whatever reason the code executed beyond the panic, you’ll wipe out the db. There is no code that will protect your db/data. Only replication to a read-only storage will help in such situations.

But what if you have a chron job that auto replicates and then deletes everything after you forward it?

Re: My $500M Mars rover mistake

#140

Really well written story. As a software engineer, I have a couple stories like this from earlier in my career that still haunt me to this very day. Here’s a short version of one of them: Like 10 years ago, I was doing consulting work for a client. We worked together for months to build a new version of their web service. On launch day, I was asked to do the deployment. The development and deployment process they had…

One place I worked (some 20 years ago) had a policy that any time you run a sudo command, another person has to check the command before you hit enter. Could apply the same kind of policy/convention for anything in production.

I'm not sure this doesn't just lead to blind rubber-stamping unless this is done very very rarely
Post reply on HN