Hi heli group!


Allow myself to introduce.. myself..


I'm Chris. I work in a controls research lab at UT San Antonio as an undergrad researcher. I'm currently doing research to apply fuzzy logic as a replacement for PID feedback control in complex systems such as traditional helicopters. ArduCopter is something that looks to be very promising in helping me solve the numerous problems of system integration that stand in the way of having a working testbed for my control algorithms.


The only thing standing in the way of progress for me is having hardware-in-the-loop simulation working for traditional helicopters. Our lab runs a Thunder Tiger Raptor 90 as its testbed, and to be blunt, I'm scared to death of trying to test a brand spanking new control method on a 90 series nitro heli.


I'm new to the open-source community, but I've got a huge vested interest in seeing this feature added to ArduCopter. This project is something that I can most likely devote not only my own time to, but also the time of my fellow researchers, as well as the time of the members of the IEEE Student Chapter Robotics team that I currently chair.


If I don't hear back from anyone in the next couple of weeks, I'll assume that nobody is working it, and I'll start the project on my own. But if you are currently working the project and need help, I'd gladly accept any guidance that you might have, so that I can help the effort along.




Views: 6064

Replies to This Discussion

Have you looked at the hardware-in-loop for quad rotors?  I think you would be able to find or create a flightgear traditional heli model that would work and then be able to adapt the code.  I haven't tried to do hardward-in-loop yet, but am certainly interested in trying it at some point as well.


As far as I know no one has done HIL for traditional heli's yet, but only Randy would know for sure.


HIL for quads info can be found here if you haven't already seen it (I am assuming you probably already have)


Would be really interested in HIL for Trad Heli :)

Nobody's done it for the trad heli yet and it sure would be a huge help in particular for testing new versions.  I had a mild crash 2 weeks ago which certainly could have been avoided with some simulator testing.


As graham says, the first step is making the equivalent of the quadhil.xml file.  I'm hopefule that one of the other ardu-developers adds some get-started advice...maybe an overview of how it works..

Currently the quad hil uses a very basic physics model, Flightgear is only there for visuals.

As for heli i did have some plans to use xplane for the physics model and the do some mixing/demixing, to make it work with a full size heli in xplane, but have yet to start, as other things keep popping up.

I posted on AeroFly's forums. They've had some people asking about supporting HiL on their forums, and AeroFly responded saying that not enough people were asking for the feature yet, so it wasn't a priority for them.


Having a sim like AeroFly would make integrating just about any system nearly trivial. If you'd like a dedicated RC sim to support HiL for us, go to this site, register on their forums, and post in support of HiL.



the problem with all the simualtors is they dont use a geographics refrence system. ie lat/long. all the AC and AP and Heli code is based around this.

I see. So they would need to be able to reference with real-world GPS coordinate systems to output a viable stream then, eh? I imagined that might be an issue, but I didn't realize that the code revolved around it so completely.


If I might offer a short-term solution, would it be possible to have the ground station software use the telemetry data from the simulator to construct a fake GPS signal that would conform to the stream that the hardware needs?


Question: Does AP use the GPS data as the primary data feed for localization, or is it solely used to relocalize to correct for accelerometer and gyro drift?


If it's only used for reloc, then could we modify the localization code in AP to just take in absolute position data from the simulator and fudge it into fake GPS coordinates to fix the interfacing problem?


I don't know about the fake-GPS idea..i'll have to leave that to Mike or other to answer..but definitely the GPS is the main (the only?) sensor for determining horizontal position.  The accelerometers and gyros are just for attitude.  I've heard some ask whether you could integrate the accelerometers to come up with altitude + position but it doesn't seem to work.  The differences in the accelerometer values when you're climbing (slowly) are miniscule and are quickly outweighed by the noise from the sensor...that's my understanding anyway.


I think Mike may be having another look at xplane and whether he can get the basic connection working.  xplane is $29 (plus shipping) from x-plane.org.  If he can get the basics working would you be willing/able to help us get it tuned & tested?


Yeah. pressure sensors are the best for measuring changes in altitude. Accelerometers and gyros are good for immediate feedback on where the craft is moving at the moment, but floating point rounding errors and sensor noise make them completely unreliable for measuring absolute position long term.


As for helping to test with X- Plane, I'd be happy to help wherever I can. I'm rusty with coding, but I'm pretty good with the intuitive problem solving side of things, and I'm good enough with most code to at least understand what I'm looking at, even if I'm not good working from scratch.


My first question is whether we'd be able to use a custom physics engine in X-Plane. X-Plane's default engine isn't great for small form factors. If we can change engines, I know enough math that if we had a good non-linear atmospheric model, I could do the Taylor expansions to linearize within the operating regions we're using. What I CAN'T do is take those equations and turn them into a bona fide physics engine that the simulator can use.


Overall, I'm not a huge fan of reinventing the wheel. The physics engine is the one exception to that rule for me. It's hard to adapt the large scale physics to work with RC aircraft, and if we DID take the time to make our own engine, we'd have a solution as good as any consumer model out there.



you can override then physics in both flightgear and xplanes. xplanes needs a custom dll though to set the option.

i have just uploaded a version of the mission planner that support heli hil (beta) in xplanes.


you need to change

mavlink_msg_rc_channels_scaled_send in mavlink_common.h to output


  10000 * g.rc_1.norm_output(),
        10000 * g.rc_2.norm_output(),
        10000 * g.rc_3.norm_output(),
        10000 * g.rc_4.norm_output(),


and then start the MP


make sure you radio/etc is setup

goto simulation

tick heli

change the sim gains to

5000 (because im using servo out this is actualy an angle to gte 1-1 mapping use 2500 which is max_pitch/roll)





click start xplanes


click start sim link.


and it would be working.



Do we have a good physics engine for small scale helis in X-Plane, or are we using the stock engine?

I haven't worked the sim just yet. Do I just need to redownload the base software and make the aforementioned changes?

Also, all I currently have is an arduino mega. I assume that's all we'll need for HiL, right? I won't have approval to purchase the full avionics package for a few weeks, but if we get HiL working, I might be able to get the process fast-tracked.


     I'm 99% sure you'll need the oilpan as well to get HIL running because otherwise the code will stall at initialisation when it tries to connect to the dataflash which is on the oilpan.

    You shouldn't need a mag, gps, sonar etc though.


    You're in new territory with the simulator for trad heli.  So it would be the stock physics engine in xplane.


© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service