The battery has to be right forward to get correct CG. The GPS already has some 3M shielding tape underneath it. I might try putting some shielding tape on the VTX in case that’s it, but I am largely assuming its the battery wires.
I find it hard to believe that the GPS serial cable needs shielding - why would that be?
Besides USB cables, video cables also usually have small gauge shielded twisted pairs in the bundle of wires.
i can only guess that some harmonics from the interference on the serial cables gets into the gps antenna circuit or amplifier and messes it up. it was hard to believe but, the difference can be seen clearly when you see how it would struggle to lock into 6-7 sats in the duration of 2-3 minutes and then suddenly in 20sec it gets locked into 12-13 when properly shielded. try to experiment with it and you will see for yourself.
i spent ton of time before trying to shield the gps puck itself, put a backplate under it, put it into a box, etc - nothing would help, and then tried to shield all the wires that go to it and that made quite a difference.
Hi Paul Atkin,
Thank you very much for your great collaboration,
I did exactly what was recommended by you in this forum (I used an antistatic plastic bag) and that solved all the GPS errors, it is the first time in so long that the mistakes have disappeared in the results of the auto analysis.
Re the vehicle not switching into RTL, the EKF is not happy with the position estimate. this can be caused by a few possible things but the most likely reasons are:
- bad GPS position. The number of satellites is falling to 9 or 10 at a few places in the logs so this is quite possibly the cause. Perhaps replacing the GPS would help.
- high vibrations. The vibes are a bit high at 25m/s/s in the X axis. This is at the top of the good zone. I.e. from 30 to 60m/s/s is the “grey zone” where altitude hold can go bad but might be OK.
- bad compass.
- simply flying too aggressively can throw off the EKF especially very fast continuous rotations (i.e. 90deg/sec yaw change is about the limit at least if it’s sustained for a long time - faster turns but short duration are OK).
I think if you tried flying in Loiter (and the vehicle stayed in Loiter without an EKF failsafe triggering) then the RTL would trigger correctly as part of a failsafe.
RE the baro interference. I think it’s really mostly a physical effect so the best solution is a change to the frame. Perhaps adding an external barometer up high (like in the GPS unit) would help. I’ve never personally used an external barometer but it should be possible and it’s documented on the wiki.
@rmackay9 - thanks. I think many of these are not solvable on such a small frame. Is there any way to determine which it is? Can I get some logging? Also why isn’t the switch to LAND notified on mavlink? I’d like to dig into this a bit more if I can. Also is there any way for doing anything other than land? What I’d really like is to switch to Alt-Hold and then when the EKF is happy again RTL.
Andy,
There may be multiple problems. So just looking for the potential vibration issue have a peek at these graphs. The first one is the vibration levels. Normally we say that below 30m/s/s is OK but in this log the x-axis is close to that limit and the other thing is we’re seeing accelerometer clipping (not shown but it’s visible by looking at VIBE.Clip0,Clip1, Clip2). So this means there is a vibration issue.
We can see the impact of this on the EKF’s altitude estimate which is deviating by more than 40m. So what’s actually happening is not that the vehicle is going into LAND mode but that the alttitude estimate is going very negative so when you later switch the vehicle into SmartRTL, it is attempting to decend to the altitude that it recorded earlier.
At this point I think it would be good to change the failsafe behaviour to be regular RTL and also look into trying to reduce the vibrations affecting the flight controller.
Thanks @rmackay9 - pretty sure this was regular RTL. Why would x-vibes affect the altitude estimate so much? Wouldn’t it be z-vibes in the main?
Ah, yes, you’re right. It’s an RTL initiated by the Pilot (line 17649 is MODE, RTL, reason = 1). In any case, I’m pretty sure this very large altitude error is the cause of the descent you’re seeing.
The altitude estimate comes from a mix of x,y and z if the vehicle is leaned over.
I really think the next step is to try and get the vibrations lower…
@rmackay9 - 
I’ve tried multiple times - the pixracer is mounted on matek rubber standoffs and I’ve pulled all the cables out of the way. I’m using the high sample rate - not sure what else I can do. Would it be worth trying to tune the EKF to favour the baro more?
I suspect the Matek rubber standoffs are too hard. We have a slightly dated wiki page with advice on vibration dampening but my personal favourite is the 3M foam from mRobotics. The 3M foam is expensive but I’ve had good luck with it.
We have some advice here regarding the EKF and in particular the EKF_ALT_M_NSE parameter might help. The number of Accelerometer clip events in this log is a very bad sign though. that means more than 24G of vibration. I really think a physical problem like this calls for a physical solution.
Randy, one poster on the RCGroups wrote down this explanation - i think it may have some ground behind it.
It may be worth to review…
{
My experience has been that when it reports GPS-Glitch, usually GPS is absolutely fine, and it is really the IMU that’s having problems. It reports the GPS-Glitch if the position reported by the GPS and that predicted by the EKF differ by too much. I have not experienced throttle-ups in this situation. I can probably dig through some logs to verify this, but I’m guessing that it is going to the hover-throttle setting during a GPS-glitch. For my 7" racer hover throttle is set at about 20%, so it settles nicely, but drifts with the wind until the glitch clears. Perhaps someone that has dug into the code can confirm this (or not). If mine went to full throttle for any length of time, that would be a real problem. Climb rate would be something like 20 m/s.
}
that discussion was related to the behavior in alt hold where due to excessive vibrations models lose their mind and give max current to all motors propelling it into the sky ignoring the throttle stick input.
my experience with gps glitch was dual - i can say in some cases i indeed had a situation with gps glitch errors and 15-17 satellites locked in, and it did not make much sense at all. but, i did not have that reteated in a very long time now, on dev master, at least. my gps glitches would only occur in a similar situation to log posted above - when gps is half-way locked, say, having 7 or 8 sats and when during movement that count drops to 5-6 - but that is a legit gps position glitch, most likely.
well, it is a story about pixracer again - i suspect it is just a bad design in the imu of pixracer and it is really not capable to deal with vibrations well. i gave up on it completely - and that was the reason i started using kakute f7. when kakute is mounted on matek standoffs, with a combination of its IMU sitting on the foam base - i think there is nothing on the market today that handles bad vibrations better.
here is a thread where folks share their opinions - may be you can ask there as well, passage i copied above was from that thread as well.
https://www.rcgroups.com/forums/showthread.php?2576614-Pixracer-Autopilot-the-new-PIXHAWK-generation-is-available/page204
@rmackay9 this is the first time I’ve seen this guideline mentioned. Is this documented in more detail somewhere, or is it just what you said, don’t yaw over 90 deg/sec for long periods? In normal flight maneuvers is there any risk of a fast turn causing EKF problems?
I wish that Kakute had a can port.
I have experienced bizarre vibration issues with the pixracer that I have never figured out. Perhaps this is the reason.
i bet you can do it - but it would require to setup a virtual machine with ubuntu, put there a git repository from the arducopter master and make your own code build with your own hwdef file definition.
f7 chip is extremely flexible. the setup in the hwdef now maximizes uarts - serial ports. i do not use CAN so it was not important to me. but it is possible to make one with it.
or not. not sure. i tried to look briefly and pins that could be used for can are now on SPI and on OTG1, but, may be there are some combinations in there that could work. not sure.
what hardware is used on the CAN bus? is it really needed?
I have a Zubax GNSS GPS and compass.
That said I can use a standard GPS as well. How well does this Kakute work. Is it easy to setup.
I don’t own anything CAN so I can’t test, but on Pixhawk 4, CAN2 sits on Serial5 with its transceiver in “silent mode”. On the Kakute we have the OSD chip on Serial5, so some nifty hot-air work extracting the OSD and hacking in a CAN transceiver may deliver Zubax connectivity. Or not. 
The transciever chip costs $1 (TJA1051TK3/118)
@Paul_Atkin1 I found the current pin on the non-AIO board. It’s the undocumented 5th pin in the 8-pin ESC plug \o/
You would need to use latest dev code build for it. Easy? Mostly yes, i think, but some issues r possible as with any not yet stable build. I personally like it and i think it works well.