Great news from the UK tech news site, The Register, which is conducting an ambitious project to create and launch their own space plane, guided by APM. The latest trial, involving dropping the autonomous glider from a balloon at 30,000m (101,000 ft), worked great.
In some highly encouraging news for the Low Orbit Helium Assisted Navigator (LOHAN) team, a Texan high-flyer recently used the ArduPilot Mega (APM) 2.6 to guide a glider back to base from a heady 30,780m (101,000ft).
Larry Grater's North Texas Near Space 4 (NTNS 4) aircraft hit around 790km/h in an "extended dive" before levelling out at roughly 16,460m, after which it "hit all waypoints and loitered down over the landing location". Larry then took control and landed the plane manually via First Person View (FPV), as the insert later in this video shows:
Tremendous stuff. AS LOHAN fans know, we've got a 3D Robotics APM 2.6 for ourVulture 2 spaceplane...
..and here it is temporarily bodged into the aircraft for servo testing purposes:
Many of you have cautioned that getting the autopilot working properly is a extremely tricky business, especially since we have a supersonic, rocket-powered phase for our mission.
Agreeably, we were recently contacted by ArduPilot (the fixed-wing APM flavour) lead developer Andrew Tridgell - of Samba and Oz UAV Challenge fame - who put us in touch with Larry.
Comments
Way back in the early days of ArduPilotMega, I did some simulations for the folks over at IHABproject dot com ; for an APM enabled - return to launch mode - non-powered decent for the balloon return vehicle. I think they lost an APM test rig in early testing; but the basic idea is going up with helium and nature can take you very far downrange, so a real challenge was cross-country ground based teams navigating to follow/find the returning vehicle. The simulations I ran took many forms. Such as free fall, to full on lifting bodies. It was really fun; and wish they had gotten one aloft. I hope this demonstrates to the folks over there to give it another go. The APM has come a long way since those early days.
Congratulations, this is an amazing achievement. Truly unique. The next challenge could be powered flight back!
Best regards,
SAA
@ SERGIOS,
Soo.. the official APM speed record is now 790km/h? :)
Andrew, I'm looking forward to 2.76 for the reasons you mentioned. The current code writes a bunch of multi-rate data to an external SD card by way of UART2 and slows the fast loop to 38 Hz. This is just barely enough but does work for HIL, UAV test flights, and the HAB objective configuration. The file size ended up at about 22M for about 2.4 hours of data. You bring up a good point about high rate TM and diagnostics. After the flight I was able to run the equations for nav bearing calculations open loop, correcting for density and reproduce the winds that I measured on the way up. This says something about the value of telemetry data for post fight analysis and also something about the predictable nature of the upper atmospheric winds on a large scale.
Pretty wild that at 500 MPH, even 50Hz latency would only give you a single point of data for every 14.67 feet or 4.47 meters travelled. That's a good size distance relative to the size of the airframe. A lot could go wrong in that much space. Inertia and fluid dynamics might keep the plane going steadily downward, but as the spin showed, it wouldn't take much force to quickly change angular momentum along the roll axis. You could potentially complete a full rotation within that space. It's cold enough up there that you could probably do some overclocking, if that would improve latency.
Hi Larry,
Congratulations again on your flight.
Regarding the wind code and nav_bearing, you may have noticed that the current L1 nav controller is ground track based, so it is almost unaffected by the wind calculation. I say "almost" as if you have an airspeed sensor then the ground vector is calculated as a complimentary filter between GPS ground track and airspeed corrected for pressure altitude. The direction of the airspeed vector comes from a combination of yaw and wind estimate. So the short term (high frequency) component of the groundspeed vector will be influenced by the wind estimate.
I certainly hope that 2.76 does a lot better at high altitude than 2.65, but that hasn't been proven with a test flight yet!
btw, have you considered using a PX4 so you can do high rate logging to a SD card? Having a full 50Hz log of the sensors would be great for analysis, and would allow us to pin down any issues as we could essentially replay the full raw data through the code. That is how Paul and I tracked down the DCM issue with GPS latency. The APM2 doesn't have a big enough dataflash to store that much data for a HAB flight.
Cheers, Tridge
Thanks for the kind words guys. Over the next few weeks I'll post my mods to the stock Arduplane code. Actually the roll rate feedback issue that resulted in the initial dive is fixed in 2.76. The vehicle wanders about after controlled flight occurs because the winds estimate code that adjusts the nav_bearing needs a pressure altitude correction. I'm carrying around a curve fit for the atmosphere, so this is really no big deal. I'll likely fly this 2.65 based code one more time before catching up to 2.76 or later. With luck the initial part of the flight will be less exciting.
Regards,
Larry G
way to go guys !!! totally amazing. and here I am just trying to get over the 20 mile mark.........
-
1
-
2
of 2 Next