3 ms·

It’s the first time they are using commodity hardware on mars. I believe the CPU is the same that has been used in a few smartphones. So it’s not a real-time

by jannes 5y ago

It’s the first time they are using commodity hardware on mars. I believe the CPU is the same that has been used in a few smartphones. So it’s not a real-time system. https://9to5google.com/2021/04/19/nasa-ingenuity-qualcomm-snapdragon/ https://9to5google.com/2021/04/19/nasa-ingenuity-qualcomm-sn...

siftedpixel 5y ago
Can’t you have a real-time kernel?
NovemberWhiskey 5y ago
There is no single CPU; it's a multitiered control system with at least two of the tiers automotive/military grade components for realtime systems. ref. https://news.ycombinator.com/item?id=26907669 https://news.ycombinator.com/item?id=26907669 for more details for example.
_joel 5y ago
There's 2 copies of memory and a RAD hardened FPGA that compares them and looks for bitflips. If it detects one then it restarts, so quickly it can do this midflight with no issues.
pragmatic8 5y ago
Why would a smartphone CPU preclude the use of an RTOS?
- GeorgeTirebiter 5y ago
  IT doesn't apriori preclude an RTOS, but multitasking OSs from unix heritage have so much 'free stuff' (networking, instrumentation, high-quality compilers, experience, etc) they are often the choice. For reasons I don't fully understand, and I'm in 'the business', true real-time embedded systems tend to have relatively simple TCP/UDP/IP stacks, simple https, and by simple I mean 'less robust than those on unix'. I think a fair amount of that is due to power budgets - embedded tend to be small or tiny. However, in this case, having that super beefy motor system to drive the blades taking many many watts, there would seem to be little point in saving microwatts in the MPU. So, one could do an RTOS on a smartphone chip, but it's 'fast enough' for human interactions - so the extra work in getting finite and well-defined real-time response doesn't really make much difference in smartphone apps - if the chip is 'fast enough'.
  - rurban 5y ago
    For RTOS such a chip is always fast enough. The problem is IO latency and software. A RTOS is typically a much slower and much smaller OS. FreeRTOS e.g consists of 3 small source files, and the control loop might be from 1KHz to 10KHz (for extremely high-dynamic systems). Compare that to the snapdragon loop of 2GHz. Factor 1e6. https in real-time is obviously a joke. There exist proper networking protocols for hard realtime, not randomized and spiky Ethernet based protocols. Telcos use such proper realtime, slicing protocols.

by jannes 5y ago

siftedpixel 5y ago

Can’t you have a real-time kernel?

NovemberWhiskey 5y ago

There is no single CPU; it's a multitiered control system with at least two of the tiers automotive/military grade components for realtime systems. ref. https://news.ycombinator.com/item?id=26907669 https://news.ycombinator.com/item?id=26907669 for more details for example.

_joel 5y ago

There's 2 copies of memory and a RAD hardened FPGA that compares them and looks for bitflips. If it detects one then it restarts, so quickly it can do this midflight with no issues.

pragmatic8 5y ago

Why would a smartphone CPU preclude the use of an RTOS?

GeorgeTirebiter 5y ago
IT doesn't apriori preclude an RTOS, but multitasking OSs from unix heritage have so much 'free stuff' (networking, instrumentation, high-quality compilers, experience, etc) they are often the choice. For reasons I don't fully understand, and I'm in 'the business', true real-time embedded systems tend to have relatively simple TCP/UDP/IP stacks, simple https, and by simple I mean 'less robust than those on unix'. I think a fair amount of that is due to power budgets - embedded tend to be small or tiny. However, in this case, having that super beefy motor system to drive the blades taking many many watts, there would seem to be little point in saving microwatts in the MPU. So, one could do an RTOS on a smartphone chip, but it's 'fast enough' for human interactions - so the extra work in getting finite and well-defined real-time response doesn't really make much difference in smartphone apps - if the chip is 'fast enough'.
- rurban 5y ago
  For RTOS such a chip is always fast enough. The problem is IO latency and software. A RTOS is typically a much slower and much smaller OS. FreeRTOS e.g consists of 3 small source files, and the control loop might be from 1KHz to 10KHz (for extremely high-dynamic systems). Compare that to the snapdragon loop of 2GHz. Factor 1e6. https in real-time is obviously a joke. There exist proper networking protocols for hard realtime, not randomized and spiky Ethernet based protocols. Telcos use such proper realtime, slicing protocols.