SDK 3.13 release


#1

Hi everybody,

SDK 3.13 has been released!

Here is the changelog:

  • Support of video stream on the Mambo
  • Support of new products: Parrot Bebop 2 Power, Parrot Bluegrass, SkyController 2P (the one which comes with the Bebop 2 Power).
  • New features: Animation, Thermal camera (for the Bebop-Pro Thermal solution)
  • New way of starting the video.
    Please now use ARCONTROLLER_Device_StartVideoStream(deviceController) and ARCONTROLLER_Device_StopVideoStream(deviceController) instead of sending the command.
  • Fixes and optimisations

To use this update on iOS, you’ll have to replace the former precompiled libraries with these new ones. You will also need to add these libraries to your Other Linker Flags: -lsdp -lrtsp -lfutils -lulog.
On Android, modify your build.gradle file with: compile ‘com.parrot:arsdk:3.13.0’

Hope you’ll like this new version, don’t hesitate to ask if you have any problem.

Best regards,
Djavan


#2

#3

Thanks for the new release… prepping and building it now. I noticed a subtle change to a couple gradle tasks, namely generateCommands and generateControllers in libARController and libARCommands.

Apparently on my system (OSX High Sierra + Android Studio 2.3.3 + Gradle Plugin 2.3.3) python3 does not act as an associative executable in exec Tasks. If I run gradle builds outside of the Android Studio environment these two tasks complete without issue.

I tried to figure out what root cause was but I eventually gave up and just hardcoded python3 in the two tasks.

def cmdline = ['/usr/local/bin/python3', ext.parser.absolutePath, ext.genrator.absolutePath, "-o", ext.destDir.absolutePath, "java"]`

Do you guys run builds internal to Android Studio and if so, any idea what Gradle related setting you applied to auto-associate .py files with python3?


#4

got another question regarding the animation feature.

Are the provided_params bits base 0 or base 1?

For example if I want to override the default play_mode for a dronie animation do I set bit 2 or 3?

   byte flags = 0;
   flags |=  (1 << 2);

   featureAnimation.sendStartDronie(flags, 0f, 0f, ARCOMMANDS_ANIMATION_PLAY_MODE_ENUM.ONCE_THEN_MIRRORED);

#5

I thought we did it for these libs, but not. Thanks for noticing.
Here is how we will fix it:

    def cmdline
    if (Os.isFamily(Os.FAMILY_MAC)) {
        cmdline = ["/usr/local/bin/python3", ext.parser.absolutePath, ext.generator.absolutePath, "-o", ext.destDir.absolutePath]
    } else {
        cmdline = [ext.parser.absolutePath, ext.generator.absolutePath, "-o", ext.destDir.absolutePath]
    }
    commandLine cmdline

We did not notice it on these libs because we always build at least once in command line.

For you second question, provided_params are base 0 (1 << DRONIE_CONFIG_PARAMS.PLAY_MODE).


#6

(1 << DRONIE_CONFIG_PARAMS.PLAY_MODE)

heh… you’d think I’d have figured this out myself. I will be sure to use the constants. Thanks for the pointers and quick follow up.

Always appreciated!

Shell


#7

I’ve got a couple other followups regarding 3.13 behavior given different drones (mainly Bebop V1 vs Bebop V2).

1.) I’m noticing some oddities between the documentation and actual behavior for the ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_CAMERASTATE_ORIENTATION, ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_CAMERASTATE_DEFAULTCAMERAORIENTATION, ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_CAMERASTATE_ORIENTATIONV2, and ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_CAMERASTATE_DEFAULTCAMERAORIENTATIONV2 events depending on the type of drone connected.

Even though the B1 supports the new camera orientation commands (setCameraOrientationV2). the original ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_CAMERASTATE_ORIENTATION and ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_CAMERASTATE_DEFAULTCAMERAORIENTATION events fire and the new V2 ones do not.

With a Bebop V2 I receive the V2 events. With a Bebop V1 I only receive the original (non V2) events, however the documentation has the originals marked deprecated and all drones (bebop v1, v2, and disco) supporting the V2 events.

Is this a bug or is the documentation incorrect?

2.) Documentation states that ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_PILOTINGSTATE_GPSLOCATIONCHANGED is meant to replace ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_PILOTINGSTATE_POSITIONCHANGED but the Disco isn’t included in the list of supported drones for GPSLOCATIONCHANGED. Both events fire when connected to a B1 or B2 drone. I haven’t checked the behavior with a Disco yet but plan to this weekend (will update this thread once I have those results).

3.). I’m guessing the Bebop V1 will never get the Camera Velocity commands / events…

4.). This is more of a firmware related question but it appears OTG storage has completely changed in the 4.x firmwares. I need to research further but it appears external storage doesn’t even mount.


#8

You’re right, the events have maybe been deprecated a bit too early. I don’t know if it will be another release of the Bebop 1, but it there is one, it will contain the V2 event. I will modify the documentation.

Documentation is correct (for the moment): Disco does not implement this event. I’ll see with the team if they can do it. We’ve deprecated this event too early since it should still be used for Disco.

It might if we release a new firmware.

I need to check that, I’ll keep you updated.


#9

Re storage

It mounts as sda1 in a read only state and after making it rw, I can no longer mount -bind it to the drone data folder.

Well, I can, but dragon-prog never sees the fs size change and the SDK mount info events never fire in any event.


#10

Talk about a nightmare…

For Android developers… I recently upgraded to Android Studio 3 and upgraded Gradle and NDK at the same time. All appeared fine initially with the exception of some NDK warnings about deprecated ABIs.

Everything worked fine for a couple days… switching variants, release types, etc and then last night as I was preparing a release build I lost all the out/ arsdk intermediates. And it got worse from there. My best guess is that when I switched build variants last night I triggered a clean or similar.

The first problem I ran into was Grade related (I upgraded to 4.0.1 from 3.3) … “compile” dependency operatives are no longer valid meaning that you have to use either “api” or “implementation”.

After reading up a little bit, I decided that I would replace all gradle “compile” references with “api”. Awesome, the gradle deprecated “compile” errors went away but nothing was getting built in my out folder. I’ve yet to figure out what else is broke, but it appears there’s something else preventing dependencies from the out/ directory to load / resolve.

I remembered doing the NDK upgrade (I went from 15c to 16) when I upgraded Android Studio to 3 so on a whim I dropped into my arsdk folder, renamed out and kicked off a new full build of the sdk. Apparently, not only did Google deprecate a bunch of ABIs in 16, but they also finalized removal of build specific headers, requiring apps to now use their “unified” ones. I fiddled around with a couple .mk files in the sdk (to get it to recognize NDK 16) and got a build launch but it eventually failed with a missing header (go figure).

On one hand I want to tackle both the gradle and NDK changes, but on the other, it will easily take me an evening or two or three to get it done.

Eventually, I reverted gradle to 3.3 and NDK to 15c and got my build done, but I got a taste for what it is coming and it doesn’t look pretty.


#11

You’re right, we should have communicate about the fact that the NDK 16 is currently not supported.

For the gradle plugin, I’ll see what we can do on our side to support it.


#12

I’m forever fascinated over the evolution (revolutionary?) approach Google takes with Android. They break stuff all the time. Gradle appears to be evolving in a similar manner… I’ve rewritten gradle configs so many times over the past 2-3 years that I’ve lost count.

This was the first time I ran into an issue with NDK in a very long time. While reading thru the 14b and 15c release notes you can see that they’ve been building up for some major backward compatibility issues. armv5 and mips are deprecated in 16 and with the progressive shift to the new unified headers (now mandatory in 16) they are making big changes.

Thanks for the response. I’m working with minimal sleep today.


#13

I got Gradle 4.3.1 working fine tonight.

All dependencies “compile” operatives were changed to “implementation” and I added the below to each project’s gradle “android” section to suppress a deprecation warning that was annoying me.

compileOptions {
    sourceCompatibility 1.8
    targetCompatibility 1.8
}

I can’t get it to break again and I’ve cleaned / rebuilt multiple times… I even deleted ${ext.root_dir}/out/${ext.product}-android/gradle/${project.name} a couple times to force things to rebuild.

Will stay with NDK 15c unless I get insanely bored.


#14

Hi,

If you’re not familiar with the internals of Alchemy, that’s a good idea :wink:

I’ve already done some tests on r16 integration, but our plan is to migrate from GCC to Clang at the same time we enable the unified headers (as both would require some patches in our libraries). And we’re not completely ready for this.

If you really want to try it, I can share some pointers on how to patch the SDK for ndk r16 compatibility, but that would be untested code (i.e. it compiles on my computer, and it seems to work fine, but don’t consider it stable).

Regards,
Nicolas.


#15

On android, I’m never seeing the following Mambo state events fire with valid data. The associated iterator is always null:

ARCONTROLLER_DICTIONARY_KEY_MINIDRONE_USBACCESSORYSTATE_LIGHTSTATE
ARCONTROLLER_DICTIONARY_KEY_MINIDRONE_USBACCESSORYSTATE_CLAWSTATE
ARCONTROLLER_DICTIONARY_KEY_MINIDRONE_USBACCESSORYSTATE_GUNSTATE

Documentation states the following for each:

@Override
public void onCommandReceived (ARDeviceController deviceController, ARCONTROLLER_DICTIONARY_KEY_ENUM commandKey, ARControllerDictionary elementDictionary) {
    if (commandKey == ARCONTROLLER_DICTIONARY_KEY_ENUM.ARCONTROLLER_DICTIONARY_KEY_MINIDRONE_USBACCESSORYSTATE_CLAWSTATE){
        if ((elementDictionary != null) && (elementDictionary.size() > 0)) {
            Iterator<ARControllerArgumentDictionary<Object>> itr = elementDictionary.values().iterator();
            while (itr.hasNext()) {
                ARControllerArgumentDictionary<Object> args = itr.next();
                if (args != null) {
                    byte id = (byte)((Integer)args.get(ARFeatureMiniDrone.ARCONTROLLER_DICTIONARY_KEY_MINIDRONE_USBACCESSORYSTATE_CLAWSTATE_ID)).intValue();
                    ARCOMMANDS_MINIDRONE_USBACCESSORYSTATE_CLAWSTATE_STATE_ENUM state = ARCOMMANDS_MINIDRONE_USBACCESSORYSTATE_CLAWSTATE_STATE_ENUM.getFromValue((Integer)args.get(ARFeatureMiniDrone.ARCONTROLLER_DICTIONARY_KEY_MINIDRONE_USBACCESSORYSTATE_CLAWSTATE_STATE));
                }
            }
        } else {
            // list is empty
        }
    }
}

But like I said, It never gets past the size() check on elementDictionary.


#16

I got beyond ^^^ this issue. It appears these events only ever contain populated data whenever the associated accessory is attached even though they fire (I’m guessing) with AllStatesChanged / etc.


#17

Hi All,

Version 3.13.1 has been released. It contains:

  • a fix of the camera accessory detection in the discovery through BLE
  • a fix of features that was set to null when the extension state changed on Android

Regards,
Djavan


#18

i don’t have a Skycontroller 2P or a Bebop 2 Power to test,
looking at the SKD i got a doubt…, when i connect the skycontroller 2P the product find is a
ARDISCOVERY_PRODUCT_SKYCONTROLLER_2P, ///< Sky controller 2P product
or a
ARDISCOVERY_PRODUCT_SKYCONTROLLER_NG, ///< Sky controller product (2.0 & newer versions)

if i connect to a Bebop 2 Power, the product found is always:
ARDISCOVERY_PRODUCT_BEBOP_2, ///< Bebop drone 2.0 product
or something different?

thanks


#19

You’re right,
when you connect a SkyController 2P, the product found is ARDISCOVERY_PRODUCT_SKYCONTROLLER_2P,
when you connect a Bebop 2 Power, the product found is ARDISCOVERY_PRODUCT_BEBOP_2.


#20

thanks for the swift reply as always…