One of the connectors of the uBlox GPS module touches or rather presses against the I2C connector cable on top of the Pixhawk.
The result is that this connector squeezes the cables and damages them over time due to the vibration of the frame transmitted over the hull to the uBlox.
Have a look at this report and pictures from someone who had this damage.
After a closer inspection I found out the following:
The Pixhawk on the consumer version is position further to the front than on the developer version, thus moving it underneath the uBlox module. Have a look at this picture from the Developer Edition to compare.
There is still space between the GPS antenna of the uBlox module and the IRIS hull. One could shorten the mounting thread in the hull and bring the uBlox module closer to the hull this way.
My workaround was to place a Post-It sized piece of fabric between the uBlox and the Pixhawk.
Has anyone else seen the uBlox module rubbing against their I2C connector?
@3DR: Why did the position of the Pixhawk change from Developer version to Consumer version?
What is your recommended fix for this?
I noticed the same problem when I first took the top off. The GPS had squashed and damaged the cable on the pixhawk and there was a wear mark on the GPS module. I put electrical tape over the cable and put a very thin piece of foam over the GPS module.
I noticed something similar just today. I was having some trouble getting my Tarot gimbal working properly and so I removed the upper shell to check the connections to the pixhawk. (Turned out the Tarot needed a sensor calibration-it works fine now.) I first noticed that the insulation on the wires exiting the power plug was slightly flattened. You can see this same issue in the previously posted link, just at the left edge of the picture. One of my wires exiting the I2C plug is similarly flattened, but that is as far as it has progressed to date. It appears (from the smearing) that the ublox chipset is in contact with the power plug on the pixhawk, and the MAG port is in contact with the I2C plug. It seems to me that maybe the vibration transmission caused by this contact could be what’s causing some of the twitchy behavior that people have been seeing. (Personally, the only twitchy behavior that I’ve seen has been when flying in gusty conditions, but I just attributed that to wind on the barometer since it disappeared when switching to stabilize mode.) I also noticed that when re-attaching the upper shell, I can see (through the vent slots) the pixhawk shifting significantly when I press the shell into position.
From looking at the development version pics, it looks to me like the pixhawk was shifted forward in order to make space for the telemetry radio which is mounted pretty close to the rear of the pixhawk.
I’ve already passed on this info, along with pics and video of the shifting pixhawk, to 3DR and they tell me that I should hear back from them tomorrow. I have a few ideas on how to fix it, but I’ll wait to hear from them and then post back after I do.
That is very interesting. I didn’t notice that yet. But it would explain a lot.
I’m seeing random issues with AltHold or rather the Barometer in particular. They appear to be caused by vibrations. If the top shell cover is pressing down the Pixhawk that badly, vibrations from the top shell will definitely be transferred to the Pixhawk.
Yes, it would be great if 3DR could address this issue here.
In the meantime I’ll look into moving the Pixhawk further to the back. Let’s see if there is space for that.
Moving the Pixhawk to the back is a no-go. It will come in contact with the Telemetry module and therefore it can’t go far enough to get out of reach from the uBlox.
But that means that the Telemetry module also has to be moved. Lot of hazels for a ready to fly product.
With that we are reaching a point where 3DR has to come up with a fix fast. Otherwise at least I will exercise my right of returning a faulty product for a full refund.
