I’m currently working on a small hexarotor with a 330mm custom frame. So far I was not able to get it to fly at all, because during takeoff it always flips over, no matter which flight mode I use.
Because the drone is aimed to fly indoor, it doesn’t use GPS, but Optical Flow (Ark Flow module) for improved position estimate.
Today I did a few flight tests with the drone attached to a safety rope. I tried to takeoff in position mode and in takeoff mode. Additionally I tried to get it to fly in stabilized mode from a hanging position.
All three tries showed similar results, also regarding the log files. The motor output plots of the flight tests in position and takeoff mode show that the motors don’t spin up evenly. In the end the extreme deviation of the motor outputs causes the drone to flip. However the cause of this is still not clear to me, although it seems like it’s trying to reach a position that’s far off.
All tests were performed using a fresh build from todays release/v1.14 branch.
From a quick glance at your logs, I’d say motors aren’t connected correctly or autopilot orientation isn’t correct.
The autopilot wanted to pitch it one way, but the drone pitched in the opposite direction.
Next time take off the propellers, and then test how it works.
Best if you’d figure out how to interpret the logs.
Arm it and roll/pitch the drone. Then look at the graph “Motor Outputs”, and see if it spins faster/slower the correct motors.
You can even feel it with just your hand if you put it over the motor while giving enough throttle and tilting it in the certain direction.
Hi, thanks for your reply.
I’m currently doing some preflight tests as you suggested. To me the pixhawk orientation seems to be right, because moving the drone matches everything I can see in the flight view of QGC. It also matches the values I can see in the Attitude message using the built-in MAVLink Inspector.
However the motor outputs absolutely do not match the movement of the dron while hovering (without props, holding it in the air and roll/pitch it slightly). The thing is that it seems to be so far off from what QGC shows me, that it will take me some more time to dive deeper into this and analyse it in more detail, so that I can also share my findings in a proper way.
As a reference, my motor setup is as follows. It’s also configured like this in QGC and I used the “Identify & Assign Motors” function to assign the motors to their corresponding output. The arrow on my Pixhawk points towards positive x.
So motors 1 and 6 are the two front motors. In the log I can see that on a negative pitch (nose of the drone goes down) motor ouputs 1 and 6 go down completely, while 3 and 4 go up. The whole motor configuration seems to be rotated around the z-axis by 180°.
I will play around with different motor configurations until I find one that gives a correct response.
I am not using the new dynamic, but the old mixing system, so I am not experienced in using it, but I think I understand how to configure it.
I don’t know why you’d change motor ordering from the default one, which is pictured here:
Under Hexarotor X.
It’s only a hassle with changing the position of each motor, and you can make mistakes.
If they are positioned approximately the same way as in that picture, with ratios being the same, don’t change that.
You only have to decide on which PWM port you want to put a given motor, and then assign that in QGroundControl.
Say you want motor number 5 in QGroundControl to be on the Main port of the Flight controller, pin 1, you’d assign it like in the picture. Same goes for all other motors. So, motor 1 on Main PWM 2; motor 4 on Main PWM 3, …
After that, test with those sliders below that you didn’t connect something wrong.
I think I mainly changed the the order of the motors, because it’s easier for me to handle and analyse (at least it seems easier to me). But I think there shouldn’t really be an issue with using the original order and then just assign them to their corresponding PWM outputs.
I did a few new tests, one of them using the original motor order, as you suggested while keeping the rest of the setup (orientation and calibration) the same. The image below gives an overview of the setup. It didn’t really change much, meaning physically the same motors spin up when tilting the drone. This can also be observed in the flight log: https://review.px4.io/plot_app?log=cb6d8b28-5c1c-4a91-b3a6-bc40f38367c9
You can see that motors 4 and 6 (rear motors) spin faster on a negative pitch (nose down), which is the same as before. So the actuator configuration in itself seems to be consistent.
Next test I did was with a completely new setup, where the drone is on it’s back, resulting in a no-angle orientation of the pixhawk. Then I reassigned the actuators and changed the motor axis from downwards to upwards. See the image below for an overview of the setup.
This is the log of a preflight test using configuration 2: https://review.px4.io/plot_app?log=550755bd-5b5e-4315-8cfd-bc4a55b69332
The first thing I noticed during testing already, and which got approved by the log, is that the motors spin much slower in general and seem to be clamped. The clamping seems logical to me, because I don’t command any thrust, just arm in stabilized, lift it in the air and tilt. Besides that, it looks like the correct motors spin up. Like on the first positive pitch (nose up) motors 4 and 6 start to spin up. Also the rest of the motor outputs seem to be consistent with the movement of the drone.
The combination of both tests led me to the conclusion, that the setup of the geometry was wrong. I always assumed that the small diagram in the Actuators tab in QGC corresponds to a top view of the whole drone (with the coordinate system showing the NED body coordinate system). But it seems like I completely misunderstood this and it rather shows all the actuators with respect to the pixhawk itself, so it’s a top view on the pixhawk. In my configuration with the pixhawk being attached upside-down to the bottom of the frame, I actually have to turn my drone upside down and assign the actuators from a bottom view. So I did the exact thing I just described, basically using the actuator configuration from configuration 2 from above (also with upwards motor axis, as seen from the pixhawk). The whole sensor configuration is done in the drones normal orientation, so with roll=180° and the drone being level when standing on its feet. The log file shows similar results to configuration 2, also with correct response from all the motors.
Log File: https://review.px4.io/plot_app?log=55914a11-e867-456e-ab64-44e57c76a5e4
I will need to do a real flight test to verify all this, but at the moment it seems promising to me.
Just to finish this off, I did a few more preflight tests and also an actual flight test today. The motors now respond correctly when the drone is tilted.
During flight test in position mode, the motors correctly start to spin up once throttle stick rises above 62,5%. The drone then starts to tilt a bit to the side, but this looks more like an imbalance issue, rather than some error with the configuration.
After a longer break I found some time to do another test flight. In the meantime I also slightly changed the configuration. The log from my last reply actually shows that the motors did not respond correctly. Also in previous preflight tests I completely missed that the outputs were mirrored between left and right side. So I switched the motor outputs again to make it work.
My final setup is as follows:
The geometry is defined in the drones coordinate system with respect to the drones center of gravity. This means x forward, y to the right and z down, like it was in the very beginning. The only thing that was changed is that the motor axis setting is now upwards (default) instead of downwards.
I also noticed that I forgot to mention this initially, so note to myself to include this in the future, because it’s kinda important.
Explanation:
For some reason I assumed that the axis setting is the physical orientation of the axis, so because of my pusher setup I changed it to downwards. Howeverr the rotors are of course attached in a way that they provide thrust in the upwards direction. When I had all of them set as downwards, the flight controller attempted to flip the drone over, to be able to get upwards thrust and takeoff. This of course resulted in a crash.
TL:DR The axis sets the direction of positive thrust, not necessarily the physical orientation of the motor. Geometry is set in the drones coordinate system.
