Preventing SD card from being corrupted

Navio / Edge Project share
1

Hi,

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: Protect your Raspberry PI SD card, use Read-Only filesystem – Charles's Blog

This way you also can safely disconnect power - what is quite common in any multicopter I think - without worrying about file system corruption

2

If you do so, you won’t have APM logs after the flight.

3

OK that’s a good point,

Some suggestions here:

  • Symlinking /var/APM/logs to /tmp. /tmp is a r/w tempfs which lasts at least until the raspberry is powered off. For analysis the logs can be copied to a safe location before turning the copter off.
  • creating a dedicated partition for these logs which gets mounted into /var/APM/logs. In case of file system corruption only the filsystem on that partition has to be recreated.
4

@vlo

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.

5

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…

6

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?

7

@vlo

That’s kind of strange!

I ran sudo ls -lh /proc/$(pidof ArduCopter.elf)/fd to figure out what files are open during calibration and it’s yielded unsurprisingly:

total 0
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:[6007]
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.