Hi all,
I recently switched to an external GPS/compass (3DR) and resolved some EKS variance issues I was having. Woohoo. So, I went out today to test a few things (Loiter being one of them). When switching into Loiter the quad would start to drift and the RC yaw, pitch, and roll (possible throttle) inputs were unresponsive by the craft. That is to say, the quad did not respond to my inputs -- at all. I tried a few times, but to no avail. I have attached the df log below. Taking a look at RCin ch2-4 and RCout ch2-4 shows weird results where the quad was in loiter.
Example: RCin ch2-4 drops to the min PWM value when any stick movement is applied to the RC in loiter mode. See screenshot.
Also, the DVelX vs. VelX (and DVelY vs. VelY) show weird things. See below. Image one is from a normal Loiter's log. Image two is from the attached log. What's also weird is that the DVelX (and Y) and VelX (and Y) do not encompass the entire flight log... Huh?!
(Normal)
(Abnormal)
Also, for shits and gigs I tried a short auto mission, but the error "No takeoff command given". Of course I had already taken off and was in the air. Note that I have flown this exact same auto mission in the past -- it's just fly to a few waypoints. I'm quite confident they are related.
Anywho, any thoughts on this?
Navio2 hat on an RPI3. Compiled 3.4-rc1.
Austin M
Replies
Hi Austin,
Do you have earlier logs that might show how hover throttle got this high?
EDIT: You'll have to accept my "friend" request.
I will message them to you as it's from my residence...
FYI for everyone else -- I was screwing around in my room with props off. Quad was armed with throttle applied, and I was moving around. *I wanted to see if I set the waypoint radius such that I could "walk" the quad to it to make sure my camera triggered...
:/
I should probably set my params back to default and bring in what I know I need from a recent log...
AM
Yep, we have fixed this problem now. Thanks!!!
Cool,
I thought that this might be what happened.
Thanks!!
Ah, I forgot to add, I think what's happening when MOT_THST_HOVER gets too big is that we use that value to determine a reasonable "take off throttle". So Copter-3.4 won't think that it's taken off until the throttle is at least 1/2 the hover throttle. When hover throttle is 1.98, you basically need to put the vehicle to 100% throttle before it'll think that it's taken off.
By the way, you can actually disable learning of the hover throttle by setting MOT_HOVER_LEARN to 0.
Ahh, I see.
So, If I disable MOT_HOVER_LEARN and set MOT_THST_HOVER to my hover percent we should be good to go? This definitely seems like it would solve the Auto-mode issue I described, but will it also solve the unresponsive loiter mentioned? Does the same premise apply?
Thanks for a prompt response, by the way!
I'll post this over in the discourse server forum as well.
Austin M
Yes, turning off learning (until -rc2 comes out at least) would be a fine thing to do.
I've created an issue here in case you want to follow progress on this.
Thanks!
Thanks for the report and testing Cotper-3.4-rc1. Also interesting that you're using one of the linux boards which really are the future.
So, you've definitely stumbled upon a bug which we will sort out for -rc2. The issue is that somehow the MOT_THST_HOVER parameter has gotten to 1.98. It's valid range is 0 ~ 1 so we've got to add a reasonable constraint into our automatic hover throttle updating code. To get you going while we fix that, can you reset MOT_THST_HOVER to 0.5?
Txs again.
By the way, we're planning to do most support in the new ardupilot discourse server area. I must admit that I've been having trouble balancing my time so that I can devote sufficient time to supporting the beta release but I expect that will improve soon.
Have you done a RC calibration?
-
1
-
2
of 2 Next