I'd like to see if I can help to get traditional heli simulation working. If I may impose, I'd like to get some general feedback from the community so that I can best direct my energy towards a solution.

 

Here's some background to help explain my motivations and abilities to contribute. I'm currently an undergraduate researcher in a non-linear controls research laboratory. My end goal is to use Fuzzy Logic to replace PID feedback control for an unmanned helicopter drone. I'm currently using a Thunder Tiger Raptor 90 as the testbed.

 

Of course, to test a new controller (especially on something as dangerous as a 90 series nitro), one must (ideally) have a working UAV platform first. In my search for a solution to the problems of finding ground station software, HIL, etc., I ran across Arducopter (much to my joy).

 

So now, instead of reinvinting more wheels than Goodyear, all I need to do to have a good testbed for my controllers is to help get HIL working for traditional helis in Arducopter, and add my own code replacing the PID control with fuzzy code.

 

The latter is something I'll likely do on my own, to submit for inclusion later (if anyone wants it). The former is something that I'd love to help with, but I'm not entirely sure where to start.

 

I'm currently the Robotics chair for our IEEE student chapter, so I could possibly contribute more than one set of person-hours to overcoming the challenges that are currently preventing HIL from working for traditional helis. I'm extremely interested in helping, and it's something I'd be willing to put a lot of hours into, simply because of how greatly it would assist me in accomplishing my own research goals.

 

So if you're currently working on HIL for traditional helis, or you know what's holding us back, gimmie something to shoot!

Views: 462

Reply to This

Replies to This Discussion

I think jasonshort is the one you'd want to talk to about changing the controller code. From my time here it seems he's the most active one of the coding team.

 

I'm working on a similar project (albeit mostly by myself) and built 2 custom quadrotors from scratch with the intent of using Fuzzy Logic methods to do the attitude and heading control, and have had some success. Perhaps the most notable difference with my project is that I'm using the HCS12 chip instead of the more popular ATmega.

 

This comes with the advantage of having built-in 8-bit Sugeno fuzzy logic opcode, but has the greater disadvantage of not being compatible with ArduCopter... so I see you made the right choice by not "reinventing more wheels than Goodyear." lol

 

I have to ask, though, about which fuzzy logic method you'll be using? Will ytou be using direct control or indirect adaptive?

 

By direct control, I mean that you essentially swap out the PID with the fuzzy logic controller. ( I have some experiance with this type of fuzzy controller)

 

By indirect adaptive I mean having a fuzzy-logic controller work in parallel with a PID, with the fuzzy-logic controller monitoring the output of the PID and adjusting its gains (Kp, Ki, and Kd) to achieve maximal performace. ( I consider this to be very advanced... and haven't gotten around to playing with the idea just yet )

 

 

P.S.

Also, which type of Fuzzy Logic are you considering? Traditional Mamdani or the simplifer Sugeno?

@ Allen,

 

I'll be using a little of both, actually. I plan on using an overseer model based on fuzzy to determine the desired values for attitude and thrust, and individual single-variable controllers for each servo that will control feedback on the servos themselves to hold those desired values.

 

As for tweaking the fuzzy sets themselves, I've got other plans for optimization that will likely end up being my Master's thesis if I'm able to get them up and running, so I'm not quite prepared to release them before I publish ;)

 

I'll be using traditional Mamdani since it's all I know in depth at this point, but I'm interested in Sugeno because of how well it seems to deal with the nonlinearities of heli flight. I'll do some research and see if I actually need to implement it to accomplish my immediate goals.

@Chris,

Sugeno uses the same input methods as Mamdani, and but differs on the output.

 

Mamdani outputs are 2 dimensional while Sugeno are 1 dimensional, which makes Sugeno functions much easier to defuzzify in MCU's as you'll only need to perform a weighted average of the singleton's. Matlab's webpage seems to cover the concept well.

 

Sugeno does have some interesting quirks, I'll give you that. If you have Matlab's fuzzy logic toolbox, try playing around with some different input membership functions and singlton positions and see what happens on the surface veiwer.

 

There's also a PDF or two floating around on the internet that goes into greater detail, even tells you some tips on how to design and "tune" a fuzzy controller. It generally starts off with linear PID-like controller that is gradually made non-linear through experimentation.

Yeah, I was just checking that out right now. It seems really promising, ideal even, when it comes to dealing with stuff like lift issues at high speeds. That's definitely something I'll consider as the controller evolves.

 

Of course, the biggest issue right now is getting HIL up and running for traditional helis. Real world testing would be quite costly considering how many crash kits I'd probably go through before I got something that would actually fly. What do you know about HIL?

Well so far my HIL testing has been "Code it into C, download it to the MCU, and run it through the debugger," although for a true HIL setup you'd have something that could monitor and modify the controller values as the hardware is running through the simulation... which for floating point numbers it gets hairy real fast.

 

Check with Jason or look around for some info on the ArduCopter's telemetry setup, you might be able to use its functions to "in-flight" tune the controllers.

 

P.S.

If that doesn't work out, then you'll need to figure out how to make the communications routines not interfere with the controllers as they're doing their calculations. Your probably not going to be able to get a fully-real-time operation though, because for RS-232 serial communications you have to send the data out as a string... 1 character at a time.

 

I'm currently working on getting communications setup to get the data saved by a "flight recorder" after each test run.

I was thinking about modding the code to have most of the computational stuff offloaded to a Pandaboard, and sticking the Arduino with communications with AC2 and I/O conversions from the sensors. I've been researching RTOS as well, but I'm not a fantastic coder, so I'll be having that conversation with my fellow researchers that know more about CS than I do.

 

Of course, that's a whole rewrite of the ArduCopter code, so that probably won't even be on the table until I at least get HIL working with the stock PID's on the Raptor. I want to keep my immediate goals attainable so I don't get distracted. An undertaking like this has so many fun tangents to go off on, that it'd kill my project's timeline if I tried to follow them.

Just went over the details of an HIL system, and it cleared a few things up with me:

 

HIL refers to testing of the embedded controller itself, and not the combination of the controller and plant.

 

HIL makes use of a "plant simulator" MCU ( the Pandaboard ), that tries to act as the intended plant (the Nitrocopter) by using a model.

 

The plant simulator does three things: simulates sensor signals ( input to the target Arduino ), simulates the plant's response to the target's output (output of the Arduino goes to the simulator) and simulates a disturbance to the plant model ( fed internally to the simulator's model).

 

 

The good news is that you don't have to recode the ArduCopter, bad news is you'll have to find some sort of system to get the plant simulation code running on your Pandaboard... you'll essentially be replacing the output of the IMU and AHRS with the output from your Pandaboard.

Actually, I wan't trying to run the sim on the Pandaboard. I was trying to run the same HIL setup that ArduPilot currently uses for fixed wing and multicopters. The software just doesn't currently support traditional helis.

 

I don't know if it's because Flightgear doesn't have a good physics model for small scale helis, or if there's a lack of flight dynamics models for small scale helis, or what the problem is. I'm trying to find out why traditional helis are not currently supported, so that I can know what problems I need to work to solve.

 

I was talking about porting the APM software to Pandaboard just to have more processing power available for the autopilot. Having the same code running on a Pandaboard, you could even integrate stuff like optical flow tracking and target acquisition using webcams in real time. That's something I'd like to see about later on, but there's no reason to start something that intense until I get the base platform working for my Raptor 90

Really? I wasn't aware of that. I don't think the physics model would be the major problem to Flightgear though, could be just a shortage of people.

 

Ah, as far as trying to get the APM software onto the Pandaboard, your going to have a bit of trouble figureing out which parts of the code is specific to the ATmega and then replacing those parts with something the Pandaboard's processor can understand. Once you get those bits replaced, then you'd have to compile it with the Pandaboard's compiler and of course debug it ( fun! ).

 

I finally got around to getting Arduino's IDE last night, and loaded up the ArduPilot project files (called a sketch, I think). I haven't had time to comb though it though, as I have 1 class in particular that's draining my time and getting on my nerves... I'm sure you've had at least one of those, eh?

I've definitely had those classes before XD

 

The story I hear with the physics modeling is that for some reason, FlightGear and/or X-Plane's physics models aren't linearized around small-scale aircraft, so the simulators tend to break down with the lower mass and moments of inertia and such. That's just what I hear though, and I hope someone will correct me if I'm wrong.

 

What we truly need is for one of the major RC sim developers like RealFlight or AeroFly to add the capability to export their telemetry data in real time the way X-Plane does. If we had that, we could instantly integrate any of the RC platforms within their libraries. To my knowledge, both of those packages already take in a PPM stream like a standard trainer cable from an existing controller. That format would be easy to output from ArduPilot, wouldn't it?

 

As an aside, I posted on AeroFly's forums, appealing to them to add real-time telemetry export as a feature. Their current response is that there aren't enough people asking for the feature to justify adding it. If you'd like to see them change their minds about that, go here and add your voice to the petition:

 

http://www.ipacs.de/forum/showthread.php/4754-Real-time-flight-data...

 

 

Now, I'm no MEEN, but I'm guessing that because small-scale craft are so light weight, in-house testing would be nearly impossible to get anything really qualitative, because you'll maybe have 5 seconds before the air recirculates into eddy currents and signficately reduce the lift generated by the prop's. Planes have it easy because you can stick them in a homemade wind tunnel to test their reaction. Helicopters (including multi-rotors) have the the hardest because they're far more complex mechanically and can't be tested in a closed environment without some sort of system to prevent the eddies.

 

I cannot tell you how annoying that air conditioner is during a test run, Lol.

 

Now as far as AeroFly gose, you might be able to get a successful appeal if you can get a dozen or so MicroUAV developers  to chip in. I'll think about it over the next few days.

Traditional heli sims account for those vorticies. The problem is that the physics are very non-linear.

 

Computers have a very hard time modeling non-linear systems, so developers do what's called "linearization", where they use a linear model that approximates the nonlinear one. The problem there is, when you use linear approximation, you have only a narrow range of operation where the approximation is accurate. In other words, you can only pick a certain range of inputs where your system will produce valid outputs.

 

What this means to simulation software, is that you can design a sim for an aircraft that weighs hundreds or thousands of pounds, and the approximations work well enough. But when you plug in a model of a craft that only weighs ten pounds, all of the measurements for thrust, moment of inertia, and everything else, produce results that are outside of the ranges that the simulator was designed to work in. That's why RC simulators are based on completely different linearizations of the atmospheric physics models.

 

But along the point you were making, it's true that helis have a good number of quirks because of prop wash, vorticies, and the ground effect. Good sim environments account for these variables. We just need a good RC sim to support HiL and our problems will be solved without the need to reinvent the wheel.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service