Hello all,
I have been doing some work on Peter Braswell's Ardusoar code (http://diydrones.com/forum/topics/autonomous-soaring?xg_source=activity) to improve thermal centring.
I finally got around to getting HIL working in XPlane to allow some cross country soaring simulations. I am using the PT60 model which has a terrible glide ratio (about 1:7) so thermal strength has been set quite high (1000 ft/min) although thermal coverage is only 10%. The Ardusoar code is working very well - the extended Kalman filter does a good job of centring thermals and almost never loses them. The throttle is set to zero when soaring but is re-enabled if the altitude drops too low, allowing automated climbs back to a good altitude. The flight mode is AUTO until an updraft is encountered (climbrate exceeds a certain threshold) at which point the mode is switched to LOITER. In LOITER mode, the Kalman filter is updated whenever new measurements (GPS positions and barometric altitude) are available. The update takes 4-5ms and doesn't appear to slow down the main loop below 50Hz. My repository is here if anyone is interested in trying out the code. https://github.com/samuelctabor/Arduplane
Below is a several kilometre flight (this was a 5-hour Xplane flight) with quite a lot of thermal encounters. The code includes logic about whether a thermal at a given strength and height is worth taking. This leads to quite a few brief thermal encounters in which the algorithm begins to search for the thermal but decided not to continue based on the thermals strength (too weak for the altitude the plane is at).
Below is the altitude throughout the flight (after the initial climb to 850m, the motor is off). There are a few long thermal climbs, especially early in the flight up to 3000m (cloudbase).
Below is a close up of a typical climb. After switching to loiter mode (purple) it takes a couple of circles to centre the thermal.
The filter's states are saving in the onboard log to allow post-flight analysis. Here the algorithm's estimate of the thermal centre location is the blue track. You can see it moves it quite a bit during the initial centring and very little after that.
The internal model of the updraft strength is a Gaussian distribution. Effectively the Kalman filter tries to adjust the estimated strength size and location to match the measurements.
As you can see the states change quite a lot during the initial centring. After that they are quite stable except for some ripple. This is due to the XPlane thermals not quite matching the Gaussian distribution assumed in the algorithm.
I am hoping to do some real-world flight testing when the weather improves here. Eventually this code is going to be used in a 3m balsa Bird of Time glider I am building, but flight testing will probably be done on something a little more tough and expendable, probably a Parkzone Radian.
Happy flying!
Sam
Comments
can someone recommend a RC glider in X-Plane10 to use for testing thermaling? Perhaps a contributed one?
I've just pushed support for X-Plane 10 as a SITL backend to master. That should make it much easier to test the soaring code. Just start SITL with the -f xplane option. You will also need to set AHRS_EKF_TYPE=10.
I am excited to see autonomous soaring interest growing here. To Gary's point, I am happy to chuck one or more of my Radians or Radian Pro's into the sky with ArduPilot test code on board. I am nearing launch of a PixFalcon based system, with airspeed indicator included. Perhaps that's valuable in parallel with simulator integration and SBC approaches? We have good thermal conditions here in Napa Valley.
Kelly
I think its one of those times that folks have to get out there and fly. Simulation will work to a point but real world thermals are super dynamic. In my part of the world the danger is too many vultures joining the same thermal and taking too much interest in the platform. Now onto the next thing.... wave who is up for that. Sam you are very well placed for the fantastic wave that sets up over Scotland and we have similar in August in the Drakensberg here.
I've been corresponding with both Sam and Kelly and I'm excited to see the enthusiasm. My plans for autonomous soaring are a bit different. I'm planning on an architecture that uses a Raspberry PI to do the soaring calculations and will simply send updated waypoint information to a Pixhawk in circle mode. I can discuss the merits of this approach in more detail, but suffice to say that I've noticed the same lack of good thermal simulation as well.
To that end, I've been working on a generic SITL framework that will allow easier sim integration with ANY simulator that outputs flight physics data that can then be converted into APM physics data. The way SITL is currently architected requires custom code integrated back into the APM codebase. This is an awful architecture and doesn't support loose coupling. My plan is to have a generic plug-in point to the SITL/APM code and to run custom code within the ROS framework, that then communicates back out to the SITL code in a standardized way. Thus to build a new integration, all you have to do is implement the appropriate ROS modules. It's still a work in progress, but I've proven out most of the constituent pieces.
To that end, the first simulator I intend to integrate is silent wings (www.silentwings.no). The soaring physics are reputed to be top notch and should be a good model against which we can test, no matter what the approach to the soaring implementation might be!
Stay tuned!
Hi Andrew,
I'm happy you think the soaring functionality would be a good addition to master. It would certainly save me having to keep the soaring fork up to data, which I have to say I am not particularly diligent in doing.
Simulation has been quite tricky. I did my initial development using FlightGear and XPlane in HIL mode, which did not make debugging very easy. I did have a go at simulating thermals in JSBSim by setting the wind properties but without much success.
I know Peter Braswell was working on adding SITL support for SilentWings, a good soaring simulator. I'm not sure how far he got with that but I'll ping him an email.
Once we get to the stage of having a good simulator interface, what is the best way to merge in the soaring code?
Thanks, Sam
Hi Everyone,
Kelly Foster pinged me about getting soaring support into ArduPilot master. That would be very nice I think.
Before I do that, I wonder if anyone here has good contacts with the X-Plane developers? It is clear that X-Plane is a good choice for soaring development testing, but right now we only support it in HIL mode. HIL simulation is never going to be really good enough for good testing as the timing is just way too bad. What I'd like is to get SITL working nicely with X-Plane. To do that we need support for lock-step scheduling in X-Plane. So we need an option in X-Plane where it doesn't advance the simulation time until it receives a new set of servo values from the simulator. That would give us really accurate simulation.
Cheers, Tridge
Sam,
Sorry to hear about your tree'd Radian. My very first RC flight was an RP that ended 40' up in a big oak. If we weren't on opposite sides of the pond I would send you one of mine.
I pulled the trigger today on PixFalcon (HobbyKing package including GPS, power board, etc.) and will be excited to receive that and drop it on my Radian or Radian Pro. I have put quite a bit of FC and FPV gear in my Radians, and am confident the PixFalcon and associated gear will fit. On one of my RPs I moved elevator and rudder servos to the tail, which opened up plenty of room in the belly of the bird.
Anything I can do in the meantime in helping merge your code with latest ArduPlane version? Happy to be a crash test dummy when there is new code to be QA'd w/o safety of sim. My foamies have many scars from lots of learning the past few years. Once ArduSoar is bomber, I am also happy to roll the autonomous dice on my Gracia 3.1M which should be a great test vehicle for your algorithms. I will pack my stripped down PilotHD or stripped down Mobius for full flight recording. Dragon Link for unlimited exploration. ;-)
Kelly
Thanks for your interest in the project! Always good to have people testing the code. I think the Radian is a great platform for soaring experiments. I need a new one since I lost mine in a tree! It does need some thought in terms of mounting equipment as there isn't much room inside. The pixfalcon looks very compact so that should help!
The ardusoar code is a bit behind the main arduplane branch as you have noticed (3.2.2 vs 3.5). At some point I will bring it up to speed and I aim to do more development this summer.
Any questions just ask.
Cheers
Sam
Sam & others,
I just discovered Ardusoar, and joined DIYdrones to be able to participate in this exciting system you have pioneered. I have a number of gliders, Radian, Radian Pro, UMX Radian, Magellan-XL 2.5M, and Gracia 3.1M. The last two, if you're not familiar are composite e-gliders. I picked up a Vector a year ago, and had a lot of fun getting it going on my Radian Pro. Separately, I am having a lot of fun with Radian (and to a lesser extent UMX Radian) thermaling with no FC or FPV, only Spektrum vario, pack volts, GPS, temp sensor onboard. I have been shaving grams with airframe mods and smaller motors and ESCs to get the Radian as light weight as possible. As I have been studying up on the FC space, I have been all over the map this week on next FC: APM, PixHawk, Naze32, CC3D, Pitlabs, or more Vectors. [The older FCs are only for a save-my-bacon-RTH capability on my bare Radian.] Given the discovery of your code, I am now leaning toward a PixFalcon, if that would work. Looking for best combination of size, weight, code capacity, modern architecture, future roadmap, platform stability and reliability, telemetry options, etc. My overall gear includes Futaba 14SG and Spektrum DX9 radios, a variety of receivers for each, DragonLink Advanced arriving any day now, and both 5.8GHz and 1.3GHz FPV gear. Really excited to get my gliders equipped with Ardusoar! I welcome your input on FC, pitot, telemetry, ground station, post processing analytics, etc.
Kelly