Bugs (something to look into) for new servo and servo mix MSP
cTn-dev opened this issue · comments
So after some testing (big thanks to) @creyc, it seems that the BOXSERVO1, 2, 3, activation boxes are only displayed in custom airplane mode, since the servo mix is much more universal now, i think these boxes should be displayed for every model that support servos? (i am opening this for discussion)
Second (probably more pressing) problem, it seems that the smix isn't "live updated", so even when the data is sent to the FW, changes doesn't apply instantly and require reboot of the FW to take affect, i think this needs some fixing, anyway tell me what you think, you know where to find me.
CC @schugabe ;)
The only possible configuration where the BOXSERVOs can be used are with the custom airplane mixer. In all other settings it is not possible to edit the smix rules (and this would be needed to use BOXSERVOs) since they are pre-configured for other models. So this behavior is on purpose.
I did not add in "live update support of the smix rules" yet since I was not sure what features exactly are needed/wanted: e.g. should there be a "preview mode", ...
So, the BOX option should contain only "always active" option when the model support servos and isnt custom airplane?
The live update would be nice, i added little checkbox on the bottom that you can tick which sends an update to the FW every time any input/select box is touched in the UI, however save eeprom is never called (this only happens when you press the save button)
For all mixers except the custom plane (obviously) you can only change the settings that get sent with MSP_SET_SERVO_CONF. So you can hide the complete smix setup section unless the mixer is custom airplane.
How can the firmware distinguish between a "preview change" and a "write to eeprom change"?
the write eeprom is different MSP command (so to update and save the settings in servo tab) you make 3 MSP calls, when you are just updating you just make 2 calls
Does the "direction of movement" need to be displayed when the servo mix section is disabled ?
Yes this value is transfered in MSP_SET_SERVO_CONF and needs to be displayed for every servo (that is used for a mixer).
I'll look into the preview feature.
Issue #246 still seems to be present with this build, in doing testing with Airplane mixer.
Is there a repository with the current configurator version? The baseflight-configurator repo is still from January.
I have added the live update feature now but I cannot test it without the current configurator version: https://github.com/schugabe/baseflight/tree/livesmixupdate
There is no public repository anymore, you can test the live update with this build
https://dl.dropboxusercontent.com/u/31740/storage/build2.zip
I did a fast test with the new configurator. The live update checkbox works but you need to order the smix rules correctly: If you create three rules for a servo and delete the second the third will be ignored since there is an inactive rule between the active => sort the list by the rate value so that all inactive entries are at the end before transferring it with MSP_SET_SERVOMIX_CONF.
Ok, i look into it, in the mean time make PR for that code required for live update
Can you give this one a shot ? (it has the smix sorting in)
https://dl.dropboxusercontent.com/u/31740/storage/build3.zip
The sorting is fine now but if you remove two rules consecutive the rule deleted last is still transfered as active smix.
So the last deleted rule still has some non 0 rate value in it?
I wrote a little bit more robust sorting before the last message, is this build still affected? https://dl.dropboxusercontent.com/u/31740/storage/build4.zip
Yes it is still affected. You can check it for yourself. Just check "enable live mode" add 4 rules and then delete two. After this go to the cli tab and type smix. You will see three active smix rules. If you go back to the servo tab there are only two rules displayed. To get rid of the "invisible smix" you have to use the cli command smix reset
Without "live mode" this issue isn't present.
I am working on this and hopefully i will soon finish this, but i have tho say this really isn't a proper way of having an access api where i already have 3x sort in the code and i have to re-generate the UI half the time due to the fact that smix index changes, way too much complexity and all it creates is a hassle on the UI side and more potential for bugs in case i miss some required re-gen somewhere...
Please give this one a shot https://dl.dropboxusercontent.com/u/31740/storage/build5.zip
Any word on this one ?
Looks good now!
Using build 5 configurator as soon as I "Enable Live Mode" or hit "Save" the servo output goes dead until the FC is rebooted.
On another note, it seems as thought checking the direction of movement "reverse" box has the same effect as setting rate=-100, is there actually a functional difference in the standard airplane mixer or is this redundant?
The good news is servo reversing does seem to work correctly from my somewhat limited bench testing, which resolves issue #246.
Test with this one https://dl.dropboxusercontent.com/u/31740/storage/build6.zip
The rate=-100 setting is kind of redundant but I think it is a nice function to have since it inverts the complete servo and maintains backwards compatibility.
With build6 I cannot observe the "dead servo output"... at least the servos move correctly on the "motor testing tab".