Hi Caleb I’m very glad to see you checked in on the questions. Since I did not hear back, I tried going over to udemy to ask another question I had, but did not hear back and had to bail.

Since I have your attention, I would appreciate it if you could answer my one lingering question that has bugged me for months. I was able to run all the dronekit bash scripts except for I simply cannot get it to work. I’ve reinstalled everything from scratch more than once, examined the code in detail, yet no luck.

It’s just copied from your script:

> #########DEPENDENCIES####################
> from dronekit import connect, VehicleMode, LocationGlobalRelative, APIException, Command
> import time
> import socket
> import exceptions
> import math
> import argparse
> from pymavlink import mavutil
> ##########FUNCTIONS######################
> def connectMyCopter():
> 	parser = argparse.ArgumentParser(description='commands')
> 	parser.add_argument('--connect')
> 	args = parser.parse_args()
> 	connection_string = args.connect
> 	if not connection_string:
> 		import dronekit_sitl
> 		sitl = dronekit_sitl.start_default()
> 		connection_string = sitl.connection_string()
> 	vehicle = connect(connection_string,wait_ready=True)
> 	return vehicle
> def arm_and_takeoff(targetHeight):
> 	while vehicle.is_armable!=True:
> 		print("Waiting for vehicle to become armable")
> 		time.sleep(1)
> 	print("Vehicle is now armable")
> 	vehicle.mode = VehicleMode("GUIDED")
> 	while vehicle.mode!='GUIDED':
> 		print("Waiting for drone to enter GUIDED flight mdoe")
> 		time.sleep(1)
> 	print("Vehicle now in GUIDED MODE. Have fun!!")
> 	vehicle.armed = True
> 	while vehicle.armed==False:
> 		print("Waiting for vehicle to become armed")
> 		time.sleep(1)
> 	print("Look out! Virtual props are spinning!!")
> 	vehicle.simple_takeoff(targetHeight)  ##meters
> 	while True:
> 		print("Current Altitude: %d"%vehicle.location.global_relative_frame.alt)
> 		if vehicle.location.global_relative_frame.alt>=.95*targetHeight:
> 			break
> 		time.sleep(1)
> 	print("Target altitude reached!!")
> 	return None
> ##########MAIN EXECUTABLE#################
> vehicle = connectMyCopter()
> ##Command template
> #Command(0,0,0,FrameOfReference,MAVLinkCommand,CurrentWP,AutoContinue,param1,param2,param3,param4,param5,param6,param7)
> wphome=vehicle.location.global_relative_frame
> ##List of commands
> cmd1=Command(0,0,0,mavutil.mavlink.MAV_FRAME_GLOBAL_RELATIVE_ALT,mavutil.mavlink.MAV_CMD_NAV_WAYPOINT,0,0,0,0,0,0,,wphome.lon,wphome.alt)
> cmd2=Command(0,0,0,mavutil.mavlink.MAV_FRAME_GLOBAL_RELATIVE_ALT,mavutil.mavlink.MAV_CMD_NAV_WAYPOINT,0,0,0,0,0,0,44.501375,-88062645,15)
> cmd3=Command(0,0,0,mavutil.mavlink.MAV_FRAME_GLOBAL_RELATIVE_ALT,mavutil.mavlink.MAV_CMD_NAV_WAYPOINT,0,0,0,0,0,0,44.501746,-88062242,10)
> cmd4=Command(0,0,0,mavutil.mavlink.MAV_FRAME_GLOBAL_RELATIVE_ALT,mavutil.mavlink.MAV_CMD_NAV_RETURN_TO_LAUNCH,0,0,0,0,0,0,0,0,0)
> ##Download current list of commands FROM the drone were connected to
> cmds = vehicle.commands
> cmds.wait_ready()
> ##Clear the current list of commands
> cmds.clear()
> ##Add in our new commands
> cmds.add(cmd1)
> cmds.add(cmd2)
> cmds.add(cmd3)
> cmds.add(cmd4)
> ##Upload our commands to the drone
> vehicle.commands.upload()
> arm_and_takeoff(10)
> print("after arm and takeoff")
> vehicle.mode = VehicleMode("AUTO")
> while vehicle.mode!="AUTO":
> 	time.sleep(.2)
> while vehicle.location.global_relative_frame.alt>2:
> 	print("Drone is executing mission, but we can still run code")
> 	time.sleep(2)

When I run it I get the following, where it just stops -

I have to Crtl-C to get out, and when I try again I get a slightly different result



The error message after Ctrl-C was the following. It refers to line 93 which is:



I think there are two problems here:

  1. “Port 5760 Already In Use”
    When you have to Ctrl+C from the script, you are leaving the dronekit-sitl program running on port 5760 in the background. Then when you try and run it again, a new dronekit-sitl instance will try to create and utilize port 5760, but since it is already in use, it cannot create from scratch.

I am going to update the suggested code for ‘launchSitl’, but to avoid this issue going forward, I would suggest added these lines to the beginning of your launchSitl script:

kill -9 $(ps -eF | grep QG | awk -F' ' '{print $2}') > /dev/null 2>&1
kill -9 $(ps -eF | grep ardu | awk -F' ' '{print $2}') > /dev/null 2>&1
kill -9 $(ps -eF | grep mav | awk -F' ' '{print $2}') > /dev/null 2>&1
kill -9 $(ps -eF | grep apm | awk -F' ' '{print $2}') > /dev/null 2>&1

This code at the beginning of launchSitl will close down any of the programs that use the ports needed to launch a new SITL drone.

  1. not executing/getting stuck

Strange, the code looks alright.

Does the script work when you run it without launchSitl?

Can you determine at what point the code is stopping by placing unique print(“TEXT”) lines in between the various steps?

For example, add a line after

  1. cmds.wait_ready()
  2. print(“POINT A”)

Then after

  1. cmds.clear()
  2. print(“POINT B”)

Gaining some intel on where the script is breaking could be helpful.

We could also try configuring the launchSitl script to use the SITL vehicle from /ardupilot/build/sitl/bin/arducopter instead of dronekit-sitl to see if there is some weird problem exclusively with the dronekit-sitl version.

Also, the code looks good, but I could attach the text of an ‘’ script that I was successfully able to run just this yesterday.

Really want to get this figured out!!


That was a good idea. It appears to get hung up with the upload command, consistent with the report from the second message above regarding line 93:

I waited about 10 sec before I bailed.




Hmmm, so it is struggling uploading commands to the drone. Perhaps there is a problem with the dronekit-sitl (Version Copter-3.3) copter that the launchSitl script is using.

Lets try launching the sitl copter (Version 3.5.5) from the ardupilot directory. If it works, than the issue had something to do with dronekit-sitl, if it doesn’t work then our issue is not related to the sitl vehicle.

Lets edit the launchSitl script at /usr/local/bin

##Comment out dronekit-sitl instance
#/usr/local/bin/dronekit-sitl copter --home=37.034233,-95.642081,0,180&

##Add the compiled sitl arducopter from the ardupilot/build directory
/home/caleberg/fc/apm/ardupilot/build/sitl/bin/arducopter -S -I0 --home 44.5014,-88.0602,584,353 --model "+" --speedup 1 --defaults /home/caleberg/fc/apm/ardupilot/Tools/autotest/default_params/copter.parm&

Make sure to replace the path to your ardupilot sitl vehicle.


Didn’t seem to work, yet a few more status statements were revealed.

And something happened to QGC…

By the way, I tried to execute a few of the other programs first. They now won’t arm… What am I missing here?


If an alternative configuration is possible, I am certainly willing to re-install everything to test it.


Jack, I believe running the ArduCopter from the ardupilot/build directory requires a much longer time to arm compared with the dronekit-sitl vehicle. This could explain why even wasn’t working for you when you tried launchSitl with the new SITL vehicle.

Try letting it run for a really long time, like 5 minutes, to see if it will 1.) become armable and 2.) If the commands will upload for auto mission.

Let me know what you find!


Same response… I think I let it go for over ten minutes. What is interesting is, I seem to be the only one reporting this issue. Everyone else is able to fly it as originally configured? I’ve even reinstalled it from beginning to end several times.


Darn! When you let it ride for 10 minutes, was that with the ardupilot/build version of SITL?

You are correct in saying most other people are able to run this successfully, including myself when I recently retook the course from scratch on 9/25/19. For that reason, it smells like your system must be configured someway different than me. Did you happen to upgrade Ubuntu to 18.04? You can check with:

lsb_release -a


Yes, it’s a mystery. I would be willing to go through the course once more, rather than using my notes, but it’s a bit too pricey for me right now.

I used the code change provided above, so I assume it is the ardupilot/build version of SITL:

##Add the compiled sitl arducopter from the ardupilot/build directory /home/caleberg/fc/apm/ardupilot/build/sitl/bin/arducopter -S -I0 --home 44.5014,-88.0602,584,353 --model “+” --speedup 1 --defaults /home/caleberg/fc/apm/ardupilot/Tools/autotest/default_params/copter.parm&

It is ubuntu 16.04.6


FYI to all: I wanted to finish this thread in reporting I was able to successfully flesh out the issue with

It seems that because I wrote outside of the linux environment (ie, windows), and moved it over to linux, there are some hidden codes that linux was not happy with. So I manually typed it all in with gedit and it worked as expected. This occurred even if I wrote it as a simple text file which I thought stripped OS specific codes.

Seems peculiar, but it worked.