My experience is that a SD card is the most crappy medium for file systems with many write operations. Sure I do not buy the most expensive cards but at least 3 cards already died in raspberries (not navio regarded but in different projects involving a raspbberry). Therefore my recommendation is to set it up as read-only by disabling swap, disabling logging to files etc.
I did this using this guide: https://hallard.me/raspberry-pi-read-only/
This way you also can safely disconnect power - what is quite common in any multicopter I think - without worrying about file system corruption
If you do so, you won’t have APM logs after the flight.
That’s a good idea. We’ve come up with the similar ideas actually. I think the Raspbian image we provide we’ll make use of them eventually. It needs extensive testing, though. If you wish, you could help us sharing your experience with the layout you just described.
Currently my copter is running complete read-only without problems so far. And I really got a better feeling when just unplugging the Pi from the lipo :-). But in the next time I need to do some vibration measurements. This is where I will stumble upon the issue Igor mentioned.
I’ll set up a partition for the logs and see if it causes any problems. If so, i’ll report it here…
I now have set up another partition and mounted it in /var/APM. But I stumbled upon another pitfall when having an read only filesystem: Compass calibration seems not to work with read only file system - even when having a writeable /var/APM. In mission planner these white dots don’t appear and it never collects samples. When remounting rw and restarting APM and then restarting the calibration process in mission planner it works fine. In APM Planner the process just fails with having not enough data.
I searched roughly through the source code but could not find any fopen or similar things writing outside /var/APM.
Does the calibration process some caching of the collected samples to the disk I was not able to find?
That’s kind of strange!
sudo ls -lh /proc/$(pidof ArduCopter.elf)/fd to figure out what files are open during calibration and it’s yielded unsurprisingly:
lrwx------ 1 root root 64 Aug 1 14:42 0 -> /dev/pts/0
lrwx------ 1 root root 64 Aug 1 14:42 1 -> /dev/pts/0
lrwx------ 1 root root 64 Aug 1 14:42 2 -> /dev/pts/0
lrwx------ 1 root root 64 Aug 1 14:42 3 -> /dev/i2c-1
lrwx------ 1 root root 64 Aug 1 14:42 4 -> socket:
lrwx------ 1 root root 64 Aug 1 14:42 5 -> /dev/spidev0.1
lrwx------ 1 root root 64 Aug 1 14:44 6 -> /dev/spidev0.0
l-wx------ 1 root root 64 Aug 1 14:42 7 -> /var/APM/ArduCopter.stg
There’s something we miss. We’ve got to dig deeper, I guess.