Hi, I have been successfully flying a big X8 copter running the ArduCopter 3.6.9 software on a Pixhawk 4 Holybro. But I’ve read about the critical fix with FrSky telemetry (which I use) so I decided to give a try to the fixed version. But something went wrong as two motors (6 and 7?) weren’t working. I use DSHOT for controlling the motors. All was running perfectly smoothly with the version 3.6.9. I send two logs, the earlier one with 3.6.9 and the latter one with 4.0.1rc3. Were there any changes with respect to the DSHOT control? (using the FMU outputs, of course)
How to update Pixhawk 4 Holybro? Should I use the Pixhawk4 or fmuv5 branch? I guess it was fmuv5 displayed as an USB name before and now I’ve used Pixhawk 4 (I’ve found this recommendation on yt). What’s the difference?
I’m not very unhappy as nothing bad happened
Another question related to firmware versions: why Mission Planner still offers the choice between frame types at the level of choosing firmware? (Quad, hex, etc). Have not these been consolidated into a single firmware file with choice done by means of parameters?
EDIT: MissionPlanner suggested the version CUAv5. But now motors 6-8 don’t work…
Your 3.6.9 log reports FC as CUAVv5. By all means, it’s a F765 with the same sensors, so probably identical to Holybro. But, and that’s interesting, the CUAVv5 has only 6 FMU PWM outputs, unlike Holybro’s eight, so you shouldn’t’ve been able to fly an X8 from FMU.
Your 4.0.1-rc3 log seems truncated. Please make sure you load the Pixhawk 4 firmware.
Your outputs look funny, as motors 1-4 are spewed simultaneously over CH1/9, CH2/10, 3/11 and 4/12. And since the values are cvasi-identical, and 1-4 come from the I/O processor, that’s not DShot, it’s plain PWM.
Pixhawk4 is the correct firmware. But that target is almost the same as CUAv5 because both include fmuv5. But anyway there are some differences so use the right one.
Reload the Firmware for Pixhawk 4 and post another log that is complete. It should work on the 8 FMU outputs you configured in 3.6.9. Select the apj from here and load manually: https://firmware.ardupilot.org/Copter/beta/Pixhawk4/
Man, there seems to be a lot of activity with these output issues going around…
I’ve checked that for the combination Pixhawk4 / 3.6.12 all the motors are spinning. So the problem occurs between 3.6.12 and 4.0.0. Can someone confirm this? Is there a problem with the code or there was some configuration change in 4.x and I should adjust the parameters? I’ll try if Pixhawk4/3.6.12 flies in real-world conditions.
I’ll try to look into the code but I’m afraid it’s a complex issue. So are there any chances of making a regression 3.6.13 fixing the critical issue with FrSky telemetry and still being able to fly 8 motors with DShot?
Aux Chanel’s 7&8 are in a different timing group so try selecting chan 9-16 in the SERVO_BLH_MASK parameter and then the Dshot protocol you are using in the SERVO_BLH_OTYPE parameter.
You are right, I’ve noticed when trying the drone indoors that the motors 7&8 are idling slightly more slowly than the other motors (for 3.6.12), I haven’t observed this for 3.6.9. But could you be more verbose about the remarks with SERVO_BLH_MASK and OTYPE?
As far as I remember, I’m using SERVO9_FUNCTION up to SERVO16_FUNCTION.
I’ll try to start using the DShot telemetry, this could give valuable hints if some motors are idling or working with low power (which is hard to notice in X8)
I’ll check this tomorrow, but why should I set the SERVO_BLH_MASK and SERVO_BLH_OTYPE to anything other than 0? If I understand it correctly, these parameter should be non-zero only for non-multicopter aircrafts? From the manual:
For using DShot with multirotor motors, set MOT_PWM_TYPE or Q_M_PWM_TYPE on quadplanes to 4 (= DShot150).
For using DShot on non-multirotor motors like traditional fixed wings’ main motors (SERVOn_FUNCTION = 70 throttle, 73 throttle left and / or 74 throttle right), specify the throttle outputs using SERVO_BLH_MASK and set SERVO_BLH_OTYPE to 4 (= DShot150).
Because you have 2 timing groups for the Aux outputs and it might solve the problem by explicitly configuring all to Dshot. I don’t have a Holybro Pixhawk 4 but on F4/F7 boards where there are multiple timing groups “This is The Way”.
Sorry, couldn’t resist that after watching all the Mandalorian episodes
So are you saying that when I specify those SERVO_BLH parameters they somehow overload MOT_PWM_TYPE? And force the motors 7&8 to be driven from a different timing group even if not changing the physical connections?
Is all this stuff a secret knowledge not quite documented in the manuals? Can’t wait to check I’ve found a new problem with setting up the telemetry - I don’t have a Pixhawk4-type connectors for the “USART & I2C B” port…
It can’t change the timing group that is hardware dependent. It just tells select timing groups what protocol to use. You cannot mix protocols within a timing group so this can present a problem particularly on planes where there are servos and motor(s). This is the intention of these parameters.
I don’t fully understand this but will set these parameters and report the result. Thanks for clarifying these issues. In the worst case, I’ll go back to 3.6.9 and disable FrSky passthrough…
So I’ve setup the ESC DShot telemetry. For ArduCopter 3.9.12, when setting the SERVO_BLH_MASK to motors 9-16 (65280), only the values for motors 6, 7 and 8 are reported (voltage and temperature look reasonable). I would be really grateful if someone could confirm that either it seems there is a problem with these motor outputs, or I’m doing something wrong.
I’ll check for 4.0.1, but the problems with motors have been also there.
In 3.9.12, there’s no field:
SERVO_BLH_POLES defaults to 14 which applies to the majority of brushless motors. Adjust as required if you’re using motors with a pole count other than 14 to calculate true motor shaft RPM from ESC’s e-field RPM.
For 3.6.9, also only motors 6,7 and 8 reported, even if for example motors 1 and 2 ticked in the mask setting.
How do you have these setup up? physically are they all connecting to a single UART port? Then how do you have the telemetry setup in the blheli firmware?
I have this running on my hex and octo, all the telemetry cables get bonded together then plug unto UART 4. Then I set serial4_protocol to esc telemetry.
In the Blheli_32 firmware I configured the ESCs to send telemetry at a 10hz frequency
Exactly how you say and how it’s advised in the manual: all the eight telemetry ESC outputs are connected to a single UART (UART4 in my case). I haven’t configured telemetry in Blheli_32 firmware, because the ESCs are polled by the FC (accordingly with the SERVO_BLH_TRATE setting).
All my ESCs are identical, from the same lot, so I don’t think that any settings there could make a difference.
The whole problem seems to be related with the issue of no control for motors 6, 7 and 8, as I’ve described in the first post of this thread.
Which firmware version do you have? Are you using Dshot 150? (type 4?)
