0

I am looking for help working with the same vehicle from 2 different processes.

I have one SITL instance runnning. I am trying to connect to this same instance from both the main process of my DroneKit script and from a sub-process spawned in the same script.

Both connections work fine (MPAPIConnection object returned in both cases, with the same @ reference), but in the subprocess the connection object does not appear to be live, and the vehicle parameters are not updated.

In the example below, the location returned by the main process when the drone is moving is the actual location, but the location returned by the subprocess remains stuck at the initial location when subprocess was first started.

Example:

import time
from pymavlink import mavutil
import multiprocessing


class OtherProcess(multiprocessing.Process):
    def __init__(self):
        super(OtherProcess,self).__init__()

    def run(self):
        sp_api = local_connect()
        sp_v = api.get_vehicles()[0]

        while True:
            print "SubProcess : " + str(sp_v.location)
            time.sleep(1)

api = local_connect()
v = api.get_vehicles()[0]

sp = OtherProcess()
sp.start()

while True:
    print "MainProcess : " + str(v.location)
    time.sleep(1)

So is there a way to access the same vehicle from different processes within the same mavproxy instance ?

Willi Mentzel
  • 27,862
  • 20
  • 113
  • 121
benblass
  • 146
  • 1
  • 4

1 Answers1

0

You should try this again - DKPY2 (just released) uses stand-alone scripts and is designed with the idea that each Vehicle object returned using the connect() function is completely independent. It is certainly possible to connect to separate vehicles in the same script (same process) so very likely you can connect to the same vehicle and from separate processes.

Hamish Willee
  • 372
  • 1
  • 3
  • 11
  • Yes, I followed DKPY2 discussions on github, I will try again. Otherwise with DKPY1 a proxy manager is necessary. Thanks ! – benblass Oct 28 '15 at 05:38
  • I think your chances of this working effectively with DKPY2 quite high - but very low with DKPY1 - it simply wasn't a design requirement. – Hamish Willee Oct 29 '15 at 05:59