I’m in the process of building a fairly unusual airframe.It’s probably closest to a Helicogyge (a helicopter where each blade is propelled by thrust at the tip of each blade). It has a few characteristics of a plane (glider like wings, tractor props) but is also very close to a traditional helicopter in some key aspects (it needs to control flight using collective and cyclical blade actions. It’s also different in that there are no non-rotating parts to the craft.
If you imagine a helicopter with two blades…get rid of everything but the blades, stick a forward facing prop on the tips of the blades, and then separate the blades by a tether so that the root of the blades are separated by a substantial distance (several meters). Each blade also has a small “tail” that is used to control blade pitch.
For now, I’m controlling pitch and throttle using a co-processor getting data over MAVlink from the Flight Controller (running ArduPlane). As each wing whirls around, almost every control action is influenced by the heading. I calculate RPM from heading changes (to govern the speed of the craft) and adjust the wing (blade) pitch for collective and cyclic control.
Problem is that the ATT.Yaw signal doesn’t seem very reliable. It has glitches. Occasionally, I’ve even seen the ATT.Yaw output “flip” and start to output a signal indicating that the rotation has reversed (physically impossible since it’s rotating while strapped to an office chair base).
Is there any other option for getting the current heading from ArduPlane? Any known limits on using ArduPliot code in a constantly rotating platform (10 to 30 RPM)?
One more question. How hard is it to add code that runs under ArduPlane? It was scary enough that I added an STM32 as a co-processor. But there are big disadvantages to anything complex running outside, i.e., …no telemetry and no logs.
Pretty close. My rotation rates are substantially lower since the two wings (blades) are tethered and are some distance apart. But I’d really like to find that code!
Peter…if you’re still interested in this, we may be able to provide some real vehicle testing for your code.
We have not 1, but 2, test setups that allow operations with a low risk of vehicle damage. We started out using a pole and tether (almost like a control line plane) and have flown in in a 40 meter diameter. Of late, we’ve been testing while strapped to an office chair since it is more constrained and allows for a faster development/test cycle.
I think our hardware is the same as your software envisions. We have normal ArduPilot sensors, radios, and flight controller (Matek F-765). Transmitter inputs are throttle, collective pitch, cyclic pitch, and cyclic roll. The outputs are THROTTLE (varied to control RPM) and ELEVATOR (varied on a long term basis for altitude control, varied within each rotation to “tilt the disk” in order to allow ground translation).
So (given our hardware design), I think your code might run on our platform. And (given our test configuration) we can test un-debugged code without much risk.
I don’t see the monocopter frame type in Mission Planner, so I fear I’ll need guidance on how to build and download.
Good news. I started looking at the two IMUs to see if there were any problems with the hardware. They tracked extremely well (so not likely). But I also decided to enable EKF3 during that test. It turns out that EKF3 does not have the issue with constant rotation in the 10-30 RPM realm that is evident with EKF2…
Here’s the EKF2 output for ATT.Yaw followed by the EKF3 version.
You can see that EKF2 doesn’t seem to handle the changes in RPM, while EKF3 does so nicely. Which makes my co-processor able to correctly govern RPM and generate cyclic control outputs.
