I’m posting this to crystallise a lot of interrelated parallel thoughts into a working serial plan. What you read below is probably the 20th draft revision:
Currently, each flight has a flight plan written by hand and saved to file beforehand: lines of 3D velocities plus how long to fly at those velocities e.g.
# - evx is fore / aft velocity in m/s; fore is positive # - evy is port / starboard velocity in m/s; port is positive # - evz is up / down velocity in m/s; up is positive # - time is how long to maintain that speed in seconds # - name is an arbitrary name put out to console to show flight progress # evx, evy, evz, time, name 0.0, 0.0, 0.3, 2.0, ASCENT 0.0, 0.0, 0.0, 6.0, HOVER 0.0, 0.0,-0.3, 2.0, DESCENT
The main motion process uses this to calculate the distance PID targets at a given point in time; it’s efficient, but inflexible – it doesn’t react to the world around it. To incorporate object avoidance, GPS waypoint targets, and ultimately maze mapping and tracking, I’ve decided to add a well-informed autopilot process to do the hard work, and leave the motion process in ignorant bliss. As a separate process, the LINUX kernel scheduling should use a different RPi 3B CPU core for the autopilot than that used by the already overworked motion process.
Initially, the autopilot process will use the same input file as before, feeding the latest distances targets over an OS FIFO to be picked up promptly by the motion process much as GPS, video and Sweep do now. That will ease the load on the motion process slightly as a result.
Once tested, GPS and Sweep will move from the motion process to the autopilot so it can make intelligent decisions dynamically about the distance targets it sends to be motion process; the time-critical motion processing remains oblivious to brick walls, hedges and where it’s been, it just blindly does what the intelligent autopilot tells it based upon the brick walls, hedges and mapping the autopilot knows of.
The only minor problem I can see currently is that the autopilot needs to know the direction the quad is pointing so it can yaw the quad frame Sweep data to align with the earth frame GPS flight data; because the compass is part of the IMU code on the motion process, I either need a FIFO feeding this back to the autopilot, or to access the IMU compass directly from the autopilot via I2C. Plenty of time to resolve that though while I get the basics working first.
The motivation for doing this is I don’t want to attach the expensive Sweep to Hermione until all future significant code changes have been test and any significant bugs have been made and tested thoroughly.
For the record, the current code on GitHub has been updated.