I want Aurdupilot Mega to control a Horten airplane. My aim is to use APM in this 1:5 semiscale Model of a Schapel SA-882 (see http://www.twitt.org/schapel.htm for a description of the original)
The Model has a span of about 2,08 m, made of playwood with silk covering. It was originally a microturbine airplane (with Martin Lambert's 20N Kolibri), had a TOW of about 4,9 kg (including 1,2 litres of Petroleum). I exchanged the microturbine by an electric motor Scorpion S-4025-01driving a 13 x 8 " propeller on 6S Lipo. Now it has a TOW of about 4 kg. I still have to do the maiden flight with that setup...
Before I go into using APM as an autopilot I want to use ist as a logger to analyse the design. I've been doing some work on the code to include the changes I need (also added functionality for the Attopilot current sensor). And wrote a program to extract the data from the logs. It's the first time I ever work with a microcontroller, but thanks to Arduino it's the same as programming in C++ :D.
Yesterday I installed the APM into the smaller sister of the above airplane. Namely, into a 1:8 model of the Schapel. This small model was designed to be a speed model, in contrast to the larger one which was designed for more acrobatic movements. Nevertheless, the small one reaches speeds of about 250 km/h on a 800 W setup (a friends one, not mine), while the large one reached also speeds way above 200 km/h with the turbine.
As always, the first time one makes errors. I installed the APM flipped, so that the yaw information is mirrored. Nevertheless, it was yesterday a rough windy ride and I was happy to make 4 logs during motor and gliding flight. I was also sort of "rusty", due to the bad weather here in Germany it's about 2 Month that I flew. The sight was also bad and it was freezing (-3 C). So, I was very happy to not have broken either the airplane or the APM. Here is one plot
The figure displays a gliding situation. The phugoid oscillation is clearly displayed (long period oscillation in altitude and velocity). In theory, the period should depend only on gravity and flight speed, which is more or less confirmed by the data. A strong oscillation in pitch is seen up to 880 s. I was probably still correcting the plane's attitude after turning. Afterwards we find two oscillations. One has a period of about 1.5 s (data between 885 and 890 s) and the other one is faster with a period about 0.7 to 0.75 s (see data between 898 and 900 s). The faster one is probably the so called short period oscillation in angle of attack, and the larger one is the second harmonic of this oscillation. To display the faster one better, a higher rate as 10 Hz would be needed. I would have to turn on the 50 Hz logging.
BTW the measurement shows a lift coefficient CL of about 0.6 and a gliding ratio of about 6 (i.e,. CD=0.1), which is not fantastic, but for a small airplane it is also not too bad. I guess I was flying the plane near stall, as my simulations tell me that stall is at about CL=0.6. Essentially the measurement confirms my simulations, as the gliding ratio was calculated to be 9 at stall (not including the cabin). Next time I'll trim the airplane to 60 - 65 km/h, where it should have theoretically a gliding ratio of 16 (realistic probably 12 or 13).
I will keep you informed on further progress ;)
Regards,
Andrés
Comments
http://vimeo.com/3894074
I managed to electrify the Horten. In the first attempt I had a problem with the propeller (it broke due to too much power) and the motor, shaft and propeller did some more or less minor damage to the fuselage and wing. I repaired this, changed the propeller for a CFK one and made about 10 flights in the last weeks. I used the APM as a logger for attitude, position and current. The next step will be to set the APM for the Horten and do some testing. I'll keep you informed...
Andrés
@Carlito: If the plane is designed well, it does not not need drag rudders. Essentially, roll and yaw have to be coupled aerodynamically in a proper way. Done this right, you need only the elevons to fly. That's why I think Hortens are perfect for autopilots, as only two servos have to be controlled ;)
@Mark: Sure, I will publish the "enhancements" or changes. I hope actually that not many changes will be needed in the stabilization and navigation algorithm. At the moment I'm fighting with the currently changing development version of APM...
@Pete & Lew: Currently I have no plans on flying that fast. I'm happy if the plane wil be autopiloted properly in the 100 km/h range. Here in Germany you are not allowed to fly UAVs out of sight, i.e. you have to be able to stop the autopilot and fly it manually at any instance. Now imagine how tight the autopilot would have to work to keep the plane in sight (+- 250 m) at speeds of 70 m/s... I will have a look at the references you posted, though. One never knows if I change my mind about the speeds one day ;)
@Lwe: We have plans but we are not distributing them at the moment.I hop eyou understand that rhere is a lot of work and know-how behind such a plane. The time to build the large one is about 350 h and needs advanced skills in wood-construction.
Regards,
Andrés
I've been screaming about this (not to you - just in general) for about a year now. Most people seem to forget (or ignore) the fact that GPS has several lagging components. In order to compute a vector, GPS must have more than one point; this means that by its very nature, it must lag (as it integrates prior points). Convert a circular path into vectors and this becomes obvious. In addition, there's integration lag (as a Kalman or other solution, internal to the GPS, "blends" the location data), error coefficients (from GPS accuracy), transmission delays (especially at serial speeds), and end-user software integration delays. A few solutions account for this, by reintegrating the delayed GPS measurement and correcting the predictor. Yet others use a commercial GPS that provides lag computation output, so you don't have to guess the delay factor of their integrator.
Here's an elegant method of integrating GPS latency into the predictor model, and here's a research paper that accompanies it.
http://www.century-of-flight.freeola.com/Aviation%20history/flying%...
You can see the code for dead reckoning here. Note that the dead reckoning is continuously adjusted by the GPS data when it arrives, and also takes account of the fact that the GPS positions when received from the GPS, are actually the position from a second or so ago. (Both the EM406A and Ublox 5 have significant delays in the position that they report).
The Dead Reckoning code was developed by William Premerlani.
-
1
-
2
of 2 Next