@rmackay9 thanks - I always wait for prearm ready in poshold which I guess doesn’t show on this graph. So although I took off in stab, I had waited to get good GPS lock etc. I’ve tried to zoom in on the first log (53) below to show the problem (very hard in mission planner when there are spikes in the data). What I observed was radio failsafe -> SafeRTL/RTL but no attempt made to RTL it just descends. I’ve graphed the EKF inconsistencies for this time period and none go over 1. GPS is ok, MAG just about ok despite a spike when the throttle bursts when the failsafe hits. So I would expect a proper RTL, but you can see from the baro that it just goes down. Also if it’s landing shouldn’t the mode say “LAND”? And if the EKF doesn’t have a good position estimate wouldn’t there be an EKF error?
Morning Randy. Hope all is well.
Wanted to share an observation I made this morning. First it’s raining still…grrr.
Second I decided I was going to flash the GNSS with new firmware so I went to the shop and pulled the connector on it to connect up the can port to USB device i just got…I ordered because I had a feeling I needed it.
Much to my surprise I found the Can port terminator on the second port was missing. Well the resistor was anyway. I don’t know if this is the reason for the sick GPS or not but the canbus was not terminated. I made up a new one, but this time I soldered the resistor to the connector contacts so they won’t fall out again. Of course the whole terminator plug could but thats unlikely. Anyway if it ever stops raining I will try again.
Grrr…this hobby has it’s challenges.
I uploaded a few more logs…
One very large one. But I still have an HDOP of 100 even with the can port terminator repaired.
sick GPS I guess
https://drive.google.com/open?id=1ICbzNjJDgmEjWEYS4H0FFMRg1s_G1Xcj
Some logs of mro pixracer on a tarot 650, number six is an autotune.
I have many vibes and don’t know where they came, on autotune disapear for exemple, it’s shocking watch the vibes get off on autotune process.
Pixracer led, stays blue without gps fix, goes blue turquoise on gps fix, and deep blue on arm.
Btw, I am dreaming every night with the message “hardware safety switch” XD
Good morning Peter.
Could you, please, email a direct linkto the 777b4c8cfe09ae05795385a1f027b8d57184d959 file?
Thank you.
(Couldn’t find it by searching GitHub)
Henri
hi, if you will figure out how to make SmartRTL work - pls let me know as well, it never worked for me neither.
We have fixes for the pixracer LED coming in 3.6.1 which will enter beta testing within the next couple of days.
The vibration levels are a bit high especially in the x and y axis (i.e. forward-back, left-right) which is a bit unusual. Normaly it’s the Z-axis (up-down) that is the problem. It’s hard to say what the cause is but it’s most likely something physical. Perhaps a wire or bolt hitting the flight controller at certain times.
Paul,
If you’ve got a dataflash log of a failed SmartRTL can you post it? I use it fairly regularly and haven’t found problems so I think we can get to the bottom of it.
Yes, you’re right that if it’s Landing then a MODE, LAND messages should appear in the logs. I think what’s happening is that the EKF’s altitude estimate is diverging far from reality perhaps due to ground effect on the barometer or high vibration levels. Then this incorrect altitude is being stored in the SmartRTL buffer so when you later switch to SmartRTL, it’s trying to move to the stored (but incorret) altitude.
Above you can see the EKF altitude (in red) is diverging from the barometer and GPS altitudes by 10 meters. They come back together at the end of the flight.
Could you try turning on ground effect compensation by setting GND_EFFECT_COMP = 1?
Vibration levels are a little high but they’re still in the OK zone (below 30m/s/s) so i don’t think it’s a vibration problem.
I will try. When i placed it on a rc channel to invoke manually, it worked. Then i placed it on a failsafe and it ended with my model stuck in a tree. I did not bother to use it after that. I can try again.
@rmackay9 - thanks I will try that. I can easily believe that my problems are related to altitude as that is consistent with both the weirdness I see with the OSD and in general the copter doing strange things on the ground as though it were flying. The barometer is covered with foam and taped up, but I guess one question - in the graph above the baro and GPS are pretty much in agreement, so why is the EKF so far out of whack? Presumably z-vibes might be the cause, but they don’t look awful. I am out of ideas on reducing the x-vibes - there’s nothing I can see that might be causing this other than prop-wash (they are BN props and the tips swing about 10mm from the edge of the FC).
[Incidentally my radio problems are hardware - the “full-range” lemon rx diversity I’m using seems to be anything but, so I have ordered a proper Spektrum race quad receiver]
I think the issue with the altitude is perhaps barometer related. See the big spike down in the barometer reading soon after takeoff? That could be the issue I think. the gnd-effect-comp parameter might resolve the issue. If not then the issue is probably those X-axis vibrations…
@rmackay9 - ah , yes I see! So perhaps the takeoff blast is causing this (which is much worse in stabilize and much worse on this copter because of 4s, BN etc, etc)
@rmackay9 - I have remounted the FC and put in additional compressed foam around the baro. However, I still see a large transient drop in baro alt when I punch out (e.g. on takeoff). For a small frame I am beginning to conclude that this is inevitable - the prop wash pretty much covers the FC stack because the props are so close and you are inevitably going to get a large transient drop in static pressure each time they rev up significantly. If this is the case then the EKF is never going to be very happy? It seems like it should be possible to model this a little like is done for mag interference - e.g. pressure drop proportional to change in throttle?
Anyone out there running 3.6.0 and a GNSS v2 GPS and have it working. If so any chance you can kindly share your Param file for your working machine. I would like to compare it against my machine to see if I have missed something in the config as I am not able to get the GPS to work yet it’s confirmed now as a functional GPS.
It’s possible we could do more work in the EKF to help it cope with these situations. I know that Paul Riseborough has done some work to allow configuring compensation when the vehicle flattens out after a high speed flight (this is another case where the baro gets unhappy). It’s a bit tricky though and it’s enough work that we probably need a corporate sponsor to fund this kind of EKF improvement or we need to find another EKF capable developer who wants to take this on…
… I guess in short I’m saying that I agree it’s possible… it’s just a bit tricky so it may be some time until we find a dev to do it.
Any possible chance in future Copter-3.6.1 to check on startup for:
- sd card kind before declaring “bad logging”?
- I/O thread heart beat?
Thank you.
Henri
+3 Now I do have 6 flight controllers with the same behaviour.
Hundred of flights without issue ( 3.5.7 ) including logging with no issue.
With Chibios they all fail with “bad logging” and no I/O thread heart beat.
Any possible chance in future Copter-3.6.1 to check on startup for:
- sd card kind before declaring “bad logging”?
- I/O thread heart beat?
Thank you.
Henri
I get bad logging as well,…it’s intermittent