Need Ideas for a Heavy Lift Flight Control System

[Amerly]

Jingchen


guanwulie@xair.cn

[h=4]管武烈[/h]极飞航空/广州/研发部 中国.广州

<tbody>
</tbody>

 

[R_Lefebvre]

Hey Guys,

Sorry about the confusion, some of the information is incorrect and let me help clarify a few things.

The ESCs are indeed compatible with refresh rates below 400Hz, the ESCs are compatible with refresh rates from 50Hz up to 600Hz, with the standard 1520us widths Flight Controllers current use allowing up to 495Hz. The KDE Direct XF ESCs can push higher frequencies (up to 600Hz), but still waiting on a flight-controller than can take advantage of this and change down to 760us or alternate bands, something future technologies will bring.

Anyways, long story short - there does not appear to be a verified synchronization issue with the SuperX equipment, and it's being used by various customers worldwide. Freddie did see an issue with his setup, but we haven't confirmed there is a compatibility issue and there could be another issue occurring (such as amperage-limitation from the PDB). Does anyone have a direct contact at XA that I can speak with concerning their hardware?

We've been in discussions with 3DRobotics concerning their hardware and they are using our equipment on their machines, so I'll find out more where they are at with their control algorithm. The problem with the Pixhawk appears to be in their negative-ground, and it's not with the KDE Direct ESC, but with compatibility with true opto-isolation. The KDE Direct XF series are true opto-isolated to the control leads to prevent noise entering the controller and as such, the flight-controller needs to be designed to handle this. There are simple work-arounds, but I'll check in with them and find out the current plans moving forward with their hardware.

Well, I'm glad to finally see some clarity about these 600Hz update rate. So it requires a shortened PWM pulsewidth. That now makes sense. This is no longer denying the laws of physics.

I'm not sure Arducopter will ever support 760uS and 600hz updates, since we view it as needless over-complication. We see more problems from vibration when trying to run at high rates than anything. I would like to add support for it just to say we can, because some people will believe what they will. And also because some people want to use helicopter servos that only work with this pulsewidth. But it's a fairly significant change so no promises.

I would like to talk about what you guys are seeing as regards the Opto isolated ESC's, not being able to arm, etc. And the suggestion of grounding issues with the Pixhawk.

First question: One your ESC's, are you using signal ground wires? (ie: you have a black ground, as well as signal wire in the servo plug going into the Pixhawk output rail?) If you are not, you must. If you are, and still not working, then I'd love to look closer at the situation.

I have used Pixhawk with several other Opto-isolated ESC's on helicopters. Both YEP 80A, 120A, and Hobbywing 70A, absolutely no problem.

 

[fpmurphy]

Well, I'm glad to finally see some clarity about these 600Hz update rate. So it requires a shortened PWM pulsewidth. That now makes sense. This is no longer denying the laws of physics.

I'm not sure Arducopter will ever support 760uS and 600hz updates, since we view it as needless over-complication. We see more problems from vibration when trying to run at high rates than anything. I would like to add support for it just to say we can, because some people will believe what they will. And also because some people want to use helicopter servos that only work with this pulsewidth. But it's a fairly significant change so no promises.

I would like to talk about what you guys are seeing as regards the Opto isolated ESC's, not being able to arm, etc. And the suggestion of grounding issues with the Pixhawk.

First question: One your ESC's, are you using signal ground wires? (ie: you have a black ground, as well as signal wire in the servo plug going into the Pixhawk output rail?) If you are not, you must. If you are, and still not working, then I'd love to look closer at the situation.

I have used Pixhawk with several other Opto-isolated ESC's on helicopters. Both YEP 80A, 120A, and Hobbywing 70A, absolutely no problem.

I had all 8 ESC's plugged in with their grounding wires. I didn't modify anything. I just got my Pixhawk working with my SimonK ESC's and my SuperX at least arms all of my KDE ESC's. The Pixhawk would consistently arm 6/8 of the KDE ESC's. They all armed at different throttle points. I think two armed with the Pixhawk and the other four armed at half throttle. The four that armed at half throttle would turn off if I lowered the throttle below half way.

 

[R_Lefebvre]

Curious, so your problem sounds like it's something to do with the PWM signal, not the grounding. Let's deep-dive on this, since this seems new.

Do I understand correctly that the KDE ESC's cannot have the PWM range calibrated? It's fixed? 1000-2000 uS?

Question probably only KDE can answer: Do their ESC's use an external oscillator to set the timing? I hope so. And what is the range of tolerance allowed in the arming procedure? 1000 uS +/- 5, or what? How much jitter and inaccuracy are you allowing for?

Murphy: Have you rescaled your throttle channel in your Tx to be equal to whatever PWM range the KDE ESC is looking for? If not, you should. Use the adjustable endpoints in the TX, to make sure the throttle range is the same as the KDE is expecting. You can see the PWM readout in the Mission Planner Radio Calibration screen. Once you have adjusted the range, then redo the Arducopter radio calibration procedure so that Arducopter is now aware of the new throttle range.

Then see if this solves the arming problem.

If it does not, then clearly we have a problem with a PWM mismatch. Either the Pixhawk is not outputting a consistent PWM timing on all channels. Or the KDE ESC's have a measurement error on those signals.

I can check for PWM timing consistency on the Pixhawk with a 4 channel scope. Not something I've looked at before.

 

[R_Lefebvre]

We've been in discussions with 3DRobotics concerning their hardware and they are using our equipment on their machines, so I'll find out more where they are at with their control algorithm. The problem with the Pixhawk appears to be in their negative-ground, and it's not with the KDE Direct ESC, but with compatibility with true opto-isolation. The KDE Direct XF series are true opto-isolated to the control leads to prevent noise entering the controller and as such, the flight-controller needs to be designed to handle this. There are simple work-arounds, but I'll check in with them and find out the current plans moving forward with their hardware.

Who exactly are you working with there?

 

[fpmurphy]

Curious, so your problem sounds like it's something to do with the PWM signal, not the grounding. Let's deep-dive on this, since this seems new.

Do I understand correctly that the KDE ESC's cannot have the PWM range calibrated? It's fixed? 1000-2000 uS?

I asked this question a while back.

For the PWM end-points, our production is set to arm at 1100ms (+/- 10ms) and maximum throttle at 1900ms (+/- 10ms).

Murphy: Have you rescaled your throttle channel in your Tx to be equal to whatever PWM range the KDE ESC is looking for? If not, you should. Use the adjustable endpoints in the TX, to make sure the throttle range is the same as the KDE is expecting. You can see the PWM readout in the Mission Planner Radio Calibration screen. Once you have adjusted the range, then redo the Arducopter radio calibration procedure so that Arducopter is now aware of the new throttle range.

Then see if this solves the arming problem.

If it does not, then clearly we have a problem with a PWM mismatch. Either the Pixhawk is not outputting a consistent PWM timing on all channels. Or the KDE ESC's have a measurement error on those signals.

I can check for PWM timing consistency on the Pixhawk with a 4 channel scope. Not something I've looked at before.

My throttle range was set for ~980 to ~2006. Within the ranges of the KDE ESC's, but not set to the exact range. Half way on throttle was well above 1100ms and by full throttle they all should have at least armed right?

 

[R_Lefebvre]

Ok, good info. So then I would strongly suggest that you set the endpoints in your Tx to 1100-1900, recalibrate the radio in Mission Planer, and try again and see what happens.

Yes, it still doesn't fully explain what you've observed, but lets try this one step at a time. If it still doesn't work, then we can start looking deeper.

If KDE or somebody wants to send me some ESC's I can look into it further. I'm fairly impartial. I don't make either hardware, I help write the software. It should be simple enough to confirm the Pixhawk is outputting accurate PWM signals, and that the KDE ESC's all arm at fixed points.

Why did they not all arm before reaching half throttle? I imagine the arming program in the ESC is looking for the PWM to hold steady in the 1100uS range for some short period of time. If you sweep through it too quickly, it probably won't arm. In fact, Mot Spin Armed may be hurting you hear, as it could be jumping above the proper signal too quickly. Then, as you raise the throttle, the Pixhawk/Arducopter will begin attempting to stabilize. It may just happen to move the throttle into the correct range to arm it. This is pure speculation though.

 

[KDE Direct]

Who exactly are you working with there?

I've been in discussions with their Director of Flight Operations (don't want to give out names online), and thus far, he's been great to work with. I recently picked up one of their IRIS quadcopters to try out their Pixhawk system, and will be upgrading this unit with a KDE Direct XF power-system soon. I sent an e-mail last night to follow-up on the status of their progress on compatibility of their system with the ESCs, and waiting to hear back with their findings.