Parrot Mambo - Python


He will! Or I will ensure I get the code going (but since I’m a professor and school is starting up, I’ve got other classes I’m focusing on at the moment). But I will ensure it gets there soon.

As for OpenCV: yes, I think the problem is entirely openCV and not the machine. I have a high end Mac and it dropped frames like mad. And another person who is using this code on a decent linux box has the same issues. It seems to be an interaction between opencv and python 3 as I can get it to work for a little bit under python 2 (but then the dropped frames kick in). In python 3, I can’t even get it to work at all and with zero informative error messages. I’ve rebuilt opencv from scratch and even FFMPEG but it didn’t fix it. I posted on the forum a few days ago but no one answered so I’m guessing no one else has ideas either.


@sletts021 I pushed some vision code to the repository tonight. I’m going to call this alpha but it is working in all my tests so far. I haven’t added any documentation on the wiki to it yet but the code itself is documented and there is a demo. I’ll be working on it more this week and I’ll update when it is an official release. Just wanted you to know that it is making good progress


I’m back to Windows for now. It was very easy to connect to the drone via wifi and get the live feed in VLC.

I came a little unstuck when using the demoMamboVision. Here’s my error. Where am I going wrong?


Make a “images” directory. GitHub refused to add my empty directory but that is where ffmpeg will write out its data.


Hint: Since you can’t commit empty directories in git (not github related, btw), so the easy way to create a “pseudo-empty” directory is to commit an hidden file (typically a .gitignore file, but any file name will work) inside the directory :wink:


Thanks! I’ll fix that right now :slight_smile:


Thanks :slight_smile: I am still a bit stuck. I am using the latest version from git which has the premade ‘images’ folder and getting this issue (folder structure on the right, if that helps :slight_smile: )
Thanks again for all your work! Kids are loving it.


I need to get a windows machine to test! I suspect this is due to how Popen works differently on windows. I think I can do a virtual windows installation this weekend on my Mac. I’ll do that and post any fixes and post here also. I only have linux and Mac at home so I haven’t been regularly testing on windows. For the record, which version of windows OS do you have? I’ll make sure that is what I install with my virtual install.


Windows 10, 64bit.

It’s odd, I used the previous version of pyparrot that I had installed, added the images folder and ran it - it produced a few images in the images folder (and the root) and then errored (I didn’t capture the error!). I have since overwritten the files with the latest git and that’s the error above. I’ll try and get the previous version from git and post the error too.

I might try linux if I get a chance today. The reason for Windows was that the Mambo’s network isn’t visible in Raspberry Pi for PC’s (unsecured network I guess?)


I reverted and here is the output from the demo vision file.

This is the commit I was running:


That is the windows socket error I’ve been trying to hunt down. My latest fix took care of it, I thought! The vision actually ran correctly there. The error happens on disconnect. When you run now, you need to clear out the images in the images directory (I guess I should add that to the code) but it should be working and have no more errors. I’ve been leaving the printouts in because I wanted to ensure everything was working and vision can take awhile to start.


Here’s the error I get with the latest commit (empty images folder).


In, I changed cwd to “images” which seems to have had some success :slight_smile: Here is the latest log.


  • The drone records 4044 frames in images

  • In the root dir 291 frames are stored as test_image_000291

  • The drone doesn’t fly (test fly = True)

              self.ffmpeg_process = \
              subprocess.Popen(cmdStr, shell=True, cwd="images", stderr=subprocess.PIPE, stdout=subprocess.PIPE)
          self.ffmpeg_process = \
              subprocess.Popen("ffmpeg -i rtsp:// -r 30 image_%03d.png &",
                             shell=True, cwd="images", stderr=subprocess.PIPE, stdout=subprocess.PIPE)
      print("Opening non-blocking readers")


This is odd. I’m going to debug by installing a virtual windows box and I’ll post back.


@sletts021 I figured it out! Took awhile to install windows but, once I had it running, it was a quick fix. I forgot that windows paths are \ instead of /. Now it looks for both! And I fixed a stray windows socket error while I was doing it. Also, I will keep my windows virtual installation around so I can debug future things in windows as well. Enjoy!


Hi @CaptainSaavik I was wondering if would be of good use to have BLE support on osx too? Let me know!


It says it is unstable on OS X and also only tested on 10.10 and 10.11. I’m on 10.13. While I’m not jumping all over it to try it, if you do try it and it works, let me know. I’m mostly focused on the wifi since there is much more information sent back over wifi. Plus I’m hoping to convince @Nicolas to send the information more rapidly than 2Hz on the next firmware upgrade!


I would also love to have more than 2 Hz. I mean I can see that 2Hz is enough if you keep it slow, but it would make much more fun if you could increase the speed. 5 Hz would already make a big difference. Because I really like the Mambo because of its size and stability, but 2 Hz is just a bit slow.