hi stefan, I think nicholas will answer better, but, I think what he’s doing, or what make sense to me is that, from a “piloting thread” he writes to some location - let’s call it “the move store” - what the pcmd should be, and then there is a loop in a “movement thread” that reads from that “move store” at some fixed interval and, at least as long as for the duration you want the video feed, will send move commands its read from the move store.
in the case above, he writes to move to the front, some value, and then goes to sleep for 2 seconds - in his piloting thread. Now, behind the scenes, so to speak, his movement thread is reading from the store and writing packets, perhaps once every 100ms or what have you, and, when his piloting thread wakes up and writes now 0,0 to the store - for being still - the movement thread just keeps going in its fashion, writing packets whatever it reads from the store. In this case, its reading and then writing 0,0, and the drone is still. Again, this loop never stops and, at least in so far as the computer controlling the actions is consistent, those packets are consistent.
now, in terms of your message queue, I’d imagine that you might have several threads writing to it, responding to things it reads, such as acks or pings and so on … you might make it a dequeue or some form or priority queue, if you absolutely had to elevate a response, as perhaps you would want to do w/ a ping/pong.
as I wrote elsewhere in this chain, I think it would help if that video feed could be made fixed and perhaps on a separate socket, although perhaps as we begin to look at higher class items from parrot, perhaps such as the bebop, we might find that there is more robustness and the ability to do this … As another example, I wish that I could change the angle of the camera, in order to point it more downward - for something I am doing … But, overall, I think that the jumping sumo is exactly at the price point and sophistication level that we wanted it at …