WIP - Live mixer tuning through mavlink including px4io #5726
Conversation
|
@magicrub Just so no-one feels left out, I did the same mixer stuff for ardupilot. That and you talked me into thinking it is the best choice. |
|
@crashmatt Hi Matt! Thanks for the PR, we'll take a look.
I'm not sure when I did that but I appreciate you checking out ArduPilot! Never hurts to see how other systems work, they all have their pros/cons and do things a little different. |
|
@magicrub Your not wrong about ArduPilot and px4 having different styles. I can't work out which will get me to my target quicker. px4 doesn't look strong on fixed wing support. ArduPilot has TECS and nice estimator features. It looks like ArduPlane doesn't run the px4 mixers when running SITL or HITL. This makes progress difficult and testing more so. A fix is to add the px4-fmu mixer devices to ArduPlane including SITL. |
|
@crashmatt this PR may be of interest to you: autonomous thermaling #5737 |
|
@magicrub The checks are failing on git submodule update --init --recursive |
| @@ -1,6 +1,6 @@ | |||
| [submodule "modules/PX4Firmware"] | |||
| path = modules/PX4Firmware | |||
| url = git://github.com/ArduPilot/PX4Firmware.git | |||
| url = https://github.com/crashmatt/Firmware.git | |||
There was a problem hiding this comment.
This is why Travis is failing. Changes like this are not allowed. You need to do separate PRs for submodules. Travis will only pull in branches from origin.
There was a problem hiding this comment.
The PX4 project appears to pull submodules from fork/branch. I might have been fooling myself.
Next step is to get those mavlnk messages fixed.
Considering the volume of real world fixed wing users I am tending to think that ArduPlane is best bet.
There was a problem hiding this comment.
Travis will pull whatever is in the submodules file, Semaphore might not. In any case, this would always have to be removed before merging. The error was there because the commit didn't exist in GitHub at the time - apparently it's there now so I've restarted the build and it worked; there are still errors but not related to this.
There was a problem hiding this comment.
Thanks Francisco. Travis is giving an error I understand. Semaphore is stuck with the module change as you suggest.
|
Okay I think I'm missing something but what are you looking to tune with the mixer? There are a couple of caveats that need to be thrown out there. First is that ArduPlane only uses the PX4IO mixer if you have activated overrides, otherwise ArduPilot simply submits PWM values that the IO directly outputs. Second you don't ever want to touch the PX4IO mixer while in flight. It can fail to accept a mixer, which would then leave you with no valid mixer. I typically see 4 attempts on average to program a mixer, and I've had the same mixer fail 1000's of times (It hadn't succeeded in programming it after 10 minutes of retrying). The current mixer protocol is just to weak to do this. The other note is that there is a very noticeable hitch in being able to control servos with overrides while the mixer is programmed (typically manifests as a freeze for about a second). Now it's possible I've missed the intent of this entirely (I haven't glanced at code yet), but @tridge has been talking about creating a proper RC Tx like mixing system on the ArduPilot side for a long time, so if that is what this is meant for that could be interesting. |
|
I had noticed the mixer reloads. Now I can report the number of mixers I
can see that the mixer is being reloaded too many times. Sometimes 8
mixers becomes 16, 24, 32 etc..
You are absolutely right about not reloading the mixers in flight. It was
that horrifying concept that lead me into this This scheme only modifies a
single mixer parameter at a time. The px4io registers are a few reference
indexes and a float value.
To fly the airframes that I do then I must improve the mixers. Without
doing this I simply can't get the aircraft back to the ground safely. At
$3000 per aircraft I am taking no short cuts. If I wish to fly then I have
to do this.
I was using the UDB autopilot but that came to an unsurprising end. Now I
have to move all my infrastructure over to something else.
The mixer parameters scheme I have prototyped is quite generic. It could
fit a wide range of mixer concepts. I am happy to change it but for now
now I built something simple to get things going.
If you have read the description document and it doesn't make sense, please
let me know.
/Matt
…On 16 February 2017 at 22:13, WickedShell ***@***.***> wrote:
Okay I think I'm missing something but what are you looking to tune with
the mixer?
There are a couple of caveats that need to be thrown out there.
First is that ArduPlane *only* uses the PX4IO mixer if you have activated
overrides, otherwise ArduPilot simply submits PWM values that the IO
directly outputs.
Second you don't ever want to touch the PX4IO mixer while in flight. It
can fail to accept a mixer, which would then leave you with no valid mixer.
I typically see 4 attempts on average to program a mixer, and I've had the
same mixer fail 1000's of times (It hadn't succeeded in programming it
after 10 minutes of retrying). The current mixer protocol is just to weak
to do this. The other note is that there is a very noticeable hitch in
being able to control servos with overrides while the mixer is programmed
(typically manifests as a freeze for about a second).
Now it's possible I've missed the intent of this entirely (I haven't
glanced at code yet), but @tridge <https://github.com/tridge> has been
talking about creating a proper RC Tx like mixing system on the ArduPilot
side for a long time, so if that is what this is meant for that could be
interesting.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5726 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAVcHaMOrtWvk1Bv2H4pBTJDmImsV1lcks5rdLvogaJpZM4MBFTb>
.
|
|
@crashmatt Are you trying to tune manual flight mode? As I stated the mixers are unused for any autopilot controlled flight stages, so tuning them would not have an effect. And under manual control your mixing can be done on the RC Tx side. |
|
@WickedShell The answer is both. The reason is a demand of aerodynamics. Consider aileron differential. Aileron differential depends on flap and airbrake setting and perhaps pitch. Flap position depends on airspeed and pitch. The transmitter has to send a roll command that the transmitter understands. How does it do this while also sending the mixed servo output? The mixer must be on the autopilot and be always in the loop. I am concerned that ardupilot overrides the mixing in autopilot mode. If that is the case I would not be surprised if the community has not moved much beyond flying wings and vtail. |
|
@WickedShell and here is the offending article: To make it worse this whole thing is lumped into the Plane class. Putting an alternative mixer system in means significant modifications. It is possible to build a new system in parallel with conditional build. That keeps the legacy code untouched for lowest risk. I have done all of this once before on UDB/MatrixPilot and that was back in 2013. And the next question is what mode that X-Plane override is running on. There is an override before and after the mixers. MatrixPilot used a plugin where the servos outputs could go to the flight surfaces rather than the pilot controls. If we can't get that level of control then there is no good way forward. |
|
@crashmatt The mixers need to be on the ArduPilot side rather then the PX4IO layer. The problem with the PX4IO layer is that it doesn't apply to all the different hardware platforms. We have far more control if we do it on the ArduPilot side. The only role the PX4IO is meant to fulfill is to actually generate the requested PWM signal, and takeover if the main FMU fails. I'm not opposed to a new mixer setup, but I don't think chasing the PX4IO side is a productive and safe solution. Especially as this is a feature that doesn't apply to all the supported board types, and a new mixer system that works on all platforms has been on the list. |
|
@WickedShell I agree that you need control of functionality on the ArduPilot side. The upstream px4io firmware has changed significantly. It has gained more multirotor hacks which have made the whole thing more cluttered. Having had a good look at both codebases, it is my opinion that Ardupilot px4io firmware has already forked permanently away from upstream. Best to make a clean break and do whatever is required for ArduPilot. The existing px4io mixer structure will not support my needs so I must re-write it anyway. It makes complete sense to do something cross platform compatible. Mixers run SITL for the px4 platform and that is the only way to succeed. The px4 mixers are compiled for both fmu and px4io. I don't see an immediate reason that they won't compile for ardupilot. My suggestion is to start this way, modify the px4io mixers to our liking and then make it a submodule. That way all platforms can use it. Does this make sense? For now I am finished prototyping the mavlink mixer tuning. It's main objective was to test if px4io mixers could be modified via mavlink. Given our conversation the details will probably change before commit. I will change focus to this new issue. UPDATE: I just compiled px4io MixerGroup direct into the Plane class and it works :-) |
|
Hi Matthew, adding a generic mixer is certainly a goal for ArduPilot. It was one of the motivations of the recent addition of the libraries/SRV_Channel work.
I'm thinking of doing it by defining new k_* variables in SRV_Channel, called k_custom1 to k_custom32. Then in a mixer file you could have: C1 = sqrt(Roll2 + Pitch3) * Rudder*0.1 that isn't a useful mixer of course, but it gives you the idea of the type of syntax I'd like. SERVO7_FUNCTION=101 |
|
@tridge Thanks for the list of requirements. I agree that the px4 mixer is not optimal. I think I am stuck with the px4io failsafe so I have to make it work nicely for manual flight. How deep do you wish to have access to internal state variables? Is it good enough to copy them to the mixer inputs or do you wish to have direct access? The existing .mix files are difficult to use since there is no context of what each value in the file does. Your syntax suggestion is much better. |
|
Hi Matthew,
I know this is all a bit vague at the moment. I'm still thinking through how all of this will work. Suggestions welcome! |
|
@tridge I agree that px4io/uavcan should not limit the ardupilot mixers. If failsafe mode has to operate with a subset of full functionality then that is ok. I just have the need to get my aircraft safely back to the ground, preferably in one piece. Have been thinking on your script proposal and the more I look the more I like it. It almost looks like it would run directly as python script which would make an interesting mavproxy module. As a use case test I started to re-write my existing mixer in python to see what it looks like. I will share this once I have it properly commented. Doing mavlink tuning is still a bit of a mystery but I am starting to get a grip on it. Very slightly off topic: |
|
@tridge One of the problems with this script is generating it from the autopilot. If changes are made to the mixer through mavlink then a new script need generating. It might be that we can have variables declared and those are the only changes allowed to the script. I can see a way to get all of the mixer descriptions through mavlink. I can also see a way that you might directly use system variables and pass the names of those variables to mavlink. Things are moving quickly now. Moving back to development on the px4 side. This is much quicker since the px4 mixers run under SITL. I hope to deliver a mavlink mixer support architecture that will support any mixer topology. This is the short term goal (1-3wks). After that I can come back to the mixer itself. |
|
Closing this for now as the conclusion is to approach this differently, as per discuss.ardupilot.org/t/better-mixers-for-arduplane-px4-mavlink-etc/9390 |
WORK IN PROGRESS - FOR REVIEW ONLY
This is the ardupilot version of this px4 pull request to enable fast tuning of mixer parameters.
PX4/PX4-Autopilot#6357
REVIEW ACTIONS
Mixer solution
Fix a consistent mixer solution for all platforms
px4io
PX4io resource and I2C loading.
Restriction on parameter writes according to operating/safety mode. The mixer has to be live for this to work.
Build configuration
The mixer tuning feature is completely optional. MIXER_CONFIGURATION must be defined for the build. This is currently hard coded into px4_targets. The original intent of this option is to reduce risk and reduce code build size on px4.
CHANGES
Changed from mavlink messages to mavlink commands.
TODO
NOTE: Mixer parameters are not the same as mavlink parameters. There is good reason for this. A description document is being maintained here:
https://docs.google.com/document/d/1LeQC2qtxqdesNuJ3RAWH_MJ_30xjf-PMN3bd5wtUAUo/edit?usp=sharing