This is an autotuned X8, with some manual twaeking, it hovers at 20% throttle.
It is sluggish to yaw, not any less due to being an X8.
I can yaw at a decent rate at speed (with higher power demand) , but bigger yaw input at hover produces wobble, as motors are commanded to minimum thrust.
Feel free to suggest PID modifications, I think my roll and pitch also looks kind of hard, but flies well… except of yaw…
It appears your MOT_SPIN_MIN is set too close to hover power. I would lower it quite a bit and make another log. When that param is set too close to hover power, the copter has too little headroom for maneuvering.
Is it possible to view your params with the BIN file?
Agreed on the minimum throttle headroom. MOT_SPIN_MIN is set to 15%, and you’re hovering at 10-15% with a full battery, which leaves almost no room on the bottom end. In fact, your motors bottom out even during level flight.
You can lower MOT_SPIN_MIN, but it must be greater than MOT_SPIN_ARM, which you have set to 10%. Whether you can lower ARM any more depends on your motors and ESC’s and how thery’re configured; some can go as low as 5% and still start up reliably. For example, I fly with MOT_SPIN_ARM at 0.07 and MOT_SPIN_MIN at 0.1.
@Iketh the parameters are contained in the .bin. You can have Mission Planner convert the .bin to a .log, and then open it with a text editor. The params are listed near the top of the log file. You can also view them in MP’s log grapher by selecting the top row of the table and filtering for PARM messages. The parameters will be listed in the table.
Re your comment over on this issue.. I think the altitude is probably not being reset on arming because the EKF origin (and AHRS home) haven’t been initialised yet. I think you’ll find that if you take-off in Loiter mode the altitude will always be reset. If you take-off in AltHold or Stabilize it may or may not be reset.
The difference in behaviour doesn’t actually have much to do with the mode used, it’s just the Loiter is not usable until the origin/home have been initialised.
Good catch guys ! (Thanks)
Those started well at 7% (when I tested for direction/sequence) , so I’ll lower it to 0.8 and 0.85
@Iketh , if you innstall mavproxy/mavlink you can also read parameters like:
mavlogdump.py Yaw.BIN |grep MOT_ (in this case, it will display all MOT_)
@rmackay9 - I’ll try out Loiter vs Poshold, Althold, Stabilize, is that intentional behaviour ? - why would we like to only reset relative altitude in that one mode ?
As I see it, flying an mission at relative altitude should always produce about the same result, regardless of takeoff mode.
re not resetting the altitude display if you take-off before getting a GPS lock (or more accurately before the EKF has decided it has a good position estimate) is not a bug… we could reset it but it would add some additional complexity to the code in an already tricky area. It’s tricky enough that I’d rather not fix it unless it’s really causing problems…
If you’re doing missions, you really shouldn’t take off without a good GPS Lock/EKF position because RTL won’t come home to the correct location!
@Iketh you both got it right, but the system apparently accepts only one @rmackay9 You misunderstood something, I could try to rephrase things better, but none of the home-altitude-resetting issue as about not having a solid GPS fix… my relative altitude is simply not reset , mostly reproducible in one particular UAV.
Another bunch of tests I did today: https://drive.google.com/file/d/1J7WHYL9JnuSngy1ufUEjFdV2peG-pCrS/view?usp=sharing
This is another UAV, deliberately sub-average GPS fix, never liftoff, arming in Stabilize/AltHold/Poshold/Loiter/Acro - my relative altitude in GCS goes to 0m on every arming. (never leaving the spot) … then drifts off with temperatire (it’s cold outside, and the UAV have just been brought outside for this test.)
The log above is a huge contrast to the one I posted on github, with long uptime outside and Cube 2.1, it may be stuck at several meters off, and many armings/or “calibrate sensors” does not fix it, so indicated AGL is still high…
This is good reading for me, thanks for raising it - both the motor issues and the home position issue.
Regarding the home position fix, I haven’t had the issues described as far as I know, but that’s probably because of our basic procedure as described below.
After a near-flyaway early on in my (limited) experience, we now wait plenty of time between power-up, GPS fix and arming. Then we do a small test fly around a few metres high and maybe 10 meters radius in Stabilise mode before trying Loiter (ready to change to stabilise), landing and disarming with the intent of positively setting home position. The test flight can last a couple of minutes.
Only then do we re-arm and select Auto to fly a mission, or extensively use Loiter for take off and general flying.
I notice on different days and weather conditions it takes a different amount of time to gain a good GPS fix, so if the craft has recently been used, like minutes ago, we pretty much know whether to just arm and take off in Loiter mode, or do a proper test flight in Stabilise. You never know when you’ll have to RTL because of failsafe or just because…
Perhaps I’ve misunderstood but I don’t think so. When you say “relative altitude” you’re referring to the altitude above [ahrs] home. Setting the ahrs home’s position on the earth requires a GPS or the user to specify the location through the ground station.
It sounds like you’ve confirmed that the altitude reset happens when arming in a mode that requires GPS (Loiter, PosHold, etc)… that’s good from my point of view because it confirms the issue is what I mentioned above.
@rmackay9 - Yes , altitude seems to reset in all modes on arming. - except… for the vehicle in the github issue, that’s why I created that issue… because I could not figure out how it could randomly more often fail, than succeed to reset it.
Which only deepens the mystery to me.
