Just updated to 2.7 on my Y6. However, I still seem to have this random issue where the mag (DIYDrones HMC5883L) fails to init when I hook the battery up. In mission planner I get a slow rotation of heading which does not respond to the heading of the multicopter rotation and the attitude feedback is very sluggish on the hud. If I unhook and reconnect it comes good again (sometimes).
It's a real pain to have the laptop / xbee on hand when I go out for a fly to see if it has failed to init the mag when I turn it on. Board is the APM 1 2560.
In this state the mag is just giving me zero on it's X,Y,Z. The fact that it sometimes works indicates the mag is ok. It's soldered directly onto the four pins of the IMU with a double sided foam tape to space it away for the electronics below it.
I though it may have been interference from the Attopilot 90A sensor however it seems to still randomly fail to init with it disconnected.
Question- should Mission Planner show the correct heading/attitude as soon as I turn on the multicopter and connect to the xbee com port, or is it only supposed to come good after arming? Does a GPS Fix have anything to do with this? What should I expect to see?
I have seen it come good a couple of times after arming but this is also random. Most times I do need to kill the power and connect again for the Y6 to be flyable.
This was the main reason I gave this board a break for a long time and tinkered with a MultiWii controller. Really disappointed that the updated software does not seem to correct this. Starting to think something is a amiss with either the mag or the IMU board.
I'll clear all the onboard log files and run some tests again to record what happens when it starts and post the log files to see if anyone can spot anything out of the ordinary.
I've got a spare HMC5883L I2C board from my MultiWii tinkering. Might hook it up remotely (15cm cable) to get it clear of all the electronics. When the existing one does kick in ok on boot up it still slowly drits around and then drifts the other way as soon as the motors kick in. Totally unreliable. Hopefully the spare board will behave differently. Would the bad I2C data from the mag cause the attitude representation in the MP HUD to move sluggishly? Hopefully the board I have works on the same voltage. I'll have to look closely at the chip on each board to work out the correct orientation.
Have to say I hate trying to de-solder multiple pins on a PCB. The de-soldering braid always leaves a thin film on the pin which makes it hard to pop it off the pin.
De-soldered the mag from the IMU. I then inserted a four pin 90 deg header underneath the IMU to allow me to test the HMC5883L board I had. After hooking it up and going into the CLI terminal I get "ERROR INIT COMPASS". I then connected the original DIYDrones mag and got the same thing. Interestingly enough with the mag disconnected and disabled in the settings the code seems to take a guess as to what the heading is and doesn't do a bad job of it. It's not showing the actual heading but it is corresponding to the correct amount of rotation. My other issue of the attitude initialising at an odd 40deg tilt (displayed in the HUD) regardless of the level command levelling but then not retaining that level after resetting the board is back. I also cannot get the sonar to work. The voltage on the centre pin coming out of the IMU is showing 0.22V. It should be 5V. No wonder I cannot hear the sonar making the quiet ticking it normally makes. Really starting to think the IMU is the component at fault.
Bit peeved about this as the board has been sitting in a static bag for months. When I do decide to give it another go, even more things fail on it.
So until I can afford to replace the entire APM1 with an APM2 I'll stick with my trustworthy MultuWii Paris board which just needs an I2C GPS to give me the basic hold and RTH.
I really have not got my money's worth out of this APM1 board. I think I've had one or two flights that remained stable throughout the flight. All other attempts have been randomly erratic and quite often ended up in hard landings or crashes. I've never been confident enough with it's performance to even think about letting it follow any waypoints.
I'm sure it is an excellent flight controller. There are plenty of APM1 users out there who have had plenty of success with it. I just ended up with a dud IMU and a bunch of add-ons I now cannot use (Minim OSD, XBee Pro 900, sonar, mag) till I fork out another $200 for an APM2.
I have solved almost the same problem with my custom compass based on HMC5883L. Please go through my post:
Hope It will help you.
I managed to test the DIYDrones compass with an Arduino Nano using the standard HMC5883L library which is set to use address 0x1E. No response from the thing. Just doing the same now with the eBay HMC5883L board now to see if it is responsive to the test calls. If that board is working then I'll wipe the APM and upload the same test code to isolate and see if the issue is with the APM1/IMU. Not much point in making code changes if any of the hardware is faulty.
With a new connector on my eBay HMC5883L board I no longer get the ERROR INIT COMPASS in CLI and the test compass values look good. So the DIYDrones mag was at fault.
That leaves this puzzle of the Sonar/Pitot Tube sensor connector - the V+ pin is surging up and down between ground and 3.85V. I have the sonar option enabled in the config. I checked if there is a direct link between +5V on the Mega and the sonar +V and there does not seem to be one. Does anyone know if this pin should always have a live +5V on it or is it via a digital pin on the Mega?
Can I bypass the +V pin with another +5V source on the IMU to drive the sonar? Might test that to see if I can get sonar reading in CLI.
Sonar works - as long as I use a different source on the IMU for +5V. Might see if there are any eagle files for the IMU and see where that pin traces back to.
Should also point out that the odd acc/gyro attitude I was getting on reset resolves itself with a working mag. I'd say having the mag enabled with a dead mag just mucks around with the attitude calculations.
Found the schematic file for the IMU. The perils of de-soldering with too high a temperature on the iron. Looks like the centre pad on JP5's top layer had been popped off the surface of the board on top of JP2's pin 2 (5V) on the bottom layer, completely isolating the track feeding the two 1k resistors R21 and R10 (which in turn feed power to the Tx/Rx LED's. Cannot understand how only one of the two tracks to pin 2 on JP2's bottom layer were severed. Pin 2 still gets 5V on the telemetry port. Must have only partially lifted the pad off the board.
Anyhow, since I can now see where the tracks go I can scuff off some of the paint and bridge the gap with solder.
Big thanks to Jordi for posting the Eagle files on the store. Could not have diagnosed the issue without them.
Is it normal to see in CLI - "test compass" a perfectly accurate heading which is not drifting when the IMU is left alone, but then in the Mission Planner HUD the heading just drifts slowly towards the reading I saw when testing the sonar in CLI. If I rotate the IMU there is a quick change in the HUD heading but then it slowly drifts toward the real heading.
At a guess the gyro reading is being mixed in with the mag reading on the HUD value. A quick twist overshoots the real mag reading and as soon as you stop moving the IMU the calculations hone in on the mag reading - slowly. Is there a PID value or setting I can change to allow the code to follow the mag reading a lot faster?
Wonder if that explains the slow drift to one heading after I make yaw corrections?