More extremely important fundamentals.
Why are they using images instead of lasers and sensors to map the terrain? Do images really provide that much information that it counters the heavy processing required to get that information? Simple scanning laser would require orders of magnitude less processing and could be achieved at low operating frequencies and with low memory.
Or perhaps use magnetism of Mars to detect the change in position. But I am sure they considered these. They must have. Using images just sounds so overkill and naive approach to me. “We as human navigate with images so robot must also navigate with images.” which of course is fallacy.
Mars lacks a detectable magnetic field of global scale, but boasts a rich spectrum of magnetic fields at smaller spatial scales attributed to the spatial variation of remanent magnetism in the crust. On average the Mars crust is 10 times more intensely magnetized than that of the Earth.
Which would mean that it might be suitable to be used as means for navigation. But I am only a layman and have no expertise on Mars magnetism so this is just guess work pretty much.
Also with laser you could scan the whole area continuously where as images come at one at the time. Sensors give you exact information where as in case of images you need to extract that information.
femtoos_core.c only 7500 lines and extremely well documented code. Should be a good read.
The OS takes between 10 and 20 bytes of ram, tasks can take as little as 6 bytes of ram, but approximately 20 to 40 bytes is more realistic for real applications.
Remarkably small. I might look into using this in my next version of system I am building but maybe not for the current one because it might require writing some libraries of my own, which takes time. Or perhaps I could write or port libraries from Arduino to FemtoOS. Libraries which I need, such as 1-Wire and I2C. Although I believe someone may have already done it since this operating system looks rather nice quality.
Edit: Didn’t quite like the code after all so this won’t be my choice of operating system.
Ideally I might want to look for something that works with both AVR and ARM. Also NodeMCU would be interesting to get under same OS but it’s so new I don’t believe it’s going to happen.
Very interesting because is based on FreeRTOS. But does not have support for Atmel Atmega2560. And the fact it doesn’t have proper homepage / website does not give the best possible impression and lets me believe it’s more of a “once done, finished” type of an OS.
Large support for different architectures from AVR to ARM, LTC, ST and more:
- ARM7TDMI (TI TMS320 C6571, Calypso, NXP LPC214x, LPC2378, STMicro STR71x)
- ARM920T (Freescale i.MX1)
- ARM926EJS (TI DM320, NXP LPC31xx)
- ARM Cortex-A5 (Atmel SAMA5D3, SAMA5D4)
- ARM Cortex-A8 (Allwinner A10)
- ARM Cortex-M0 (nuvoTon NUC120, Freescale KL25Z, KL26Z)
- ARM Cortex-M3 (ST MicroSTM32 F1/F2/F3, TI/Stellaris LM3S, NXP LPC17xx, Atmel SAM3U/3X, SiliconLabs EFM32)
- ARM Cortex-M4 (with/without floating point unit: ST Micro STM32 F4, TI/Stellaris LM4F/TM4C, NXP LPC43xx, Freescale Kinetis K40/60, Atmel SAM4C/4E/4S/4L)
- ARM Cortex-M7 (Atmel SAMV7)
- Atmel AVR
- Atmel 8-bit AVR
- MicroChip PIC32MX (MIPS)
- Renesas/Hitachi SuperH
- Renesas M16C/26
Has a lot of drivers available randing from Intel e1000 1Gbit network card to small ENC28J60. Also filesystems, including NFS and FAT.