When I first added the autopilot process, it would update the main process at 100Hz with the current distance vector target; the main process couldn’t quite keep up with what it was being fed, but it was close. The down side was the video processing dropped rate through the floor, building up a big backlog, meaning there was a very late reaction to lateral drift.
So I changed the autopilot process to only send velocity vector targets; that meant autopilot sent an update to the main process every few seconds (i.e. ascent, hover, descent and stop updates) rather than 100 times a second for the distance increments; as a result, video processing was running at full speed again.
But when I turned on diagnostics, the main process can’t keep up with the autopilot despite the fact they are only send once every few seconds. A print to screen the messages showed they were being sent correctly, but the main process’ select() didn’t pick them up: in a passive flight, it stayed at a fixed ascent velocity for ages – way beyond the point the autopilot prints indicated the hover, descent and stop messages had been sent . Without diagnostics, the sending and receipt of the messages were absolutely in sync. Throughout all this, the GPS and video processes’ data rates to the main process were low and worked perfectly.
The common factor between autopilot, GPS, video and diagnostics is that they use shared memory files to store / send their data to the main processor; having more than one with high demand (autopilot at 100Hz distance target or diagnostics at 100Hz) seemed to be the cause for one of the lower frequency shared memory sources simply to not be spotted as far as the main process’ select() was concerned. I have no idea why this happens and that troubles me.
This useful link shows the tools to query shared memory usage stats.
df -k /dev/shm shows only 1% shared memory is used during a flight
Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 441384 4 441380 1% /dev/shm
ipcs -pm shows the processes owning the shared memory:
------ Shared Memory Creator/Last-op PIDs -------- shmid owner cpid lpid 0 root 625 625 32769 root 625 625 65538 root 625 625 98307 root 625 625 131076 root 625 625
ps -eaf | grep python shows the processes in use by Hermione. Note that none of these’ process IDs are in the list of shared memory owners above:
root 609 599 0 15:43 pts/0 00:00:00 sudo python ./qc.py root 613 609 12 15:43 pts/0 00:02:21 python ./qc.py root 624 613 0 15:43 pts/0 00:00:03 python /home/pi/QCAPPlus.pyc GPS root 717 613 1 16:00 pts/0 00:00:01 python /home/pi/QCAPPlus.pyc MOTION 800 800 10 root 730 613 14 16:01 pts/0 00:00:00 python /home/pi/QCAPPlus.pyc AUTOPILOT fp.csv 100
Oddly, it’s the gps daemon with the shared memory creator process ID:
gpsd 625 1 4 15:43 ? 00:01:00 /usr/sbin/gpsd -N /dev/ttyGPS
I’m not quite sure yet whether there’s anything wrong here.
I could just go ahead with object avoidance; the main process would only have diagnostics as it’s main high speed shared memory usage. Autopilot can maintain the revised version of ony sending low frequency velocity vector target changes. Autopilot would get high frequency input from the Sweep, but convert that to changes of low frequency velocity targets sent to the main process. This way, main has only diagnostics, and autopilot only has sweep as fast inputs. This is a speculative solution. But I don’t like the idea of moving forward with an undiagnosed weird problem.