I was having issues, so I reimaged my disk with the rpi linux given. I have the navio+ board and the RPi2ModelB. I cloned the github and did all of the steps directly on my pi as listed in these instructions: http://docs.emlid.com/navio/Navio-APM/building-from-sources/
I downloaded 4.8.4 of gcc, and update the find_tools.mk file as suggested.
After make navio I received the messahe Firmware is in ArduCopter.elf
The way to run the APM as listed in the basic instructions (sudo ArduCopter-quad -A …) no longer works here, and as suggested above, I instead tried sudo ./ArduCopter.elf -A udp:GCSIP:14550 which returned the same error message again of PANIC: failed to take bus->sem 100 times in a row, in APCompass_AK8963
If there is a known reason or a solution to this, please let me know. Thank you!!
P.S. - I put the SD card in the second Pi/Navio that I have, and it returned the same exact response, so I am thinking that it is not a hardware issue, unless the model Pi that I have is incompatible or something.
@cstracq2 could you please run AccelGyroMag example on both Pi\Navio and post its outputs?
I ran this test. As soon as I moved the pi, every number became and remained zero. I stopped the process and reran it, and the values were still all zeros.
@cstracq2 it is possible that there is a connection problem between RPi and Navio. Could you please make a photo of how they are connected?
This is how they are connected:
I ran the test on the other pi, waiting a few seconds before moving the pi around. This one did not fail in the test but it did fail the same peculiar way (which is different from the original failures I was getting).
Then I put the same SD card back in the other pi (mentioned in previous reply) and ran the test. After a few seconds, I started moving the pi, and it seemed to work for a second until it went all zeros again.
Please always run ArduCopter with sudo, it is necessary as it requires direct access to the memory.
What power supply unit do you use? What are it’s output characteristics (voltage and amps)?
I am going to rerun this test in a minute with the apm directly downloadable from this site. I am currently trying to cross-compile, but the sudo ArduCopter-quad… command does not work anymore. I tried asking why in another thread, and I was simply recommended to try ./ArduCopter.elf…
Power Supply: 5V 2.4A
This is the same power supply that I used in the past when the initially downloaded apm was properly connecting to the GCS
When you install APM.deb it also sets up symlinks that allow you to run it like “ArduCopter-quad”.
When you are running a binary file from the directory you’re in you need to add “./” before the name of the binary file.
Thank you for helping.
Is there anything else that is missing when compiling the .elf file myself? Or is the only difference that I need to run it as ./ ?
Yes, there should be no other difference.
There have been many issues with trying to compile the .elf myself. Sometimes it has not failed to compile, but it has failed to work properly with the resulting .elf file. I had restarted and reimaged the SD card a few times in different attempts. I have also tried to cross compile and compile directly on the pi.
I just reimaged the SD card, downloaded your .deb, and I can successfully see telemetry from my GCS once connected. I also ran the test again and moved the pi after a second and then left it flat:
Is there any chance that I am getting outdated cpp files and it is resulting in an issue with cross-compiling? I just tried again with a new Ubuntu VM. I have gcc 4.8.4, I had to install git and gawk, and then I followed the instructions posted on the site and I am getting this error:
I just retried cross-compiling on Ubuntu. I received the same error message, but there was the .elf file created.
So I tried sending that file to the pi anyway, and the .elf runs, but I do not actually see the parameters on the GCS. After interrupting the process and restarting the ./ArduCopter.elf… I received “No INS backends available.” I restarted the pi, ran the command again, and this time received the same error as originally posted in this thread
@mikhail.avkhimenia so I realized a few things. “Cannot create file” didn’t actually reflect the lack of an .elf file created, and the error does not come up if I run as sudo.
And also, Running the same SD card in the both RPi/Navio setups shows me that there is clearly something wrong with the pi that kept returning 0s and was giving this error message. Is there a way to replace the hardware or find out exactly what the hardware issue is?
@cstracq2 Can you try disconnecting HDMI, keyboard and everything else except for Wi-Fi, then login using SSH and try same things again?
@ivereninov I did as you asked, only I used the Ethernet cable instead of WiFi because of the WiFi at my desk. This is from Ubuntu after I went into the pi using SSH. And I was about to go move the pi around, but it turned to all 0’s.
This pi also failed to run the apm:
Then I took the SD card out and put it in the working Pi/Navio setup. The AcGyMag test worked: Waited a second, moved it, then left it.
And this pi successfully ran the apm. (I interrupted it manually):
Could you please run another example (e.g. baro) on the troublesome Navio and try to move it? What would be the output?
I ran the baro test, and moved the device about 3-4 feet at the point with the red arrow, so the baro works, but the Accel/Gyro/Mag test fails. Are there other tests I can do?
Seems like there’s a problem with MPU9250 chip on one of your boards. Please send me a private message with your order number so I can organize you a replacement.
Just to add to this, I had the same error “PANIC: failed to take bus->sem 100 times in a row, in APCompass_AK8963” error when running my cross-compiled ArduCopter.elf build using “sudo ./ArduCopter.elf -A udp:x.x.x.x:14550”. I then ran AccelGyroMag file which seemed to behave fine. When I stopped that and tried starting ArduCopter.elf again, it ran with no issues and I could connect to AP. Not sure what happened the first time, but mine seems intermittent.
Mine was repeating, and even when it stopped, it would fail to run the APM for other reasons.