I've been working towards a realistic simulation of my high-altitude return-to-launch glider project in X-plane and this is the latest result which some here might find interesting.
The simulation is running with X-plane 9, APM-MP 1.1.36 (to keep the TAS into APM - more on that later) and a slightly modified version of ArduPlane 2.28.
To achieve the drop, I drag the aircraft up to the release altitude using the Local Map feature in X-plane and set the speed to zero. Whilst this isn't a perfect simulation of the intended release due to the flat orientation of the aircraft, for my purposes it is sufficient for now. Initially I allow the aircraft to accelerate in Manual mode until about 25kt IAS, then I switch to Stablize, manually manipulate the controls to pull out of the dive as rapidly as practicable before proceeding to switch into Automode. Eventually I need to code this whole process to trigger and execute all automatically in APM.
On this drop, I set the release point to be about 80 miles 'upwind' of the simulated launch point to make a rough allowance for the drift of the balloon on ascent. I am using the X-plane's real weather simulation (where it gets its weather data from some unknown on-line and quasi-real-time source), so I couldn't be absolutely sure what the headwind was going to be. This was the third in a series of flights, where the release point was selected from the experience of the earlier flights to give a likely head wind for the whole descent glide stage.
As you can see from the Google Earth image above, most of the travelling is done above the jetstream altitudes and the aircraft arrives at the loiter point still at nearly 45000 feet!
I logged the data using the data output to file feature in X-plane and then created a KML file using this method which uses this on-line file translator. Whilst logging the data in X-plane, I added more than just lat-long-alt and included some airspeed data so I could figure out a few other things.
The altitude profile shows the entire descent stage lasting a little over two hours:
and, the speed profile is here. You can see how the ground speed is fluctuating wildly as it tries to hold the loiter position. I'm not sure if the peak airspeed of nearly 500mph is achievable either because I didn't make a note of the Mach number, but it was probably less than 0.85. I suspect this could be an issue for airframe integrity...
More work needed here to limit the speed during the dive phase.
Finally, I integrated ground speed to give me an estimate of the distance I could feasibly travel from the release point. A pretty impressive number, don't you think? Line of sight all the way too! ;)
...and before I forget, here's a few details on the TAS problem I mentioned earlier.
The APM-MP-based HIL simulation up until recently has fed APM with true airspeed (TAS) from the X-plane data. I need this primarily for the PID loop speed scalar to allow stable control at high altitudes. The only problem is that this isn't what APM gets in real life from a pitot. The pitot-static system will give you indicated airspeed (IAS), or more correctly, dynamic pressure, which deviates wildly from true airspeed as density changes.
Michael Oborne has changed this in a later version (1.1.42 at least) so that APM now sees a realistic IAS number from X-plane, however this would mean I'd have to implement the IAS-TAS conversion in the APM code. I must do this at some stage, but for now having this little MP bug is a handy thing! :) Lazy? Moi...?
The APM software mod I've done is an embarrasingly simple one (yes, it's true I'm not a software geek!) where I expand the speed scalar clips from the standard 0.5-2.0 to a randomly selected 0.01-5.0.
Comments
Link
Paul, I don't really want to hijack the thread too much but you might want to look at the link above. I did end up using FG for my HIL simulations. With new versions of the code the SIL route might be best since you get better SW coverage. Either simulation has its limitations. FG relies on an externally created Flight Dynamics Model (FDM) which is comprised of table look ups and aero linearizations. I did try to create a custom FDM for the Stinger airframe at the proper inertia but pretty much failed. The only plane that seems to exist is the Rascal. It worked well enough for what I was modeling. Gains and constants were developed with a UAV Stinger. Nothing like the real thing. Regards, Larry G
So, where has this project gone? Any developments? BTW, I wouldn't hold my breath on FlightGear being better from my last experience with it their model had little to do with real world physics... but that was years ago. Maybe things have gotten better.
Thanks guys. I also increased the frame rate and minimized rendering. Perhaps with a faster PC I could get a better resut. Result is the same though and open loop dynamics are not representative.
I'm not stuck on X-plane either, but it is running and I've been able to use to help debug SW changes. I'll start looking into FlightGear when I get back from the ranch. There are some recent threads on how to get this working. Good to know about the development team.
I've been making good progress on SW mods for 1st flight. I've stopped working on gain scaling for now. Basically I'd like to do something similar to Andrew and scale rate feedback. I implemented a non-linear scaling using airspeed_pressure (Qbar). Airspeed_pressure had to be reconstructed using a simple atmospheric model for HIL. I'm using a 3rd order curve fit for density v altitude. I was shocked to see that the error in density is only 5% for SL-100k ft.
2 stage release code is done. This isn't autopilot gain related so X-Plane is a good prototyping tool. I'm releasing on altitude, time, longitude, and free fall. Computing the vertical velocity was done using an idea that the APM development team is about to use for a new FBW mode for descent rate. I re-wrote the upcoming linear regression code to use floating point to get around scaling issues above 20k ft or so. The plane stays on a drogue for 3k ft or so, then releases the drogue. I'm thinking I might use a EPS foam "drogue" that's rigidly attached to the back of the plane. Ultimately, I may not use a drogue but the code is there.
Looking forward to seeing more work in this area. Hopefully we'll end up with a simumulation that's close. Aero doesn't have to be right, but we need to have something so that we can double and half gains to do robustness testing. This should cover changes in Cld/Cmd due to low Re or other modeling errors. My gripe with X-plane was that results for Cld seemed to be high by 10X and not close enough. I'll post progress and setups for flightgear if I'm able to make this work. Some combination with Andrew's CFD results shoulds like the ticket.
Not being bloody-minded or anything. I just need all the neurons I can muster to make any sense of OpenFOAM, so learning another simulation package might be beyond my capacity for now. Back in civilisation at the end of the month, so hopefully some progress from there.
With X-plane, the trick is to get the Airfoil Maker data file representative. The supplied files are simply nonsense at model/UAV Re's
Hi Guys! Sorry, I am away from civilisation for a while with a very poor internet connection apart from my Android device on which I can't figure out how to avoid the mobile version of this site, so I'm not able to comment much.
I don't think X-plane is useless Monroe. I have managed to do some good simulations, but it can lead you astray if you're not careful. The trick is understanding how it models the wing L/D characteristics and inputing data that is more realistic for our Re levels.
Also, I have bumped up the frame rate, or at least the calculation rate to improve the smoothness. It's important that the actual video simulation doesn't need to be that fast, but there is a parameter there that allows you to adjust the number of calculation iterations per frame refresh. That needs to be wound up a few notches. I can't tell you what I'm running at the moment, since I'm away from my simulation machine, but a figure of 5 or 10 iterations per screen refresh rings a bell.
Also, I am still running an older version of APM-MP - the one that accidentally confused TAS with IAS or was it the other way 'round? I use this when I am high-altitude flying, because MP doesn't access the temperature and baro that's required to do the calcs in the APM to correct for TAS.
I also have a TAS-based fiddle factor on the gain speed correction and have also widened the limits that APM uses for this factor - this was a huge step, as the default code limits it way too much to be useful at high altitudes. Take a look in my earlier blog posts and comments - I'm sure I've posted details of what I did somewhere.
I hope this helps some.
Andrew, I have been having some issues getting X-Plane to give representative results at altitude for RC size aircraft. After reading a bit, the issue that I'm seeing is mentioned in the X-Plane (v9) documentation. Frame rate changes did help some. The plane is flying well at normal altitudes, but alt least for me, gains seem very ill conditioned at altitude. I found issues with the open loop dynamics at altitude that look as if Clp (roll damping) is scaled properly but Cldelta (roll moment/aileron) is not. The aero appears OK, including atmosphere, but pitch and roll are more sensitive than at low altitude. I have had success with the larger aircraft and found APM flew things like the F-102, B-52, others just fine with my RC gains. This was before special scaling. The simulation seems to start working well at 40k feet or so for my setup.
Can you provide detail on which X-Plane version, frame rate, and especially aircraft model? I am still using X-plane for SW verification of release, drogue release, timers, software robustness tests... but would like to be able to run end-end. The other option is flight gear. Thanks for the help.
Larry
@Paul, I hadn't considered using any variable geometry airframe like SS2. My aim was to have a minimally complex airframe, hence the choice of flying wing with only two control surfaces. I hope to be flying at least 20000 feet higher than SS2 and my X-plane work suggests this is possible.
I have been doing some work in the last few days on improving the slow-flight capability and have made some interesting discoveries that have allowed me to operate in controlled flight to within a gnat's cock of the stall break. This has lowered my minimum controllable flight speed by about 3-4kts indicated and my airframe can operate in Stablise mode at just over 14kts IAS in low turbulence air.
This improved stability will need yet more code tweaking in APM to make it functional, but once I've got it running, I'll probably post some more about it, since I'm sure others will be interested in it, especially for auto-landing applications.
@Monroe, you're welcome to republish my work here with appropriate attribution. I'd suggest asking Chris Anderson as well, since he kindly runs this site for all our benefit.
Andrew, have you considered an air frame design similar to Scaled Composite's SpaceShipTwo. My understanding is the feathered wing provides stable flight characteristics at high altitude.
BTW, I calculated the Mach number at the peak airspeed shown in the graph as 0.748. Possibly just transonic.
-
1
-
2
of 2 Next