-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make PWM allocation a bit smarter. #9268
Conversation
Only assign servo output if the timer is not used for a motor. Only assign a motor output if the timer is not used for a servo. Needs configurator update and more testing. Checking resource on the MATEKH743 on the CLI, with 3 motors, servos were correctly assigned to TIM4 outpus, instead of TIM5, even with outputs sets to MC_SERVO and MC_MOTOR
This would have worked with the assignment suggested in #9214. The following targets already have dual MOTOR/SERVO assignment in MC mode.
|
Here is the allocation result on the modified MATEKH743 target in this PR
|
@shota3527 can this be a potential problem for the vtol mixer profiles? |
Timer ids are needed to correctly replicate pwm allocation logic in the configurator
Removing motor 3, frees up timer5 for servos and servos get allocated to PA0 and PA1
|
@mmosca BTW I think there is a bug in the configurator. |
Setting all options as motor/servo causes issues with fw. I will probably change the assignment order to give motors priority (like in multicopter mode) Assign motors |
Good to know it won't be an issue wit VTOL. I would rather have that than this :) I am still planning on doing some extra work on the assignments. I will check the behavior to make sure we follow the servo order when doing assignments |
The stress test MATEKH743 target seems to handle things well. If all outputs are both servo and motors, It will go through outputs in order and claim all outputs in order, until the desired number of motors is achieved.
You should be able to achieve the same result with this pull request, hopefully before supporting overriding individual timer functions.
I flashed this to a MATEKF405 tricopter
It had previously been working (from INAV pre 1.0 to date ( and with MATEKF405 since .c May 2018)) |
MATEKF405 Quad appears to work OK |
And if you add a servo, will it land on s5 and second one on s6? Probably s6. It may skip s5 because of led |
I'll try that later. BTW, the tricopters (actually two of them) both have the servo on S1 (i.e. built prior to the later "S6" variant). And I'd really prefer not to have to dismantle them to change it ... |
That is my main concern for deciding if I should change existing targets. Out of the box settings may shuffle the outputs of some targets. I will add the possibility of forcing a timer to servos or motors, but the upgrade process may be painful. |
@mmosca MatekF722 with following configuration skips S5 completely ![]() Signal is not generated on S5, checked with the scope |
output_mode sets default, inidividual timer is processed afterwards.
Overriding individual timers is now working: timer_output_mode 2 MOTORS forces TIM3 to be a motor, and timer_output_mode timerId SERVOS forces it to servos. Timer id is 0 based, so TIM1 is id 0 Currently, setting s1 timer to SERVO causes FW to have no motors. |
It ends up on S6:
|
The legacy MATEKF405 tricopter steadfastly refuses to move the servo off S6 and to S1, with
I still end up with:
Am I missing some magic step? |
The timer id is 0 based. Try:
It will probably be more obvious once I add the timer Id to the configurator :) |
We have a winner ...
|
Excellent, thank you. |
Once this is ready to merge, I'll update |
|
||
Note: | ||
|
||
* `timer` identifies the timer **index** (from 0); thus is one less than the corresponding `TIMn` definition in a target's `target.c`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should mention the timer index shown in the mixer tab of the configurator. Probably easier for the user and less error prone than opening the target.c file to find the timer mapping.
Also, at32 chips call the timers TMRn.
After I validate the msp commands, this will be ready for review and merging. I will probably save any further target changes to a separate pr to minimize the changes in this one. Not changing a target just means that you are more likely to need to manually override a timer. The configurator without related changes should work fine, but won't display the timers or the options to override. |
Just checked that the msp messages work, now, to make the configurator send the correct messages. :) |
Dynamically allocate servo and motor outputs.
Motors are allocated first and outputs can be assigned as both.
When ensuring enough motors have been allocated for a given mixer setting:
Servos are only allocated from timers that have no motors, and servos are only assigned to outputs that have no motors.
Needs configurator update (iNavFlight/inav-configurator#1820) to easily:
This opens up the possibility of flexible with outputs on targets, and eventually may open up the possibility of asymetric setups, with different motor protocols on different timers, or different servo refresh rates and pulse width on different timers.
Adding/removing motors in the mixer may reorder outputs, and require re-wiring. We can avoid breaking existing setups by not changing existing targets, but I plan on allowing manually overriding a timer to be MOTOR or SERVO and show timer info on the configurator output display.
Goals:
For the future:
Do you want to build a scale 4 motor bomber model? Easy!
Oh, you want A bicopter with many servos? Of course, you don't need a new target for that!
Are you building a quad with walking spider legs? -- Why? But sure....