I’m using Methodic configurator to setup two drones. The target one is agro 34i (pihawk6c), but for test platform and to make myself familiar with setup I’m using cinewhoop SpeedyBee Bee35 with matek mini flight controller. I’m pretty sure I do the same steps/tests for both drones except hard ones which require specific stands (like building thrust curve for motors, so I use default set by Mission planned via inital config).
I got an issue with takeoff on Bee35, which is not an issue for agro (why?). During takeoff in AltHold or Loiter. Arming, motors spin, I do a little throttle up from midpoint (50%+), drone takes off, I release throttle to center, drone slows down the motors and trying to land. If surface is clean it continues to spin motors and it is possible to take off again. The only way to keep it in the air now is to work with throttle like in stab mode, but much more actively, I need to keep throttle over 50% (~80%) until drone sets its height and then it keeps it (it takes several seconds). After that I can continue normal flight in LOITER.
Did you calibrate your radio/transmitter?
Also typically the dev team wants to see your file created by Methodic configurator.
Or your param file at a min.
I use also Bee35 and have similar issue with 2 different flight controllers (F405v4, and now F405AIO). Seems it is related to pressure changes during takeoff, but that is just a theory for now. I just need to add more throttle on takeoff, and keep it up for a moment to get stable hoover. Adding short legs helps a little, but does not solve the problem.
When RPMs go UP, pressure drops and FC assumes it overshoot and is reducing RPMs.
But I am not an expert here.
I was considering setting EK3_RNG_USE_HGT to 33% to force it to use lidar (max range 6m) on takeoff to 2m height instead of baro, but not sure if that would be the result that I expect - just assumed this is it from the parameter description. Drained all packs I had for tuning flights.
And at least I can see much less altitude spikes, and it’s a bit easier to takeoff and hover, it still try to reduce RPM, but could be fixed with apropriate throttle compensation:
Without shields (not able to take-off because of spikes):
So the Adam’s idea that working props suck air out of enclosure → lower pressure → higher. So reducing RPM at the “final stage of take-off” adds extra pressure into the enclosure and FC thinks it much over the desired height and decrease RPM even more.
Is it possible to compensate baro sensor for RPM somehow? Or shields and comlplete FC isolations is the only way?
With -275 after several probes it did a take-off after single stick move without any shields but still with a piece of foam over the baro sensor. To maintain altitude during flight it steel needs some input from me (RC3) but it much more reliable! Will do some tests outside later.
If you need some other tests conducted to improve this, don’t hesitate to ask.
Is there a way to see the current altitude target? I think “desired” is the intermediate points to get to the target, or do I have that backwards? Desired changes after the throttle input is over, so I assume that an altitude target was set and Desired is what is used by the controller?
As I understand the logic: throttle >50% starts takeoff, after that drone shold reach PILOT_TKOFF_ALT autmatically and hover.
After that pilot uses throtle to change altitude. I guess these parameters are for altitude controller:
I think Pilot Takeoff (at least in alt hold) is only used if you are in Alt Hold and issue a takeoff command. If you simply throttle up then I think something else happens (I have an open question about actually detecting the “not landed state” here)
Looks like you’re right about the takeoff behavior, but the Z position target is the answer to what althold should be tracking, which should be in PSC logs, which I don’t see in your latest bin. Or else I’m still missing something
Works like a charm 