Weird Behavior set vs send commands with SC2


#1

Product: [SkyController + Bebop / SkyController + Bebop2]
Product version: [LATEST] + Bebop version: [LATEST]
SDK version: [LATEST]
Use of libARController: [YES] (Only for ARSDK)
SDK platform: [/Android]
Reproductible with the official app: [/NO/]

I have been experiencing some really odd behaviors recently while testing out some new features. I’ve noticed that periodically the drone will start ignoring set commands… like setPilotingPCMD and setCameraOrientationV2 and setVelocity… The only way I can recover from this condition when it occurs is to completely shut down my app (and ARSDK) and re-initiatlize

And it only ever happens when I have the SC2 connected. I have not tested with the SC1 yet, but I will here before too long.

What I am finding… and it has been a PITA to get this far, is I’m finding I have to use the send commands to ensure a reliable experience when an SC2 is connected. Basically I’m checking for the presence of featureSkyController and using send in place of set.

I know that send is a blocking call… it actually does a send and is something we should be avoiding, but I’m at a loss as to root cause absent this change.

I should mention that I’m toggling sendCoPilotingSetPilotingSource to do some pretty cool stuff behind the scenes and am relying on ARCONTROLLER_DICTIONARY_KEY_SKYCONTROLLER_COPILOTINGSTATE_PILOTINGSOURCE to keep track of who’s in control.

I have logs that clearly show the piloting source assigned to the correct device … and I should point out this should have absolutely nothing to do with mysteriously loosing the ability to control the camera orientation.

@Djavan or @Nicolas – you ever experience anything like this?


#2

Weird…
Could you put some logs in a non ack callback (for example here) to see if the loop is still active?
And of course, if you find a way to reproduce it, please tell us :slight_smile:


#3

recompiling now with some additional logging. thanks for the pointer!


#4

I put some logging in as requested… covering all return paths for the V1 and V2 orientation “must be sent” callbacks… looks like the control loop is running throughout. I see the following before and after I lose “set” functionality:

08-17 11:12:22.997 ... ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: fall thru
08-17 11:12:23.022 ... ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationMustBeSent: cmd version != 1

I’m adding some additional logging now to see if my data values are flowing in.


#5

Ok, I’ve been able to narrow this down a bit more. I have some of my own code to verify but here’s what I’m seeing:

Good state (post init, piloting source CONTROLLER):

08-17 11:52:44.993 29108-29108/com.shellware.arpro3.debug E/ARPRO3: 11:52:44:993 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed:245 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed tilt=-23.00 pan=0.00
08-17 11:52:44.995 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:44:995 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.009 29108-29108/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:009 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed:245 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed tilt=-26.00 pan=0.00
08-17 11:52:45.020 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:020 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.028 29108-29108/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:027 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed:245 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed tilt=-27.00 pan=0.00
08-17 11:52:45.046 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:046 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.046 29108-29108/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:046 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed:245 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed tilt=-31.00 pan=0.00
08-17 11:52:45.072 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:071 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.097 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:097 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.122 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:122 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.147 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:147 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.173 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:173 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.198 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:198 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.223 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:223 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.249 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:249 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.274 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:274 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.299 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:299 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:269 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: incrementing sending count
08-17 11:52:45.325 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:52:45:325 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:273 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: fall thru

I then do some stuff:

  • set piloting source to SC
  • set camera velocities to 0 as a safeguard
  • featureDroneManager.sendDiscoverDrones()
  • featureSkyController.sendWifiRequestWifiList();
  • featureSkyController.sendSettingsAllSettings();
  • featureSkyController.sendCommonAllStates();
  • featureCommon.sendSettingsAllSettings();
  • featureCommon.sendCommonAllStates();
  • featureBebop.sendMediaStreamingVideoEnable((byte) 0);
  • featureBebop.sendNetworkWifiAuthChannel();

And it is at this point things go sideways and a rogue ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Init is executed:

08-17 11:54:00.087 29108-30477/com.shellware.arpro3.debug E/ARPRO3: 11:54:00:087 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Init:183 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Init

And from that point on I no longer see “incrementing sending count” when attempting to change orientation:

08-17 11:55:07.327 29108-29108/com.shellware.arpro3.debug E/ARPRO3: 11:55:07:327 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed:245 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed tilt=9.00 pan=0.00
08-17 11:55:07.330 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:55:07:330 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:273 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: fall thru
08-17 11:55:07.344 29108-29108/com.shellware.arpro3.debug E/ARPRO3: 11:55:07:344 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed:245 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed tilt=10.00 pan=0.00
08-17 11:55:07.356 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:55:07:356 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:273 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: fall thru
08-17 11:55:07.362 29108-29108/com.shellware.arpro3.debug E/ARPRO3: 11:55:07:361 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed:245 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Changed tilt=11.00 pan=0.00
08-17 11:55:07.381 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:55:07:381 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:273 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: fall thru
08-17 11:55:07.407 29108-29265/com.shellware.arpro3.debug E/ARPRO3: 11:55:07:407 | ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent:273 - ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2MustBeSent: fall thru

I’ll keep digging. When an SC2 is not connected all the same commands (except those relying on featureSkyController) are executed and the rogue ARCONTROLLER_NAckCbs_ARDrone3CameraOrientationV2Init is never fired.


#7

Found my problem…

            featureSkyController.sendCommonAllStates();

I worked around it like so:

        if (droneData.getSkyControllerDeviceConnection().getStatus() != ARCOMMANDS_SKYCONTROLLER_DEVICESTATE_CONNEXIONCHANGED_STATUS_ENUM.ARCOMMANDS_SKYCONTROLLER_DEVICESTATE_CONNEXIONCHANGED_STATUS_CONNECTED) {
            featureSkyController.sendCommonAllStates();
        }

#8

Please do not send these commands. It is automatically sent during connection (by libARController itself). After that there is no need to send them again.