John,
My intentions with the X-Plane and HIL-simulation was from the beginning to use it for helicopter simulations since I had a few nasty surprises that cost me a lot of cash that I really couldn't afford to fix. Now when the helicopter is in flying condition again I wanted a simulation environment to test all aspects of the code and hardware before trying to get it airborne again with the UDB in the cockpit.
When I started to ask around a little among the people that has written the plugin used for interfacing MatrixPilot to X-Plane I was told to first migrate the code base to the "new" standard that we have called "the 3.X" for a while. (It's the one that is built on the libUDB and libDCM libraries. This should do the work much easier and would open the doors for using some of the other great stuff that has been developed by the MP dev. crew. I started to look at it using the guidelines given to me by Ben Levit (studying the migration of the RollPitchYaw demo for UDB.) I was rather surprised when I realized that this wasn't the common goal for the rest of the heli community, and I then understood that there is no real cooperation between the MP development team and the MP-H development (team?). I was of the impression that you had been "pushed" in that direction before, but were unwilling to go that route.
When I couldn't get any help in developing anything for the "old" code base I concentrated on learning as much as I could about the plugin, datarefs and the "MP3.X" code base. I have since then been busy "debugging" MP3.X and the HIL-plugin. That is; I have used 100's of hours to find and point out faults in the plugin that wasn't so obvious at the first glance. Now there is said to be work going on to rectify the HIL plugin so that it works as it is supposed to, but I have no idea about the progress here. It's only a few weeks since I got my complaints classified as an "issue" or "issues" with the HILSIM plugin for X.Plane.
My understanding is that you have been busy with the magnetometer part of the project which is vital to the further development of working rotor wing code for the UDB. For a while it looked to me as there were several guys that were working on horizontal translation algorithms, but it has been dead silent in the "uavheliboard" for a long time now. My guess was that all came down to working magnetometer for control of the nose attitude, which I believe is the base for the work on translational algorithms in combination with altimeters with greater accuracy then a standard GPS. (barometric altimeters in combination with ultrasound or anyting else with millimeter resolution and accuracy.
I have had my ideas about how this should work, but since I'm not a programmer I can only speculate and do "pseudo code" for manipulating a rotor wing drone. (I was thinking vector math based on accelerometer and gyro inputs.) As I have understood the "original" Mahony papers is dealing more with vertical (helicopter type) drones with counter rotating rotors than airplanes. This was also a discussion among the MP devs to do a more "Mahonyish" code base.
I have no idea about what this really means to us, but I guessed that the "new" (3.X) code base was a step in that direction.
Then I don't understand (based on my knowledge level) why the heli code shouldn't migrate to the same code base?
Isn't it a "relative" easy task to port the MP-Hv2 code to the 3.X code base? On Ben it sounded like even I with my VERY limited C-skills should be able to pull it off (with some help and guidance from him).
I Have not had the energy to study all the different versions of the heli code since my health is deteriorating rapidly, but my guess is that it is originally based on the "Aileron Assist". Am I right?
Would it be a monstrous task to do this "porting" so that the helicopter specific control routines can use the libDCM and libUDB libraries?
If we were able to do this there is so much more to "leach" from the MP3.X There is virtually new functions and options coming each day. I hardly keep up with trying all the new development code being produced these days. In the last few weeks we have had added support for PPM input (8ch in and 8ch out), camera targeting that works wonderfully, Matt's CAN-Bus co-processor board that opens for some interesting possibilities, support for a bunch of telemetry protocols which of MAVINK seems to be the most sensible since it's binary, and now last we have "bumped" the speed of the telemetry UART to ridiculous speeds by using the internal (fast) clock and a 8x multiplier. (I'm currently running my telemetry at 57600 baud and had it running at 230400 just for test.
I really can't see why we shouldn't do a move towards the 3.X code base so I would be very glad if you could describe the hurdles (in a very short format and understandable way so that even an old soldier can get an idea of what's the catch). Just point out the main problems that hides from my un-experienced point of view, so I could get a better picture of what's going on and which path is the most sensible to take.
My whole involvement in this project is to learn C programming and to create a new base for a source of living for the future.
I have some ideas that have been growing in my head for the last 10 years... Now it looks like they might become a reality in my lifetime. (A small, cheap drone that's available to almost anyone, but more importantly; a drone that actually can do some useful work.)
I'm thinking SAR (Search And Rescue) since this is what I have been dong for the last 10 years on the side of my ordinary work as a computer network engineer.
My understanding of the MP-H is that it's your "brain child". I will no try to convince you to do this or that. My knowledge in this area is much to modest for that, and it's not my kind of being to try to "push" peole in directions against their will. I just want an (short) explanation to why the roadmap doesn't include migration of the MP-H to MP3.X code base.
My very best wishes for a merry Christmas and a happy new year to you and your family.
Talk to you later
/ Marcus