This depends a lot on the code you’re using, the particular operations you need to do, and the hardware you’re running it on. It’s very difficult to comment in a meaningful way without access to that information, although I understand that since this is for a competition you may not be willing/able to share those details. As with every optimisation task, I’d suggest a good starting point is to profile your code, and see where the most time is being spent.
As a general principle for Python applications, I/O bound tasks should be handled asynchronously where possible (e.g. using coroutines (async) or threads), so that the other components of the program don’t need to be held up by waiting time. CPU bound tasks (where a lot of processing needs to occur) should be separated into their own processes where possible, but things get a bit more complicated if there needs to be a lot of communication between different processes, or if your computer has very few cores.
In this case your video stream receiving + processing steps could be done in one process, which then sends the detection info to a main process that can do something meaningful with it (perhaps through a pipe or queue). Depending on what you need to do with the telemetry and control signals it may be relevant to put that into its own process or it could be best to keep it as part of the main process.
QGC is a compiled application written in C++ - that means that most operations will be at least a bit faster, and it doesn’t have the same GIL threading constraints that Python does. It almost certainly uses some form of threading/multiprocessing, but I couldn’t tell you exactly where without looking at the source, which isn’t super easy to understand.
I believe this is determined by the pilot input failsafe, which defaults to 3 seconds.
Looks like there’s a typo for the longitude value in that example function - it should say lon_int=0 but currently says long_int=0. I’ve opened a pull request to fix that in our docs, but you should also be able to easily change that in your code 
1 and 2 are fine to set once, 3 should be fine to set once, although I have a vague memory there might have been an issue with that - I’ll ask the software team. For manual control see point 1.
As is specified in the docstring of that example function, it uses this mavlink message. The typemask is described there (in the mavlink docs).
You can send the request, but it won’t be able to achieve it. If you don’t have control over an axis then you don’t have control over it - if you try to gain control over it by rotating other axes until one of them aligns with the one you wanted to control then you’ve now lost control over one of the ones you previously had control over.
Is there some way to get the vehicle to be always paralel to the ground?
That’s quite subject to interpretation, but assuming you’re ok with minor fluctuations then sure, you just need enough control axes to do it, and a control algorithm that will provide that control for you. ArduSub will provide the algorithm if you provide the axes and the set point. If you need 6dof with only 6 thrusters then you could try a setup like this.
If minor fluctuations aren’t ok then I suppose it’s still possible, but only if you can remove/negate all external forces, which likely means you’d need to keep your vehicle on a solid surface (e.g. make it heavy and sink it to the bottom, or keep it on a table or the ground out of the water). From a stability standpoint you could also try making your vehicle large and flat, so that it strongly resists turning about the roll/pitch axes, but that also significantly increases drag for vertical motion.
Yes, heartbeat messages should be sent by whatever your control application is, be that QGC or your own pymavlink program.
No, pymavlink does not do this automatically in the background.
- I’ve submitted a pull request to pymavlink for a background-thread-based approach here which hasn’t yet been accepted, and may not end up being. It does work however, so you’re welcome to use it if you want, but I’d suggest you read the discussion there to better understand when to use that over a synchronous/in-line approach. (Note that you’ll need to change the type parameter to GCS if you’re simulating a ground control station, as in @monsterbacke’s snippet)
- For a synchronous approach you can instead use the
periodic_eventclass from mavutil - It’s technically also possible to disable the heartbeat failsafe instead of sending a heartbeat, but it’s not recommended to do that because you could end up not being able to turn off your AUV even after losing contact with the control computer