Mambo state information


Well, I invite you to test with our samples to see that the Mambo does sent these events.

I’ve modified the iOS Samples to add this code and I see all three logs:

        HASH_FIND_STR (elementDictionary, ARCONTROLLER_DICTIONARY_SINGLE_KEY, element);
        if (element != NULL)
            if (arg != NULL)
                float altitude = arg->value.Float;
                NSLog(@"Test Altitude = %f", altitude);
        HASH_FIND_STR (elementDictionary, ARCONTROLLER_DICTIONARY_SINGLE_KEY, element);
        if (element != NULL)
            float speed_x = arg->value.Float;

            float speed_y = arg->value.Float;


            float speed_z = arg->value.Float;

            NSLog(@"Test Speed = %f, %f, %f", speed_x, speed_y, speed_z);
        HASH_FIND_STR (elementDictionary, ARCONTROLLER_DICTIONARY_SINGLE_KEY, element);
        if (element != NULL)

            float q_w = arg->value.Float;


            float q_x = arg->value.Float;


            float q_y = arg->value.Float;


            float q_z = arg->value.Float;

            NSLog(@"Test Quat = %f, %f, %f, %f", q_w, q_x, q_y, q_z);


@Djavan I’m watching the raw stream of BLE send & receives and it sends battery and then (2, 18, 1). According to mini drone.xml, 2 is mini drone, 18 is NavigationDataState, and 1 is DroneSpeed. I never see a (2, 18, 2) or (2, 18, 4). 2 would be the altitude and 4 would be the quaternion.


@Djavan Here is what I see from my code below. Code first:

mambo = Mambo(owletAddr, debug_level=0)

print "trying to connect"
success = mambo.connect(num_retries=3)
print "connected: %s" % success

print "sleeping"
print "taking off!"



#print "trying to flip left"                                                                                                                                       
success = mambo.flip(direction="left")
print "mambo flip result %s" % success

mambo.fly_direct(roll=0, pitch=0, yaw=0, vertical_movement=10, duration=1)
mambo.fly_direct(roll=0, pitch=0, yaw=0, vertical_movement=-10, duration=1)

mambo.fly_direct(roll=0, pitch=50, yaw=0, vertical_movement=0, duration=1)
mambo.fly_direct(roll=0, pitch=-50, yaw=0, vertical_movement=0, duration=1)
print "landing"

Then here is what I see in my results ( I didn’t show it all as it is long). But you see that it never sends anything in the 2/18 paradigm except for 1.
updating sensors with
(2, 1, 2, 3, 1, 0)
updating sensors with
(2, 2, 0, 30, 0, 0)
updating sensors with
(2, 3, 0, 5, 2, 0)
pdating sensors with
(2, 4, 0, 5, 3, 0)
updating sensors with
(2, 1, 2, 18, 1, 0)
updating sensors with
(2, 2, 2, 18, 1, 0)
updating sensors with
(2, 5, 2, 3, 1, 0)


Hi, I just understood why we are not experiencing the same behavior. You are testing the Mambo without the camera whereas I’m using the Mambo + camera.

These two events (quaternion & altitude) are not sent when the Mambo has not the camera accessory.


@Djavan I just tested with my camera and it didn’t change anything. I’m still only seeing speed. Also, why would the camera make any difference in the altitude and quaternion computations? Even had the camera made it work, I’d be begging for it to work without it.


I should have mentionned Mambo with the camera, connected through Wifi.

The firmware team is currently evaluating sending those events without the camera, through BLE. I’ll let you know if they decided to do it or not.

Getting IMU values

@Djavan So they are being sent via wifi? And not through BLE? I don’t currently listen for any events over wifi except for the camera (e.g. the RTSP stream). That was a failure on the Raspberry Pi as it can’t handle the 30 fps bandwidth so I stopped my camera development.


@Djavan What protocol is it using to communicate on the wifi? The only data I’ve gotten from it is the RTSP vision. Is there a handshake? Also, what is the chance of sending it over BLE? That would be more consistent and reliable.




When the camera is plugged, you can access the mambo via the wifi interface like you would do for a Bebop (except that you use the mambo commands). Our samples provide support of the Mambo through either wifi or BLE with no code change outside of the SDK.

Regarding the commands only sent on wifi this is a design choice based on available bandwidth of the BLE connection. A discussion is ongoing with the firmware team to check whether we could still send those data on the BLE link, but with a reduced frequency, without harm on the “normal” user experience.



@Nicolas Thanks. I will update my python library to handle either WIFI or BLE soon then. Right now it is entirely BLE. I’ve been working on my bebop library but that means I’m learning the protocols for WIFI so that should be an easy transition. Thanks. I only have one camera and 3 mambos so I was hoping things would work over BLE as well. I understand the low bandwidth of BLE though!


@Nicolas and @Djavan I’ve got the wifi library started but I have a question: the handshake protocol says that I should be sending data to the mambo on port 6000 and I tell it that I want to hear data on port 43210 (I just used your example port).

This is what I send:
{“controller_type”: “computer”, “d2c_port”: 43210, “controller_name”: “pyparrot”}

This is what I get back:
{u’status’: 0, u’c2d_port’: 6000, u’c2d_user_port’: 21, u’c2d_update_port’: 51}

But I am not seeing anything on any port! I’ve tried putting listeners on all of the ports (43210, 21, and 51, all listed above) and I am literally seeing nothing. Have I misunderstood how it is working? The documentation on the protocols says that all the data should be coming back on the d2c_port.



@Nicolas Where is the documentation on talking to the mambo? I’ve gone through the samples and I found the parameters sent to the mambo but I cannot see where they are listening back from the FPV. Since I can’t hear anything back following the directions in the protocol documentation, I’m stumped. It will only listen to my first command and then it stops since I’m not sending ACKS to its data. But that is because it is being silent!



Since you got a proper response from the handshake, you should be getting data on UDP port 43210.

If you want a reference, I did a python implementation of the SDK (without video) while writing the protocol documentation, which can properly connect to a Mambo FPV via wifi. It might be a good starting point to check what is different in your implementation.



@Nicolas Thank you! The key was one line. You are using:

    self._recv_sock.bind(('', self._d2c_port))

and I was doing:

    self.udp_receive_sock.connect((self.drone_ip, self.udp_receive_port))

When I switched to your bind call, I am suddenly getting data back! Hooray!


@Nicolas I am seeing a very odd behavior in the wifi control. When I send it a command, it will go into some sort of emergency mode where the eyes turn red and it simply stops. Usually it doesn’t even success in takeoff but just turns the motors on. Once it took off then entered emergency mode mid-air and simply fell out of the sky. The BLE controller would simply hover if it disconnected so I assume this is something I am doing wrong in my communications but I have no idea what it would be. Can you enlighten me? I’ve been reading your bybop code to see if we do anything different in our communication and I do not believe that we are. Btw, it is not low battery (usual red eye issue) because if you connect using the iPhone or even my BLE controller, it flies just fine on the same battery. It is only my wifi program that is having this trouble. And it isn’t distance or signal strength. Today it was literally sitting ON my laptop so it was inches from the wifi!


@Nicolas Is there a way to change the update interval of the sensors? We are getting speed_x, speed_y, speed_z only every 500 ms, which is a huge interval for control. I am sure it is being computed internally more frequently. If there is a way to ask for feedback more frequently, perhaps in the json string, I would be very grateful.


Bumping. @Nicolas or @Djavan. I updated to the new firmware today and it is pushing new state info that isn’t in the xml file but it still seems to be pushing at 2Hz. Can we somehow ask the mambo for at least 5 Hz?? It is really hard to do anything with 2 Hz :frowning:


speaking of state… it would be really nice if the Mambo (it would be even nicer if it were all mini drones) correctly sent the ARCOMMANDS_MINIDRONE_PILOTINGSTATE_FLYINGSTATECHANGED_STATE_FLYING flyingState event.

I remember reporting this quite some time ago. All we get is the HOVERING state.


I just wish we could get data more frequently. They haven’t even answered if it is possible :frowning: I’m sure it is computed internally more than 2 Hz! 5 Hz please??? 2 is too slow for decisions!


I find the rate to be just fine over wifi. I’m guessing you’re struggling with BLE throughput.