Hello, I built a drone with the Holybro S500 V2 kit with a Pixhawk 6 FC. I am new to building drones and pixhawk, and when I arm my drone the motors are not spinning at all. Everything else is turning on and working the way it should, but the motors refuse to spin. I did ESC calibration multiple times as well. I tried out the motor spinning feature in QGroundControl and it didn’t work either. I have attached some pictures of my drone and the flight log.
Hi,
if your motors dont spin using the motor sliders in QGC menu . you need to check your radio telemetry whether it is connected to the drone itself. Also you could open another instance of QGC on a pc and try to operate the motor sliders from it. All the dual QGC operation depends on whether you are connected within the same network.
Hi jacob, I have already tried using two different computers and using the other computers sliders, and it still did not work. By the same network, do you mean it will work (motors will spin) if the seperate computers are on different networks or the same network?
I just have the SiK on my drone, I dont think any signals are actually passing through it, but I might be wrong. The transmitter is set up for the reciever.
great to know that you are replying to queries which I didn’t ask … …may be you didn’t connect your power cable to the escs or esc motor…please check …
He was using I/O PWM OUT without enabling the SYS_USE_IO parameter. After he switched to port to FMU PWM OUT it started working. I would recommend using FMU PWM OUT if you don’t need too many PWM outputs since IO is on the additional microcontroller.
I would recommend using FMU PWM OUT if you don’t need too many PWM outputs since IO is on the additional microcontroller.
@Igor_Misic We recommend using FMU PWM out (labelled AUX, if IO is present, MAIN if not) for racers due to the reduced latency of FMU. For other frames I understand that it isn’t something you particularly need to worry about.
This is still a point of concern. Probably we did not address this in the docs I assume.
It is a minor point of concern. I am not sure how to address it in the docs.
The SYS_USE_IO param is disabled by default on definition, but it is enabled by default on FCs that have an IO board. For for example, you can see this on durandal here.
What that means is that for this to be disabled on an FC board where it will do anything, you have to have turned it off explicitly. At which point you should have known you were turning off your IO board and hence your “MAIN” outputs.
We don’t explain it like that, but it is pretty obvious in the places where we suggest disabling IO, such as the racer setup.
I’m not sure where else we could make people aware of this. @Igor_Misic Do you think it might be reasonable to update the comment in SYS_USE_IO to note:
“If disabled, you will not be able to use the MAIN outputs on a board that has both MAIN and AUX ports”
The thing is we discussed it once in a Dev call before and we came to the point that this is not needed to be documented at that time since each board even if it is 6C might be different from each manufacturer to another regarding the mappings of these and sometimes I/O maynot even be available hardware wise.
Maybe we can just put notes under Holybro’s 6C for instance?
If we choose to add this to flight controllers then it should be done for all flight controllers that have an IO board.
But I see it as pointless for the reasons given above. It might be worth adding to SYS_USE_IO docs as I indicated.
@Igor_Misic Are you certain you need to turn it off to get the latency benefits? I thought with control allocation you can just use the AUX ports if available. In that case anyone touching this outside of an airframe configuration file is doing the wrong thing.
Are you certain you need to turn it off to get the latency benefits?
I never said anything about latency, but yeah, I agree, it doesn’t matter if SYS_USE_IO is disabled or enabled, connecting motors to FMU will have lower latency than using IO since FMU is controlling IO.
The good thing with control allocation and actuator tab in QGC is if you connect motors on the proper connector you don’t need to know the difference between MAIN and AUX, you just select a motor that spins (finally getting rid of this bad design decision with MAIN vs AUX naming)