I also tested just reading the AK8963 WIA register containing the device id in the while loop (using the MPU9250::AK8963_whoami() function), thus performing the initialisation just once. After some time (minutes) garbage was reported instead of the device id (0x48).
Btw, my test last night ran without problems.
I still have “AK8963: bad DEVICE ID” quite often when running the latest version from the navio branch of the emlid/ardupilot repository. I also notice that I need to turn off the device for at least 10 minutes to let the MPU9250 recover from this state (which I still find hard to believe, but it seems reel as I’ve seen it happen quite often now that after a short (10 seconds up to 10 minutes) power-off it still does not respond with the correct number on a call to MPU9250::whoami(). After powering off for 10 minutes or more it always does respond correctly on a call to MPU9250::whoami(). Any ideas what causes this to require so long to remain powered off before functioning normally again?
@Bert_Regelink the fix appeared in GitHub - ArduPilot/ardupilot: ArduPlane, ArduCopter, ArduRover, ArduSub source (not emlid/ardupilot), please try it.
It is probably powered by the capacitors for some time after power is removed, this is why it would not reset immediately.
When I use a clean copy of emlid-raspberrypi2-raspbian-rt-20150401.img and power on my Raspberry Pi 2 (after being off for at least 10 minutes) and I execute the following code after 15 minutes of being powered on, then it reports a device id of 0x00. When I do not wait for 15 minutes after power on and execute shortly after boot, then it correctly reports 0x71. After that, when I wait for 15 minutes and execute it again, it reports 0x00.
When I compile and execute the bleeding edge from GitHub - ArduPilot/ardupilot: ArduPlane, ArduCopter, ArduRover, ArduSub source after that, then I get:
pi@navio-rpi ~ $ sudo ./ArduCopter.elf -A /dev/ttyAMA0
Raspberry Pi 2 with BCM2709!
Raspberry Pi 2 with BCM2709!
No INS backends available
pi@navio-rpi ~ $
After powering off for 10 minutes and immediately after boot executing ArduCopter seems to work fine. But when I terminate the application (CTRL+C) and execute it again afterwards, it results in “No INS backends available”. This message can be caused by an unsuccessful initialisation of the MPU9250 (judging from looking at the source code).
MPU9250Test.cpp
#include <cstdio>
#include "SPIdev.h"
#define READ_FLAG 0x80
#define MPUREG_WHOAMI 0x75
int main()
{
unsigned char tx[2] = { MPUREG_WHOAMI | READ_FLAG, 0x00 };
unsigned char rx[2] = { 0 };
int status = SPIdev::transfer("/dev/spidev0.1", tx, rx, 2);
printf("MPUREG_WHOAMI: 0x%02X\n", rx[1]);
return 0;
}
I think one of my Navio+ boards is broken, because none of this happens on my other Navio+ board. I’ve swapped the boards on the same Raspberry Pi 2 several times now and it is one of them giving weird values for any of the MPU registers after some time, including the WHOAMI register. Also on another Raspberry Pi 2 the MPU on this Navio+ board is misbehaving.
Hi, I have the same problem with the card and when I check the devices connected i2c no devices, try performing any of the examples and always get the same error when I start the example gyroscope always get zero. can you help me please?
Please post a picture of your setup.
Good morning, today when I turn the card is different, i2c settings shown me even GPS devices but does not send me details of position, the gyro works.
Do you perform GPS tracking in the house?
no, when I use gps I am outside home
For GPS to work there has to be a good sky view, it will work poorly in a building-dense area.
Also, mind that antenna has to be as far as possible from other electronics due to RF noise from it, even from the RPi itself.
Could you please run U-center with antenna placed outdoors and post a screenshot of satellite level bars?
http://docs.emlid.com/Navio-dev/GPS-ucenter/
This is a bit dated, but I’ve recently run into the same problem. Did you come up with a fix? Or is your board just faulty?
To test if compass is working, please do the following:
If I run the test it is fine. If I power cycle it it is fine.
But I should not have to.
Say I’m onsite - about to fly - do I have to wait a half hour and hope that it works? What is a permanent fix?
The fix for this is already in the dev version (you can use it instead):
ArduCopter 3.3 is getting closer to the release, I hope that this rc is the last one.
Thank you for your excellent pointer. Running dev on the bench and it works quite well. Will try for some field trials later this week.
This topic was automatically closed after 10 hours. New replies are no longer allowed.
