3 ms·

My dad's friend worked at JPL on Ingenuity's software. When I talked to him about it in 2019, he was sure he was going to retire after the rover launched/landed

My dad's friend worked at JPL on Ingenuity's software. When I talked to him about it in 2019, he was sure he was going to retire after the rover launched/landed, because he thought all the consumer hardware would probably not work on Mars for very long and there'd be nothing to do after that. I remember he was ranting about how they used Python. Like they had so much compute power available they could just "waste" it running "slow as hell" Python. It was such a departure from all his previous rover missions where they very judiciously optimized low level code. When we met up in 2023, we were still surprised he was working. He was too since he didn't expect Ingenuity to be in service for that long, but he figured, "well, no one's going to train a replacement for me, might as well see my last mission to its end."

elashri 3y ago
I understand that point of view. It just missing that most of the actual scientists are not top programmers. It is hard to be both. You can hire professional programmers to do some work but that has its limit and you will need more active participation from actual scientists. We usually have this discussion at CERN. But usually the very delicate components and code that works in harsh conditions and time constraints are done in a more throughout process with help of professional programmers (many of them are very capable physicists) but the majority of physicist can work in a world where what is important is to get something done in reasonable amount of time. Usually physics analysis where physics and statistics is more important than the implementation itself. I don't know about the dynamics of how this plays out usually in NASA but I would think this problem is there and the approach is probably the same too.
- kenhwang 3y ago
  I believe it was the same people, people that used to carefully plan how they'd use their 100kB of ram budget in C that then switched over to mission-of-the-week Python scripts. The code that runs on Mars was always written by career programmers, not the rocket scientists. It was the mentality that they didn't have to carefully plan resource use, or even care too much about it, and if it didn't work, they could just ship a patch was just a giant cultural shock for them, because it was so different from how they wrote mission critical software in the last several decades.
  - charred_patina 3y ago
    Is there anywhere to read about what CI/CD looks like for a Mars rover? Curious what a pipeline for something like that looks like and how they account for bugs, what kinds of conventions they must use to keep errors from occurring.
    - dehugger 3y ago
      I would be shocked if patches are applied to a mars rover in any way that's not got a human at the helm...
bane 3y ago
What's really interesting is that this has almost always been a debate. Back in the 80s, the average microcomputer could basically do nothing by today's standards. But they were still faster than a human. They were so fast in fact that most people used them with a very slow interpreted language called BASIC which was perhaps a hundred times slower than machine language and ate up a lot of the very precious memory. Still, people did a certain amount of useful work with these systems, ran businesses, managed finances, simulated reactors, etc.

elashri 3y ago

I understand that point of view. It just missing that most of the actual scientists are not top programmers. It is hard to be both. You can hire professional programmers to do some work but that has its limit and you will need more active participation from actual scientists. We usually have this discussion at CERN. But usually the very delicate components and code that works in harsh conditions and time constraints are done in a more throughout process with help of professional programmers (many of them are very capable physicists) but the majority of physicist can work in a world where what is important is to get something done in reasonable amount of time. Usually physics analysis where physics and statistics is more important than the implementation itself. I don't know about the dynamics of how this plays out usually in NASA but I would think this problem is there and the approach is probably the same too.

kenhwang 3y ago
I believe it was the same people, people that used to carefully plan how they'd use their 100kB of ram budget in C that then switched over to mission-of-the-week Python scripts. The code that runs on Mars was always written by career programmers, not the rocket scientists. It was the mentality that they didn't have to carefully plan resource use, or even care too much about it, and if it didn't work, they could just ship a patch was just a giant cultural shock for them, because it was so different from how they wrote mission critical software in the last several decades.
- charred_patina 3y ago
  Is there anywhere to read about what CI/CD looks like for a Mars rover? Curious what a pipeline for something like that looks like and how they account for bugs, what kinds of conventions they must use to keep errors from occurring.
  - dehugger 3y ago
    I would be shocked if patches are applied to a mars rover in any way that's not got a human at the helm...

bane 3y ago

What's really interesting is that this has almost always been a debate. Back in the 80s, the average microcomputer could basically do nothing by today's standards. But they were still faster than a human. They were so fast in fact that most people used them with a very slow interpreted language called BASIC which was perhaps a hundred times slower than machine language and ate up a lot of the very precious memory. Still, people did a certain amount of useful work with these systems, ran businesses, managed finances, simulated reactors, etc.