Sumo-Drone Protocol: Sending a movement command stops video transfer


Yes, pkx, as you see above (it seems we wrote at the same time ) I finally got it and I will do some refactoring as I can now greatly simplify it. I see a lot light at the end of the tunnel.

Regard the price point: I was able to get some Sumos for “my” kids really cheap. I only have to repair the jumping mechanism (luckily I know how to do that), which is the only part that unfortunately has been engineered to be too weak.

cheers and thanks again for all your support - I really do appreciate it!


hi stefan, definitely keep us up to date w/ your project, and in particular, let us know what was wrong and how you fixed the jumping mechanism …

also, I looked at your above message & saw you wrote: “… I had thought I need to keep sending the Pcmd(0,0) until the next command actually is sent and until the next comes in. The only mistake I made was not to send the Pcmd(0,0) ONCE” in the end …"

but, I don’t understand this … I think, currently, that as long as you want to receive constant video messages, you need to send move messages of some sort within some constant rate. You are free to send whatever you like, including nothing, but then, that will stop the video …

or, as you saying, that: if you cap off the move w/ a 0,0, you’ll keep getting images w/ no need for extra movement commands ?


“or, as you saying, that: if you cap off the move w/ a 0,0, you’ll keep getting images w/ no need for extra movement commands ?”

Exactly: That is what I learnt! The only trick is to end the move sequence with a 0,0. Then you don’t have to send anything anymore and the video is still fine!


ah! very nice! this is a discovery, indeed! nice work, stefan!

I take my hat off to you!

… there then definitely needs to be some whole section on this in the protocols document, if this the “general behavior” across all classes of parrot devices that are compliant w/ this protocol …


Hum … that’s not what should happen.

My understanding of the link quality estimator from the Jumping Sumo (and earlier versions of the Bebop Drone) is that once you sent at least one PCMD, you have to keep them coming at constant interval. If you stop sending PCMDs, the drone will think that the network is getting really bad and will lower the video framerate (down to “0fps”).

I’m not at work now so I can’t confirm this from the source code, but i’ll check tomorrow :wink:

@pkx : No, this behavior is not part of the “ARSDK Protocol”, it is a higher level link estimator, developped in parallel by a different team, which is implemented only on Jumping Sumo (including Race/Light versions), and older Bebop 1 firmwares.
I decided not to include it in the documentation because sending a periodic stream of commands should not be (and actually is not, for Bebop/Bebop 2) required to keep the video stream. I this this kind of informations should be in the commands documentation (in the .xml files) … which is currently being updated :wink:



Too early happy :cry:

It seems it had an old library (that is my “libarcontroller”) mismatch when I used it in my application. @pkx and @nicolas for the confusion. So I refactored it back to continuously send the Pcmds and not it works reliably. What a pity - it could have been so easy.

Still, the hint from Nicolas that this refers only to Pcmds simplified the code a lot.

Nicolas, please I would still appreciate if you looked into the code at work. I am going to bed now, too.

Thanks for all the support.


thanks for spending the time to respond, nicolas !

oh, well, stefan - I guess you can’t be faulted for trying … I suspected that this sounded a little too good to be true …

… but what nicolas wrote has confirmed my suspicion: that the jumping sumo is exactly what I thought - a somewhat lower capability drone at a lower price point, simpler to use & perhaps made to introduce notions of robotics that can be fleshed out later on the bebop or w/ other more robust products …


Not really :wink:

When the Jumping Sumo and the Bebop were released, the behavior for both drones were really similar.
When we released the Bebop 2, we drastically changed the video pipeline, both internally, and on the network (switch from libARStream to an RTP-like libARStream2) to enhance the live video quality, typically at long ranges. This change was back ported to the Bebop 1 (to avoid getting two different APIs for two similar drones), but not to any other product as their video requirement is different.



oh, hi again & thanks for taking the time to respond.

let me also be careful to state that I’m not trying to disparage the device by writing the above, and, for what I was trying to do - which really amounts to education - it is perfect …


I definitely concur! I love the sumo for education!