They work just fine with 3.6.11 on my build, I was thinking of upgrading to AC 4.0.4 for fun though anyways. Thanks!
One issue I’m noticing though is that during dronekit scripts only, I sometimes get “Bad Baro Health” appear in mission planner. If I fly about manually though there is no issue. Could this be dronevit vs AC3.6.x related?
Despite that, the mission performs as expected.
That’s great to hear!
If you do try out 4.0.4, let me know how that works for you! I have tried 4.0.0-3. With all I experience violent rotating upon takeoff in GUIDED mode. Others have reported this issue too. If you do go on this adventure maybe try a low altitude with a takeoff_and_land.py dronekit script. Of note, the issue occurs sporadically, and you can actually experience many good dronekit flights before experiencing this issue.
Regarding the bad baro health issue, I actually haven’t experienced that issue before. I occasionally receive bad baro health messages, but they always quickly subside. Additionally on my builds, I have experienced this in multiple flight modes. Do you notice any aggressive shifts in altitude when this baro message appears?
Hi @caleberg, I am also having trouble with the takeoff_and_land script. I went through the “build a raspberry pi drone” course in August, so I am pretty sure I have ArduCopter version 3.6.3 (judging from the “Downloading Ardupilot source code” video.
In order to get AC 3.5.5, do I just need to follow these two instructions?
git clone -b Copter-3.5.5 https://github.com/ardupilot/ardupilot
I also see that the 2:45 minute mark - end of the “Changing Firmware in NAVIO Image” video seems to reinstate this.
Thank you.
Hi there @Jspatafore49
Is your issue with the takeoff_and_land.py script related to dronekit timeouts, or something else?
If the former, I have had reports of students with working versions of AC-3.6., so I think the folks at Emlid may have fixed the timeout problem related to AC-3.6.
The numbered order for installing custom Ardupilot firmawre you lay out is correct. I would start out trying to clone a newer version of AC-3.6.* to see if the timeout issue goes away- maybe AC-3.6.11?
If that doesn’t work, the AC-4.0.* does not experience dronekit timeout issues- however, I have experienced erratic takeoff behavior documented here. If you use this version, make sure to set you takeoff height to 1 meter so if it does go crazy, the crash is soft(er).
If that doesn’t work, then using AC-3.5.5 is the next step. I have very little issues with this version, and while it lacks some features compared to the newer versions, those features aren’t likely to be missed too much (unless you really need them). The main drawback is the earlier version won’t support as many pieces of hardware (like rangefinders).
Hi @caleberg
I did end up installing AC-3.6.11, and had no luck with the takeoff_and_land.py script. I then replaced 3.6.11 with AC-4.0.3. The script can’t seem to break the “waiting for the drone to become armable” stage. Any suggestions? Thank you.
Hi @PhotonJon
I’m currently trying out AC-3.6.11 with dronekit 2.9.2, as I see you’ve had success with it. Did you happen to write the takeoff_and_land.py script from this course? If so, are you able to share it? I am having a ton of trouble trying to get it to work, and have tried multiple AC versions : 3.5.5, 3.6.3, 4.0.3 with DK 2.9.1, now trying to work AC- 3.6.11 + DK 2.9.2.
Let me know if you can provide any guidance. Thank you!
I have scripts that are very similar to what Caleb has published, they worked for me off the bat! I was using 3.6.11 and have recently upgraded to 4.0.3. Maybe there is some IP conflict or incorrect setting on the RPI? Sorry don’t think I can help much other than suggesting to recheck your setup. You can always post images of the problems!
Hi there @Jspatafore49
When you were using AC-4.0.3, did you check in MissionPlanner under the messages tab? It might provide some clues as to why the drone isn’t arming. There may have been some firmware upgrades from 3.6.* to 4.0.* that provided further arming checks, I’m not sure. But that waiting for drone to become armable should be actually indicative of something that has to be fixed, or a parameter that needs to be switched/turned off.
Hello, so for this step what hardware is necessary if I may ask ? I don’t have a PPM encoder, but I attached the GPS antenna and Telemetry(wasn’t setup with Missionplanner) to my Navio. I followed the steps in Caleb’s course on coding and I arrived up to this point. I had a few issues with writing and saving the code, but I resolved that. And now I’m wandering if the “Link timeout, no heartbeat in last 5 seconds” error is due to me missing some hardware/ proper hardware setup, software error with the version ect.(as I see in these replies) or my software manipulations.
Thanks in advance for any advice.
Hi there @Fedpanda
The lack of RC or a PPM encoder should not affect your dronekit script’s ability to connect to the drone.
What ArduCopter version are you using? If you are using anything in the 3.6’s and you are experiencing this issue, I would recommend you upgrade to something in the 4.0.'s. I would reference the lectures on downloading your own ArduCopter firmware and this will walk you through the process.
It is weird, some have issues with the 3.6 AC firmware, and others are able to connect just fine. I wonder if this has something to do with different Navio2 batches- perhaps there was a hardware problem and only some boards are affected? No idea, just thinking out loud.
I had the same timeout problem (navio2 on pi4) and fixed it by restoring the TELEM1 value in /etc/default/ardupilot ( or whichever default file you are using ) to its default setting:
TELEM1="-A udp:127.0.0.1:14550". I had changed the TELEM1 setting to point to a ground station, but the dronekit connect did not like that.
Note that I am connecting using
vehicle = connect(“127.0.0.1:14550”, wait_ready=True)