I couldn't connect to the ROV after resuming the thread

yaw () is the yaw function I defined with channel 4, and here I created a thread to control this function. I wanted the thread to pause and then resume, but I found that when I paused the thread, I couldn’t resume the thread. I suspect it was a communication blackout, but I don’t understand why it happened. Is there any way to avoid it?
Thank you for your reply!

Hi @robotmark,

This is more of a general Python question than one specific to ArduSub/pymavlink usage. You haven’t explained what’s actually happening here when you try to pause / resume the thread, and you’ve posted your code as an image so it’s not easy for us to try to test your code ourselves (see the formatting section of the How to Use the Blue Robotics Forums post).

This stackoverflow response was the first result from an online search of “python pause thread”, and takes an alternative approach of passing in the event and function to run rather than subclassing threading.Thread and creating the event inside it. It may be worth trying that approach since it seems to have worked for others there (although it’s possible something else is causing your code not to work).


If you’d like more help then please provide:

  1. System information (device you’re running the code on, Python version, library versions as relevant)
  2. Minimal working example in a code block or repository
  3. The full output you’re getting when you run your program (e.g. printed results, any error messages, etc) in a code block

Thank you for your reply. Now I will specifically describe the problem I encountered. When the program run to line 107 “add_thread2.start()”, the ROV starts to rotate. When the ROV rotates for 3 seconds, line 109 “add_thread2.pause()” is executed, and the ROV stops rotating. Line 111 of code “add_thread2.resume()” is executed after stopping the rotation for 5 seconds, but I find that the ROV has not restarted the rotation until the program was finished.
I have attached my code below:

class Yaw(threading.Thread):
    def __init__(self, *args, **kwargs):
        super(Yaw, self).__init__(*args, **kwargs)
        self.__flag = threading.Event()    
        self.__flag.set() 
        self.__running = threading.Event()
        self.__running.set() 
    def run(self):
        while self.__running.isSet():
            self.__flag.wait()  
            #print (time.strftime("%Y-%m-%d %H:%M:%S", time.localtime()))
            yaw(1600)    # Yaw with pwm output of 1600
            #print("run now")
            #time.sleep(1)
    def pause(self):
        print("pause")
        self.__flag.clear() 
    def resume(self):
        print("resume")
        self.__flag.set() 
    def stop(self):
        print("stop")
        self.__flag.set()  
        self.__running.clear() 

add_thread2=Yaw()
up_down(1400,2)     # Let the ROV sink at 1400 pwm output for 2 seconds
change_mode('ALT_HOLD')     # Changed flight mode to "ALT_HOLD"
add_thread2.start()
time.sleep(3)
add_thread2.pause()
time.sleep(5)
add_thread2.resume()
time.sleep(5)
add_thread2.stop()
disarm()

The terminal output is as follows:

By the way,I found that when I released the comment on line 91,I found that the print was fine. Therefore,I suspect that the communication was broken after the thread was suspended,so the ROV could not resume rotation.Thanks again you for your reply!

The terminal output shows that it’s resuming as expected, so it’s the commands to the vehicle that aren’t working as you expect. Most likely that’s due to a failsafe causing the vehicle to disarm automatically, so when you resume the thread and start sending more movement commands it ignores them because the vehicle is no longer armed.

How can I prevent the ROV from disarming? Otherwise I have to try arming again, which may take a little time and the machine may return to the surface.
Thank you for your reply!

The failsafes are there to ensure the vehicle is still under control. Ideally your program should send regular heartbeat messages (which avoids the heartbeat failsafe), and also send regular control inputs (which avoids the pilot input failsafe and also the rc override timeout).

It’s also possible to disable the failsafes from the Safety Setup Page, although that’s not recommended (they’re there to help, and if your control program freezes or crashes while failsafes are disabled your vehicle could run away and/or cause damage to itself or its surroundings).

Can I only disable failsafe in QGC? Does this disable failsafe take effect when I program to control the ROV? Do I also need to reset failsafe in the code?
Thanks again for your reply!

The failsafes are based on parameters. It’s easiest to modify them in QGC because it provides a convenient interface for doing so, but you can also set the parameter values manually with MAVLink messages if you prefer.

Parameters are maintained across vehicle restarts. If you configure them once (in QGC or otherwise) then they will maintain their newly configured states until you next reconfigure them.

If you want to turn them off only temporarily in a program then you’ll need to make sure your program turns them back on when it finishes.

Thank you again for your answer!

1 Like

A post was split to a new topic: Waiting for the vehicle to arm