rosflight / rosflight_ros_pkgs

ROS packages for the ROSflight autopilot
http://rosflight.org/
BSD 3-Clause "New" or "Revised" License
86 stars 56 forks source link

Questions about Attitude Controller Implementation #40

Closed sethholsinger closed 6 years ago

sethholsinger commented 6 years ago

I am trying to get rosflight working on physically hardware, specifically the bixler 3 platform. When I created my own attitude controller (based off of 'Small Unmanned Aircraft') using the Ju-87 model and constants in fcu_sim it works well, but it gives reactions that I think would not be physically possible (e.g. bouncing back and forth between the bounds of the control surfaces deflections very quickly). Is this common behavior for aircraft tuned by solving for the gains or is it abnormal and better damping and maximum error values need to be chosen? Also will better more realistic responses be gained by tuning through flight testing?

gellings commented 6 years ago

This question probably belongs in the rosplane repo, since rosflight currently doesn't have a fixedwing attitude estimator or controller (hopefully coming soon).

The Ju-87 model that used to be in fcu_sim (which is now deprecated) flew on the aerosonde parameters (Appendix E.2 from the book you mentioned) but the default rosplane controller was tuned for something much more like the bix3 (and it just might work for you). The aerosonde was an extreme aircraft that was built to fly really fast (I think it was built to cross the ocean or something like that). Both the rosplane and rosflight simulators have been modified to use coefficients that are much less extreme. You might have better luck with the current setup (rosplane now has its own simulator and can optionally be used with rosflight as software-in-the-loop).

Solving for gains often just gives a good starting point and gains are modified from there to achieve better performance. Remember that the transfer functions used to calculate those gains are only approximations. That said, I have never seen the behavior you are describing. Its possible that you made a mistake, I don't understand what you are talking about, there are defects with the simulator that don't match reality, or the aerosonde is just a really hard plane to tune. We do regularly see throttle bounce back and forth but I think good throttle-to-airspeed performance can be achieved by setting a really good trim throttle value (or writing a better controller).

I'm glad you were able to write your own controller! If you used the polymorphisum in rosplane to do it that would make me even more happy (if you don't know what I'm talking about them I'm happy to explain). It would mean our stuff is useful to others.

You should be able to get some good performance in simulation by playing around with the gains. PID controllers can be tuned without any knowledge of the transfer function at all. P is for speed of response, D is for damping, I is for overcoming steady state error (and should be used sparingly).

sethholsinger commented 6 years ago

To show you what I mean by my commanded deflections bouncing back and forth against the bounds here is the commanded aileron deflection: image As you can see it basically appears as a solid rectangle (obviously it is not). I am fairly certain this is because the gains that I am using are too high. For example my P gain for roll is 60 (max deflection 0.6 / max error 0.01). Elevator deflection looks the same and thrust change looks like this: image You can't see it from the graph just the general trend but each of these every peak goes down to zero before continuing the trend. For reference this is the trajectory that I told the plane to fly with green as the actual path flown and blue as the reference: image So these commands do seem to work. Any idea why the calculated gains are so high? I don't think my maximum error is that unreasonable.

Also how do I access the new simulator? And what is polymorphisum in rosplane (I haven't used rosplane at all yet)?

Also thank you for taking the time to answer my questions!

gellings commented 6 years ago

Wow, yeah that doesn't seem right! I think your max error might be a little small. Try something 10 or 20 times that size.

ROSplane https://github.com/byu-magicc/rosplane is a fairly simple implementation of the autopilot in 'Small Unmanned Aircraft.' It is implemented in such a way to abstract the ROS communication using inheritance and polymorphisum. Every ros node (controller, estimator, path follower, and path manager) corresponds to a different chapter of the book (chapters 6,8,10,11 respectively). Each node has a pure virtual base class that does the ROS communication and timing. By inheriting from the base class and implementing the pure virtual function you can easily create your own implementation of the node without having to reinvent the communication. Example implementations are also included.

ROSplane is constantly being improved. We have recently added a simulator that is stand alone to ROSplane. It can optionally be used in combination with this repo (currently the release candidate branch: rc1.0) to have ROSflight do software-in-the-loop. This means gazebo with emulate rosflight running on the naze. We are also adding other functionality to ROSplane including the design models from chapter 9 and the tuning functions that I mentioned.

Try cloning it, building, and running roslaunch rosplane_sim fixedwing.launch With some luck (and the dependent packages) it will work out of the box.

sethholsinger commented 6 years ago

Thanks for you help!