Typhoon H IMU related problems

[h-elsner]

During my investigations regarding "Stuck in Aquiring state" the IMU on the Flight controller board got attention as source of different problems.
Details can be found here: http://h-elsner.mooo.com/pdf/GPS_acquiring_problem.pdf

It looks like MPU6050 chip as heart of the IMU has an aging problem when the drone was stored somewhere and not used for some time. That's why my recommendation is to power on the drone from time to time and do a accelerometer calibration. Of course it is best to fly it.

In case the IMU has a problem, usually, only the exchange of the flight controller (MCU-board) will help. But since this is quite expensive, we could try to replace only the IMU (make-one-out-of-two-method).
I added a guide how to replace the IMU on the flight controller of the Typhoon H to the HowTo collection on my homepage.
Here it is: http://h-elsner.mooo.com/pdf/HowTo_Replace_IMU.pdf

The most important part is to find the right place to lever the old IMU to avoid damaging conductive paths on the PCB.


br HE

 

[shoebferoze]

I wish I had come across your posting before I started investigating this issue, would have saved me a lot of time; but it was fun so cant complain. A little bit of backstory, I bought a TH from fellow forum member PEVO a few days ago. On arrival, I tested it and it would not fly. This is my first typhoon H and I did not have any knowledge on common issues. I got together with PEVO who walked me through what could possibly be wrong and zeroing in on the FC I decided to get it fixed at a qualified tech and got that sorted out. Unfortunately the GPS module was also weak on this, the received signals were about ~25 db even with clear views of the sky. So thats another thing that got replaced.

My curiosity on the issue grew and the retired engineer in me wanted out over the long weekend. I went hunting on craigslist, bought a Parted out Typhoon for ~50$ and got to experimenting. As rightly pointed out by you, the sensor IC is contained within the brass enclosure and filled with resin is the culprit. The STM32 microcontroller uses a lookup table to correlate GPS positioning data with sensor readings to validate everything. When it does not pass the check, it just assumes the GPS readings are at fault and gets stuck in acquiring. From a safety standpoint, the job is done as the TH is locked out of flying. However, given the contradictory nature of readings, it does stop you from flying out with GPS disabled. I think the engineers at yuneec implemented this considering this situation, only that they did not want to write additional status messages to let us know that it could be either GPS or the positioning sensors that could be bad. Without a third input - a redundant GPS or IMU, it would be impossible for the TH to perform self diagnostics.

I remembered something I used to do to fix robotic arms that were subject to similar malfunctions- bake the PCB. This would reflow the solder taking care of any oxidation that caused issues and the would get the machine running again. I decided to be a bit brash here instead and brought out my blow torch heating the enclosure to a 120°C. Once it cooled down a bit, I Installed it and the error went away or atleast temporarily coz it came back after a bit. I think baking it at 180°C for 15 minutes should get rid of it for good. Also, once hot, the resin just peels off, so you could take it off and install a new IC in there. To do this however, you would need a SMD solder station. A heat gun might work, but YMMV.

Now im off to restore this craigslist TH480 and maybe install the PX4 firmware. Fun weekend ahead

 

[fantacmet]

I Realize this is an older thread, but where would one get replacement IMU IC's? I doubt Yuneec is gonna let them go. I doubt they're proprietary, but given everything is filled with epoxy it's likely they want to keep the origin of the chips silent. It's common practice among companies to push you into buying the newer products rather than repairing the old.

 

[h-elsner]

The idea is to get proper working IMUs from bricked MCU boards to working MCU boards with defect IMUs.

 

[fantacmet]

Bricked boards like mine?

 

[fantacmet]

Dude is sending me a board with bad imu. Gonna try the swap. It would be nice if we could get ahold of new IMU chips though instead of $# for a gamble.

 

[h-elsner]

The chip itself is a cheap MPU6050 which is available as sensor in the Arduino world. It is completed with a heater and sealed in the brass housing. I don't believe that this is available as single spare part anywhere. The problem is the tiny connector. I tried to find a place to contact the wires to the IMU just for measurement cases.
After a lot tries I ended up with a complete destroyed MCU-board but I have now an adapter to test the IMUs at a Raspberry Pi. Nothing for productive usage nor for flying with that construct.

I think the only way is to cannibalize defect MCUs.

 

[fantacmet]

Hrm. On the FC boards thst are coming are dead IMU's to play with. I may have access to equipment in an electronics/avionics lab that most don't. I'll see what I can figure out.

 

[fantacmet]

Were you by chance trying to calibrate them with the raspberry pi? I have a few Raspberry pi boards that don't get used all the time. I wouldn't have an issue with grabbing another micro SD for standard red raspberry pi and mucking about(one of them pi3 is a retro pi gaming setup, the other two are pi4 2gig, there I run 2 3D printers with, and those 3D printers are in storage and I'm only running a single resin printer right now due to space.

 

[h-elsner]

Were you by chance trying to calibrate them with the raspberry pi?

This was my first idea and the reason why I waned to connect them to Raspberry Pi. I wrote an application to access to it. But at the end I understand that calibration means to update correction values in the flight controller (or gimbal) firmware instead of store values in the MPU6050 which is not forseen at all.

Summary: I have learned a lot but external calibration is not possible.

My MPU6050 test tool is here: GitHub - h-elsner/MPU6050-test-tool: MPU6050 test GUI for raspberry Pi

 

[fantacmet]

This was my first idea and the reason why I waned to connect them to Raspberry Pi. I wrote an application to access to it. But at the end I understand that calibration means to update correction values in the flight controller (or gimbal) firmware instead of store values in the MPU6050 which is not forseen at all.

Summary: I have learned a lot but external calibration is not possible.

My MPU6050 test tool is here: GitHub - h-elsner/MPU6050-test-tool: MPU6050 test GUI for raspberry Pi

Calibration can also be stabilizing drifting values.

Check out this video...

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

I realize he is doing this to chips thay aren't embedded but food for thought.

 

[h-elsner]

This is the same procedure as PX4 autopilot is doing to find the correction values that are used by flight controller.


Also in this two videos he only calculates the offset values to use it in the application that the MPU6050 uses for what ever usage. He don't write something to the chip.
The problem is, Typhoon H has no proper calibration for accelerometer (oly one position, not six).
At least, I think it is gyro calibration, not acc. So, if acc z-axis is out of range then the pre-flight check fails and the drone remains in "Acquiring" state.

In customized H480 FW on PX4 base I can use the "defect" IMUs without problems. PX4 does the full spectrum of calibration.