evranch
Well-known member
It's great to hear your experience especially as you are flying a platform that is different in almost every way from mine. I believe some of my statements were likely based on my equipment, usage and environment, so let me explain them. This sort of discussion is really valuable for those interested in building a system, as well.
Airframe weight and wind. I have no issue with the image quality itself in wind - you are running the a6000 with manual controls, I'm running CHDK on my Canon. Manual control of the camera is important to keep a high shutter speed, low ISO and locked autofocus if possible. The issue with buffeting is with Arduplane and the way it captures metadata. My stitching software places a lot of importance on the camera attitude and position data. It's used for calibration, alignment and correction of things like shutter lag and wind drift, and it's captured by the Pixhawk when it fires the camera trigger. I have about 150ms of total shutter lag as calculated during alignment, and if the plane is pounded out of attitude or position by a gust, the photo and the metadata no longer align, resulting in calibration failure and discarded images. This is why I specified that with Arduplane and Micmac, at least, the plane must have weight and inertia to hold attitude against gusts. It doesn't help that SK is famously gusty. I personally tried the system in a lighter airframe and was disappointed by the results.
The ultimate solution for this to use a camera with a hot-shoe and use CAM_FEEDBACK_PIN to log the exact moment the shutter fires. This is also done by the Emlid Reach RTK system, something I plan to add to my system in the future as well. Once I get my airframe properly powered, I can afford to fly a better camera without the fear of losing it on takeoff. However, most peoples' first attempts will likely involve a servo-triggered point-and-shoot, and this will work better with a heavier airframe.
Software... I agree with you fully in principle. I also write embedded code and PLC systems for agriculture and industry, and clean code that is inherently understandable and testable is a goal for us all. I'm honestly a little jealous that you have time and funding to write your own autopilot! It sounds like a great project.
The real risk with Ardupilot is not the codebase - it is mature and has been tested heavily by many users. It's the vast number of parameters that the user is allowed access to, and in many cases has to adjust to get good flight. A good example that you will see posted all over the internet in crash threads is that it's easy to build an initial setup where the sticks give the correct commands, MANUAL will fly fine, but the stabilization outputs are cross-controlled. When you then flip into an auto mode in the air, it will attempt to pull down elevator to correct down pitch - and as the pitch drops, the amount of down elevator grows, as does the throttle setpoint. This can put you in a very bad situation in under a second. When you flip back into MANUAL you are headed for the ground vertically with high airspeed, and had better have a plan that doesn't involve ripping the wing off by hauling panic elevator. This particular failure mode is responsible for most of the lawn darts, and the equivalent mix-up for ailerons has ruined a lot of wings. Bench testing in all modes is the solution here, as well as flying plenty high before your first switch into an auto mode.
Once it is flying safely in FBWA at low rates, getting it to fly a good envelope for mapping requires adjusting a bunch of parameters that can result in power-on stalls while in a bank, i.e. spins that grow into spiral dives. Even when it's setup and flying reliably, wind shear can still put you into some nasty stalls. The autopilot responds like a beginner pilot and is incapable of escaping these. This is why I recommend the pilot is capable of flying the full envelope of their airframe before attempting to install an Arduplane system.
Airframe weight and wind. I have no issue with the image quality itself in wind - you are running the a6000 with manual controls, I'm running CHDK on my Canon. Manual control of the camera is important to keep a high shutter speed, low ISO and locked autofocus if possible. The issue with buffeting is with Arduplane and the way it captures metadata. My stitching software places a lot of importance on the camera attitude and position data. It's used for calibration, alignment and correction of things like shutter lag and wind drift, and it's captured by the Pixhawk when it fires the camera trigger. I have about 150ms of total shutter lag as calculated during alignment, and if the plane is pounded out of attitude or position by a gust, the photo and the metadata no longer align, resulting in calibration failure and discarded images. This is why I specified that with Arduplane and Micmac, at least, the plane must have weight and inertia to hold attitude against gusts. It doesn't help that SK is famously gusty. I personally tried the system in a lighter airframe and was disappointed by the results.
The ultimate solution for this to use a camera with a hot-shoe and use CAM_FEEDBACK_PIN to log the exact moment the shutter fires. This is also done by the Emlid Reach RTK system, something I plan to add to my system in the future as well. Once I get my airframe properly powered, I can afford to fly a better camera without the fear of losing it on takeoff. However, most peoples' first attempts will likely involve a servo-triggered point-and-shoot, and this will work better with a heavier airframe.
Software... I agree with you fully in principle. I also write embedded code and PLC systems for agriculture and industry, and clean code that is inherently understandable and testable is a goal for us all. I'm honestly a little jealous that you have time and funding to write your own autopilot! It sounds like a great project.
The real risk with Ardupilot is not the codebase - it is mature and has been tested heavily by many users. It's the vast number of parameters that the user is allowed access to, and in many cases has to adjust to get good flight. A good example that you will see posted all over the internet in crash threads is that it's easy to build an initial setup where the sticks give the correct commands, MANUAL will fly fine, but the stabilization outputs are cross-controlled. When you then flip into an auto mode in the air, it will attempt to pull down elevator to correct down pitch - and as the pitch drops, the amount of down elevator grows, as does the throttle setpoint. This can put you in a very bad situation in under a second. When you flip back into MANUAL you are headed for the ground vertically with high airspeed, and had better have a plan that doesn't involve ripping the wing off by hauling panic elevator. This particular failure mode is responsible for most of the lawn darts, and the equivalent mix-up for ailerons has ruined a lot of wings. Bench testing in all modes is the solution here, as well as flying plenty high before your first switch into an auto mode.
Once it is flying safely in FBWA at low rates, getting it to fly a good envelope for mapping requires adjusting a bunch of parameters that can result in power-on stalls while in a bank, i.e. spins that grow into spiral dives. Even when it's setup and flying reliably, wind shear can still put you into some nasty stalls. The autopilot responds like a beginner pilot and is incapable of escaping these. This is why I recommend the pilot is capable of flying the full envelope of their airframe before attempting to install an Arduplane system.