I am in the process of tuning a ~180kg thrust drone that has an asymmetric octa-v frame and 30" props with a frame layout that looks like this (each “m” is a coaxial pair):
With max payload, the drone is around 125kg.
I selected the “Octo Quad V” frame in Ardupilot config (via QGroundControl), but there are not direct inputs for the geometry parameters regarding motor location. This is potentially concerning given the oblong shape of the frame. I have followed this process in the documentation to set up safe parameters, which are mostly a function of the prop size (not the frame geometry). Before my first flights, are there any other controller parameters you’d recommend I change to initial test values?
One other issue I’m having is after testing the motors without props, I frequently get overcurrent shutdowns (>350A detected) in my Hobbywing 200A ESCs if PWM exceeds about 1600. I have set the MOT_PWM_MAX to 1550 and do not see any shutdowns, with nominal/moderate motor heat-up after several minutes of testing full to no throttle (i.e. up to 1600 PWM, not 2000). ESC isn’t warm at all, indicating this may be a relatively transient spike (although according to the manual the ESC does a rapid shutdown, activate, and then permanent shutdown if it sees the current twice which is happening here). Therefore, I do not suspect any short circuits or similar issues since it runs fine at lower duty cycles. I’m using a fully charged 12S pack (~51V) and a T-Motor V10L KV170 motor for each circuit. According to the limited manufacturer data, 200A is reached at full load (30" props) at 100% duty cycle. Why would I be hitting 350A transients with no props closer to 60% cycle? Issue with too high RPMs of the unloaded motors causing a back EMF issue? Rapid inertia M*A acceleration of the rotor causing a load (seems unlikely)? Thanks!
Thanks so much for the tag. This big drones are hard to tune. My initial thought would be you need 88 Volts with less KV. I’m not sure what your target RPM was for your prop thrust chart, but mine was @4500. I could not achieve this on 44 v with 130kv. I switched to 88v power with 50kv motor and Wow what a difference! I’m not a good electrician but this is my only guess so far. Let me know your thoughts and what is your target RPM and prop pitch?
With some assumptions on coaxial motor thrust losses, I anticipate hover will take around 75% thrust, operating at 4600 RPM and ~100A. The data sheets on the T-Motor V10L is limited, but they give a table for two recommended paired props, and I chose the second (G30x10.5). Extrapolating from the motor KV rating, max PWM duty cycle from the logs, with no load I was getting intermittent 350A ESC overcurrent shutdowns at around 6k RPM.
I would use the Octa-Quad X frame type.
Review this in regards to your wiring, you probably have very long wiring runs so all this will be relevant. I would say this is related to the ESC shutdowns. Add capacitors at the ESCs too.
Use the MissionPlanner Initial Parameters calculator to check everything is set OK.
Set and test the transmitter (throttle) and battery failsafes, plus set FENCE_ENABLE,1
Thanks Shawn! Due to the inductance concern I kept the ESC to battery leads relatively short (20cm), and the 3 phase run from ESC to motors is longer (up to 0.8m). The 3phase wires are close and twisted, but I’ll try twisting the battery to ESC wires as well to reduce inductance. Given the short run though, I’m not sure if that’s the issue.
Thanks for the additional parameter recs-- will use and then do initial hover tests in Stabilize. Why do you recommend the Octa-Quad X? Isn’t the V a closer approximation?
The 3 phase motor wires probably dont need twisting, this may even cause an issue (unsure).
Even at 20cm it’s worth twisting those ESC power wires.
Actually with the V vs X config I could be thinking of the H config.
If you do change anything use MissionPlanner motor test to verify the order and spin before attempting a test flight. The motor spin directions are opposite for V and X configs.
Maybe best to leave it how you have and at least test.
If you can post a .bin log of a test - it would be interesting to see.
I started to do the initial hover flights, starting to lift off the ground but still a point of contact ground to landing gear. Being cautious to protect the drone. If there is any roll or pitch starting condition, it looks like the drone overcompensates during initial liftoff. Here is an example log:
In this case, the roll starts to quickly raise as it starts to take off. To be safe, I cut the throttle off all three times as it looked like it was starting to roll over.
Here is the log file for a few runs, showing similar behavior in both roll and pitch. In another flight I was able to keep the drone relatively level by inputing up to 30 deg pitch input on the RC sticks, which seems excessive and I didn’t want to continue lifting off with that.
Will update the config parameters as suggested and do another test run.
@dkemxr yes it’s relatively low thrust to weight. That is with full payload, and understand maneuverability will be limited but I think still flyable. Could reduce max payload rating to create hover around 65% throttle (half of estimated thrust).
Just trying to get a stable takeoff without additional payload now though as step 1. Note in log file I still have the max PWM capped below max.
You definitely need to set up battery voltage monitoring (at least) before you do any more. Otherwise all these important parameters have no effect (or are unavailable)
BATT_FS_CRT_ACT
BATT_FS_LOW_ACT
MOT_BAT_VOLT_MAX
MOT_BAT_VOLT_MIN
Attempting to flip during takeoff is always motor order. This often means spin direction could be wrong too.
Set this before more tests
INS_LOG_BAT_MASK,7
and I’m always a bit shy about going so low with INS_ACCEL_FILTER,10 until you’ve got evidence you need to change it from the default of 20.
I would also level the frame across the top of the motors with a spirit level, pack under the landing gear to get it right, then press Calibrate Level in MissionPlanner/Mandatory/Accel…
Thanks will try these now. Re battery monitoring I’m not sure I can make that work, as the Pixhawk Cube is running off a different battery pack than the ESCs. Each motor has a different pack. The battery monitoring operates off the Pixhawk power module voltage sense, I believe. How important is that, and would there be another way to sense 8 different packs?
When I use roll and pitch control stick inputs it does lean in the correct direction (while still grounded). From the log file it looks like the controller continues to push the correct motors with higher own values in order to tilt the drone. For example, at 16:33:20 I start to give throttle and the drone starts to pitch forward on the ground. As I continue to add throttle the pitch overshoots 0 and exponentially increases until I come off the throttle. Motors 3,4,7,8 are all higher PWM as one might expect if the controller was trying to pitch forward.
Am I just being too conservative stopping throttle before it lifts off? Maybe the pitch is a minor overshoot while the landing gear is still in contact with the ground?
By setting the drone on level ground (x_accel and y_accel < 0.01G), it had a straight liftoff. It started to drift to the right after liftoff, but had generally stable attitude. Was testing on my front yard so lowered it as it started to drift, but will go to a large open field to do further testing. Here is the log file which shows two test runs. First one attained liftoff, the second one was not on level ground during takeoff and started to both pitch and roll so I cut the throttle.
@xfacta I’m using QGroundControl vs. MissionPlanner due to Mac. Is the level horizon function the same as Calibrate Level? When I inspected the IMU outputs in MavLinkInspector, the raw and filtered IMU outputs still seem to be non-zero (no change).
Anything you see in the log files or calibration that could reduce these concerning pitch/roll events if it starts on even slightly un-level ground?
Thanks so much for everyone’s input. I will be able to test in a large open field with less hesitation tomorrow.
Yes, Level Horizon in QGC .
Search these forums for my initial parameters spreadsheet - it was converted into the appropriate section in MissionPlanner.
Use that spreadsheet to check you parameters.
Yes it has GPS (a Here3 unit). Will use your initial params sheet-- that’s super helpful. Is this the latest version? It looks like most parameters follow the Ardupilot tuning guide which I used for initial calibration (plus the changes you recommended in this thread). Since I don’t have voltage sense on the motor battery packs, am I correct to not enable the battery voltage adaptive parameters?
Is there any way to see the effect of level horizon? When I inspect the IMU values they don’t appear to change. Thanks.
I would reconsider the battery wiring.
Having a battery for the flight controller is no redundancy and it’s weight and complexity overheads.
Ideally all motors would operate from one battery pack and you can report voltage and current. The flight controller would also be powered by this single battery pack.
I could see how you might work OK with the batteries split into 2 battery packs, one for front motors, one for back motors or something similar. Then you could use BATT and BATT2 voltage monitors. I would still run the FC off one of those packs, or combine them via diodes for FC power.
It becomes impossible to monitor the battery voltages yourself during flight and you miss out on the critical safety and important tuning parameters that the flight controller can do itself.
All this talk of batteries is not so focused for small aircraft, most of which are lucky to be able to fly out of sight and some wouldnt even hurt people. Yours has props that will just about cut through steel, not to mention the expense.
There is significant oscillations in that log but not enough flight time to tell much more yet.
You will have to work through the manual first-flight tuning instructions to try and get some stable flight.
GPS unit doesnt appear to be detected
Change ARMING_CHECK,1
