How to control Gimbal from Olympe script

ANAFI USA / ANAFI Thermal / ANAFI 4K
1

I have now spent almost a full day trying to control my AnafiThermal Gimbal from a script without any success. I can start and stop the drone. I managed to get the Gimbal moving by sending a reset request to the Gimbal with:

drone(olympe.messages.gimbal.reset_orientation(gimbal_id=0)).wait()

So gimbal messages seems to work. I can also see the Attitude messages with the gimbal location if I turn on debug logging.

I have then tried to control the gimbal with a lot of combinations (mode/reference/values etc…) using the following command (was available in some Olympe example):

drone(gimbal.set_target(
    gimbal_id=0,
    control_mode="position",
    yaw_frame_of_reference="absolute",
    yaw=0.0,
    pitch_frame_of_reference="absolute",
    pitch=45.0,
    roll_frame_of_reference="absolute",
    roll=0.0,
)).wait()

The gimbal does not move when I issue the command. If I issue the command connected via the SkyController3 then the tilt function on the handcontroller stops working (so something is happening). I also tried to connect directly to the drone with SkyController3 turned off via WiFi with same result.
I have tested some messages that are not documented in Olympe documentation (olympe.messages.ardrone3.Camera.OrientationV2) but that did not work either…

Have anyone else got this working on a Anafi or do you have any good ideas what to do???

2

Hi,

Could you try the following command:

drone(gimbal.set_target(
    gimbal_id=0,
    control_mode="position",
    yaw_frame_of_reference="none",   # None instead of absolute
    yaw=0.0,
    pitch_frame_of_reference="absolute",
    pitch=45.0,
    roll_frame_of_reference="none",     # None instead of absolute
    roll=0.0,
)).wait()

and post associated olympe logs ?

It should work with or without the SkyController3 between your application and the drone.
olympe.messages.ardrone3.Camera.OrientationV2 shouldn’t be used on Anafi (it’s only useful for Parrot Bebop or Disco).

Thanks

Nicolas

3

No it did not work for me but I will use the gimbal feature in the FlihtPlan instead. I can use REST interface to download and upload flightplans from the drone and control the gimbal direction there instead. Saw that FlightPlaner6 saves QGC WPL 120 format but it accepted upload of QGC WPL 110 (can be generated by MissionPlanner). I will test if 110 works…

Anyway, that solves the issue for now :slight_smile: but it would be good to get it working…

/ Mats

4

I really don’t know what we’re missing here. The code above should work without any issue.

Could you please share the olympe logs of the following script ?

gimbal_set_target = drone(gimbal.set_target(
    gimbal_id=0,
    control_mode="position",
    yaw_frame_of_reference="none",   # None instead of absolute
    yaw=0.0,
    pitch_frame_of_reference="absolute",
    pitch=45.0,
    roll_frame_of_reference="none",     # None instead of absolute
    roll=0.0,
)).wait()
print(gimbal_set_target.explain())

when you are directly connected to the drone without a SkyController3 first, even if it shouldn’t have much impact.

Thanks

Nicolas

5

Thanks for your support. I did a quick test and I got same result as before. I have uploaded the python script, stdio and log file in the attached file.

gimbaltest.zip (15.5 KB)

1 Like
6

Hi eubmabe,

I still don’t understand what’s happening to this gimbal.set_target command. The drone just seem to ignore it for some unknown reason. Please continue to share any update you may have on this issue. Thanks

8

Thanks for the information. Could not find the link that you referred to. Could you share it?
Thanks
/ Mats

9

Hello there Parrot Dev Team!

I am having the same issues with the gimbal of ANAFI and ANAFI Thermal.
I noticed however something important!

I am using 3 different computers: A PC, a Raspberry Pi and a VM all with Linux O/S.

The “VFP ABI” does not function in Linux distros that are ARM based. Instead, the VFP ABI works as expected in all x86 CPUs and the VMs.

So, my question is if there’s a chance you guys at Parrot, do anything strange or handle the gimbal requests in a different way than all the rest requests in your C/C++ code through ARSDK.
If so, this could result to the commands being ignored by the gimbal, maybe!

Can you please check that out? …and if this is the case go and release an update please! :wink:

Best,
George Delaportas
Co-founder at ProboTEK
Enterprise Architect & IT Strategy Expert
Certified Security Researcher (Hacker) - ViR4X
https://www.linkedin.com/in/gdelaportas
https://kingston.academia.edu/GeorgeDelaportas

10

Hello,

Do you imply that the gimbal set_target command works on x64 but not on ARM based architecture?

That would explain why I wasn’t able reproduce this issue… ARM CPU are not (officially) supported by the SDK. I know that some of you guys managed to build the SDK for RPi but this architecture remains untested.

1 Like
12

Good day to all!

Any news on the issue?

Best,
George Delaportas
Co-founder at ProboTEK
Enterprise Architect & IT Strategy Expert
Certified Security Researcher (Hacker) - ViR4X

13

I am re-posting my theory as your spam filter deleted my post…

I am having the same issues with the gimbal of ANAFI and ANAFI Thermal.
I noticed however something important!

I am using 3 different computers: A PC, a Raspberry Pi and a VM all with Linux O/S.

The “VFP ABI” does not function in Linux distros that are ARM based. Instead, the VFP ABI works as expected in all x86 CPUs and the VMs.

So, my question is if there’s a chance you guys at Parrot, do anything strange or handle the gimbal requests in a different way than all the rest requests in your C/C++ code through ARSDK.
If so, this could result to the commands being ignored by the gimbal, maybe!

Can you please check that out? …and if this is the case go and release an update please!

Best,
George Delaportas
Co-founder at ProboTEK
Enterprise Architect & IT Strategy Expert
Certified Security Researcher (Hacker) - ViR4X

14

Yes , please avoid to post a signature with links.
This is not email :wink:

15

The logic for this part of the SDK is the same for every architecture. Anyway, the arsdk-ng library used by Olympe to communicate with the drone is also used by GroundSDK Mobile (Android and iOS) on ARM based CPU.

I am now suspecting that there might be some kind of ABI problem in Olympe C/Python autogenerated binding (olympe_deps.py). Can you please share this file (generated on your RPi) here ? You can find it from the groundsdk workspace directory at ./out/olympe-linux/final/usr/lib/python/site-packages/olympe_deps.py.

This file is generated by our fork of ctypeslib. ctypeslib is based on libclang and as far as I know has only been tested on x86 and x64. I think It’s possible that some strange ctypeslib memory layout bug on ARM is causing an issue that is only revealed with a specific gimbal commands…

The Raspberry Pi support is not on our roadmap for the SDK so I cannot make any promise.

3 Likes
16

Hello there,

Sure, please download the file from here.

Best,
George Delaportas
Co-founder at ProboTEK
Enterprise Architect & IT Strategy Expert
Certified Security Researcher (Hacker) - ViR4X

1 Like
17

Hi Nicolas,

Got any updates on the case?
Did the file helped at all?

Best,
George

18

I don’t see anything obviously wrong here in this binding file. In the header of the file, we can just see that the binding is generated for an ARM 32 bit processor with an hard floating point ABI (I don’t think the binding would work with a soft floating point ABI). The rest of the file seems to be coherent with a 32 bits cpu target.

Anyway, I cannot even try to debug this issue if I can’t reproduce it (without an RPi on hand…).

19

Hi Nicolas,

Thanks for your efforts!

Well, get an RPi and find a solution. I am sure you can :wink:

Best,
George

20

Hi Nicolas,

Let me give you my output on my Raspberry Pi 3 B+ if it helps at all…

I arsdkctrl: discovery ‘net’: start
I arsdkctrl: discovery ‘net’: add device name=‘ANAFI-1’ id=‘PI040445AA9D000340’
I arsdkctrl: discovery ‘net’: remove device name=‘ANAFI-1’ id=‘PI040445AA9D000340’
I arsdkctrl: internally disconnect device name=‘ANAFI-1’ type=ANAFI_THERMAL id=‘PI040445AA9D000340’
I arsdkctrl: discovery ‘net’: stop
Traceback (most recent call last):
File “/home/user/parrot-ground-sdk/packages/olympe/src/olympe/_private/pomp_loop_thread.py”, line 211, in _run_task_list
ret = f(*args, **kwargs)
File “/home/user/parrot-ground-sdk/packages/olympe/src/olympe/arsdkng/drone.py”, line 871, in _send_command_impl
raise RuntimeError(“[sendcmd] Error cmd interface seems to be destroyed”)
RuntimeError: [sendcmd] Error cmd interface seems to be destroyed
RESULT:
<ArsdkCommandExpectation: >

Best,
George.

21

Hi g0d,

I am following up to let you know that we’ve finally confirmed this bug for Olympe on ARM hf targets.

I’ve filled a bug report on Python ctypes which doesn’t use correctly the libffi API. ctypes should be calling ffi_prep_cif_var for variadic functions instead of ffi_prep_cif. But since ctypes doesn’t have any way to know it’s dealing with a variadic function it just always call ffi_pref_cif for every function.

This has absolutely no consequence on x64 . Conversely on ARM this has a dramatic consequence since the ABI of variadic functions (with float parameters) is different from normal functions. So when the arsdk_cmd_enc variadic function is called through ctypes the arguments of this function end up in the wrong registers. That explains why the gimbal.set_target (that takes float parameters) doesn’t work on Raspberry Pi.

The next release of Olympe will workaround this issue. We will just stop using variadic functions through ctypes.

2 Likes
22

Hi again,

This should now be fixed in Olympe 1.2.0 that has just been released.

Thanks for your patience

Nicolas

1 Like