https://www.planetary.org/space-policy/cost-of-the-mars-expl...

[1] https://en.wikipedia.org/wiki/Ingenuity_(helicopter)#Avionic...

untested possible landing vehicles ...

in which case, yeah, you have a lot of robots.

For the solar farm assembly case, It's actually a lot easier to have a teleoperated robot doing the work, a few astronauts in orbit doing the operation / construction. In the case of building things, you want as much space / weight landed to be the thing being built, not the builders, per se.

See EDLCAM in https://link.springer.com/article/10.1007/s11214-020-00765-9

HN is dominantly a web/SW crowd plus some mobile frontend, and "it uses a Snapdragon" gives many a wrong idea. In embedded device projects a lot of time is spent planning and designing around a heavy compute element running Linux like this, especially if the device has a safety concept or other mixed criticality concerns. It will have a substantial moat around it.

On HN if you say "systems architecture" most folks go "Oh you mean like, whether we use microservices?". In embedded, while there is a lot of overlap and analogues, it's also all of the above, plus power state management and other aspects. It's not very shiny, but that profession makes all your cars, airplanes and alien planet multicopters.

It all makes rational sense. It just feels weird to think about Python running on Mars before there's even people there.

For LEO you can scoot by pretty easily with non-hardened solutions and better systems engineering and software. For deep space you'll need to be more clever.

Here's the background:

  There were numerous ways in which SpaceX's strategies diverged from space industry norms, and almost all of them had direct implications for the cost of its launch systems. First, whereas most aerospace companies give their designs to myriad third-party contractors who create the hardware for them, SpaceX produced roughly 80% of its launch hardware inhouse. SpaceX builds its own motherboards and circuits, vibration sensors, radios and more. In most industries vertical integration increases the costs of firms by not enabling them to benefit from competitive bidding between efficient suppliers. In the aerospace industry, however, the entrenchment of norms around using parts specialized for the space industry ("space grade"), and the bureaucratic rules defined by government contractors, had kept supply costs high — very high. SpaceX decided instead to build many of its own parts, or to buy parts not considered "space grade" and modify them to achieve "space grade".For example, rather than paying $50,000 to $100,000 for an industrial-grade radio, SpaceX was able to build its own for $5,000, and shaved 20% of the weight off at the same time.

  SpaceX's willingness to produce their own parts came as a shock to suppliers. For example,Tom Mueller recounts a time when he asked a vendor for an estimate on a particular engine valve: "They came back [requesting] like a year and a half in development and hundreds of thousands of dollars. Just way out of whack. And we're like, 'No, we need it by this summer, for much, much less money.' They go, 'Good luck with that,' and kind of smirked and left." Mueller's team created the valve themselves, and by summer they had qualified it for use with cryogenic propellants. "That vendor, they iced us for a couple of months," Mueller said, "and then they called us back: 'Hey, we're willing to do that valve. You guys want to talk about it?' And we're like, 'No, we're done.' He goes, 'What do you mean you're done?' 'We qualified it. We're done.' And there was just silence at the end of the line. They were in shock." As noted, a big factor driving savings at SpaceX is that it often builds its components out of readily available consumer electronics rather than equipment alreadydeemed "space grade" by the rest of the industry. Twenty years ago "space grade" equipment would have had far superior performance characteristics compared to consumer electronics, but today that is no longer the case-standard electronics can now compete with more expensive, specialized gear. For example, at one point SpaceX needed an actuator that would steer the second stage of the Falcon 1. The job fell to engineer Steve Davis to find the important part, and since he had never built a part like that before he sought out suppliers who could make it for them. Their quoted price for the device was $120,000. As Davis recalls, "Elon laughed. He said, 'That part is no more complicated than a garage door opener. Your budget is five thousand dollars. Go make it work.'"20 Davis ended up designing an actuator that cost $3,900. Another example is provided by the computers that provide avionics for a rocket. Traditionally NASA's Jet Propulsion Laboratory bought expensive, specially toughened computers that cost over $10 million each to operate its rockets. Musk told engineer Kevin Watson that he wanted the bulk of the computer systems for Falcon 1 and Dragon to cost no more than $10,000. Watson was floored,noting, "In traditional aerospace, it would cost you more than ten thousand dollars just for the food at a meeting to discuss the cost of the avionics."21 Watson was inspired by the challenge, however, and ended up creating a fully redundant avionics platform that used a mix of off-the-shelf computer parts and in-house components for just over $10,000. That same system was then also adapted for use in the Falcon 9.

  Steve Davis, the twenty second hire of SpaceX, needed an actuator that would trigger the gimbal action used to steer the upper stage of Falcon1. He went to find some suppliers and got a quote a $120,000. “Elon laughed”. Davis said. “He said, ‘That part is no more complicated than a garage door opener. Your budget is five thousand dollars. Go make it work.’” Davis spent nine months building the actuator and the final actuator approved by Musk ended up costing $3900.

I've experienced building something in-house that is far better than what you could otherwise get. Back in the 00's I wrote a JavaScript framework because the existing ones were all crappy in a variety of ways. Even as a one-person effort (and I'm no 10x engineer) I could write something that was wayyy better in a bunch of important ways (albeit not pretty enough design). My work was engineered better than the open source and commercial frameworks that I evaluated/used. Better loading, better recovery from network and other errors, better memory behaviour, better size, better speed, better integration, better diagnostics, better browser support, better user interface, customised for our needs. It did exactly what we needed for our project and mostly worked flawlessly.

The 10x difference comes in with metric units (kg and N).

Edit: might as well mention the rocketry connection... Probably the most well-known use of pounds-force is when discussing thrust of rocket engines (and other means of jet propulsion).

On earth rotor sizes are limited by the speed at the wing-tip. Once you make the rotor too long the tips start approaching supersonic speeds, giving you all kinds of weird mach effects. To make matters worse, the speed of sound is about 30% lower on Mars compared to near earth's surface.

https://ieeexplore.ieee.org/abstract/document/9843501

In short: 30kg heli, 5kg payloads. Other designs by collaborators are closer to 20kg. It's probably possible to transport a few of these on the existing lander technology, which would be awesome.

The scholar.google.com keywords you want are "Mars Science Helicopter" and a good touchpoint author is T. Tzanetos or S. Withrow-Maser

Ames and JPL were still collaborating on this when I worked there.

Sojourner (1997): 11 kg

Spirit & Opportunity (2004): 185 kg

Curiosity (2011): 899 kg

Perseverance (2020): 1,025 kg

If she says you can keep cool whatever needs cooling for 10% of the Boeing price, you’d better believe it.