Have followed the instructions, on the site, image is the emlib-raspberrypi2-raspbian-rt-20150401.img as listed.
ArduCopter-quad is from the github download as instructed.
Here’s my config.txt file
dtparam=spi=on
dtparam=i2c_arm=on
start_x=1
gpu_mem=128
[pi1]
kernel=kernel.rt.img
arm_freq=700
core_freq=250
sdram_freq=400
over_voltage=0
[pi2]
kernel=kernel7.rt.img
arm_freq=700
core_freq=250
sdram_freq=400
over_voltage=0
It seems like your clock settings are incorrect, remove the following strings from [pi2] to return to default:
arm_freq=700
core_freq=250
sdram_freq=400
over_voltage=0
Github code depending on repository and branches may be in different states.
Please try GitHub - ArduPilot/ardupilot: ArduPlane, ArduCopter, ArduRover, ArduSub source master branch, issues with AK8963 have been recently solved there.
We will update deb package with APM binaries soon.
I grabbed the code, but I can’t get it to compile. I need a few more instructions, or I’ll have to wait for you to refresh the deb packages. Thx
Hi,
The compass seems unreliable.
I’m testing with the Example AccelGyroMag. After a fresh boot it works well even for about half hour. But the compass output zeros after several tests—I mean, C-c and restart.
I’ve edit the AccelGyroMag.cpp, so that the main loop only run 100 times and abort. After several execute the Mag is zero. And rarely all output(Acc,Gyro,Mag) crash. It’s all zero or some random number.
Surely I can get the correct values after a fresh boot, but it’s really annoying to power off the board and power on.
I’m using a raspberry 2 model B, image is the emlib-raspberrypi2-raspbian-rt-20150401.img. Clock settings are:
[pi2]
kernel=kernel7.rt.img
arm_freq=700
core_freq=250
sdram_freq=500
over_voltage=2
force_turbo=1
Any help appreciated.
Problem seems solved.
My reference is
Line 424-428, which says:
Prevent reseting if internal AK8963 is selected, because it may corrupt AK8963’s initialisation.
So I’ve change the line 95 in Navio\C++\Navio\MPU9250.cpp
{0x80, MPUREG_PWR_MGMT_1}, // Reset Device
to
{0x00, MPUREG_PWR_MGMT_1}, // Reset Device
which prevent the MPU9250 from reset during initialize.
It seems works well for me now.
The problem with AK8963 has been fixed in the latest Ardupilot master. The problem was indeed the redundant reset. We haven’t got around to fixing the example. though. We can update the example or you can make a PR, if you wish. Thanks!
I also had this problem and initially thought that disabling the reset during initialization of the MPU9250 did not work for me, because after a few hard reboots (powering off and on my Raspberry Pi 2) the AccelGyroMag example still gave me all zero’s. Since I have got two instances of the Navio+ and Raspberry Pi 2, I tested the example after disabling the reset instruction on my other instance. That worked fine. Then I swapped the Navio+ hats to see if one of them is broken. But it didn’t seem broken since it now works. Then I swapped back the Navio+ hats to their original Raspberry Pi 2’s, to see if the problem is in the software image of one of the Raspberry Pi 2’s. To my surprise now the initial configuration worked.
So, why didn’t it work in the first test? Possible answers are:
Regarding the change in MPU2950.cpp, is it better to comment out the ‘Reset Device’ line (and decrement MPU_InitRegNum by 1) instead of changing 0x80 to 0x00? Because after looking at the register map document it seems to me that writing 0x00 to the MPUREG_PWR_MGMT_1 register actually doesn’t do anything.
Regards,
Bert
After some testing it seems that there is another problem in the MPU9250 initialisation as implemented in Navio/C++/Navio/MPU9250.cpp, which is timing. I modified my copy of AccelGyroMag.cpp to repeat the MPU9250 initialisation in a while loop along with reads of the Who Am I register and the AK8963 WIA register. I noticed that after a few minutes the values read became random and eventually stayed zero. I had to turn off and on the power to the device in order to be able to access the MPU9250 again.
I’m currently running a test after having modified MPU9250.cpp to wait 100 ms instead of 10 ms after each register write during the initialisation. It seems that the ‘Reset Device’ instruction must still be disabled as I’ve seen the AK8963 WIA register become zero after some time while running with the 100 ms delay implemented (and the ‘Reset Device’ instruction still in place). I’ll let this run overnight and report the result.
@Bert_Regelink In short, the issue is that during reset internal I2C bus could perform a transaction. If it was not finished properly, master might not be able to talk to AK8963 at all. So internal I2C bus should be disabled before resetting.
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?
