Sphinx remote control - different behaviour between local and remote controlling app - solved

ANAFI USA / ANAFI Thermal / ANAFI 4K
1

I’m sorry I have to continue my little series about “What am I doing wrong with Sphinx” (E01 here Sphinx 2.8 simulation runs very unreliable - #3 by Neil , E02 here Sphinx 2.8.2 - no video from simulated drone - #2 by Neil). Don’t be discouraged or upset: Since this is “work in progress” I do neither hesitate to admit own errors nor sharing my results. But it would be awesome, if you could assist me with some helpful comments.

OK, two machines in the same wired local network:

  • Ubuntu 20.04, Gigabyte G5, Sphinx simulator 2.8.2 installed, Parrot Olympe SDK 7.2 installed from source, IP 192.168.188.118
  • Raspberry PI 4, Parrot Olympe SDK 7.2 installed from source, IP 192.168.188.78

The test script:

import olympe
import os
import time
from olympe.messages.ardrone3.Piloting import TakeOff, Landing

# On simulator
DRONE_IP = os.environ.get("DRONE_IP", "10.201.0.1")
# On RPI4
DRONE_IP = os.environ.get("DRONE_IP", "192.168.188.118")


def test_takeoff():
    drone = olympe.Drone(DRONE_IP)
    drone.connect()
    assert drone(TakeOff()).wait().success()
    time.sleep(20)
    assert drone(Landing()).wait().success()
    drone.disconnect()


if __name__ == "__main__":
    test_takeoff()

While on the simulator the script runs more or less OK, even over several runs (except the strange unreliabilities mentioned in E01), it does not fully run on RPI4. In fact, even the log is different. The symptom is, that the drone on the PI never meets the assertion

assert drone(TakeOff()).wait().success()

It fails here. I see the drone starting and hovering, but it doesn’t land due to the failing assertion.

Besides this the log is full of “unknown message” warnings, which might explain the failing assertion.

Needless to say, that the script works fine on the PI with a real drone, but I also there noted the “unknown message” warnings, at least during the startup

Log from the simulator:
takeoff-log-simulator.doc (46.0 KB)

Log from the PI (actually a text file):
takeoff-log-pi.doc (41.1 KB)

Both logs are plain text files. I had to change the extension to overcome a limit in the board here.

If I omit the assertions the drone starts and lands fine from the PI. Wondering, why I have that “unknown messages” here.

2

Here the logs again, zipped, with original txt extension (for convenience).

logs.zip (12.5 KB)

4

The comparison of the first unknown message sequence shows, that at least “alarm.alarm” messages are unknown to the PI…

5

With sphinx, the DRONE_IP address should be 10.202.0.1 like so:

import os
import time
import olympe
from olympe.messages.ardrone3.Piloting import TakeOff, Landing
from olympe.messages.ardrone3.PilotingState import FlyingStateChanged

# On simulator
DRONE_IP = os.environ.get("DRONE_IP", "10.202.0.1")
# On RPI4
DRONE_IP = os.environ.get("DRONE_IP", "192.168.188.118")


def test_takeoff():
    with olympe.Drone(DRONE_IP) as drone:
        drone.connect()
        assert drone(TakeOff() >> FlyingStateChanged(
            state="hovering", _timeout=15)).wait().success()
        assert drone(Landing()).wait().success()
        drone.disconnect()


if __name__ == "__main__":
    test_takeoff()
6

Yes. Sorry, typo. I was hacking that on another machine. I’m using .202. of course.

As said: It works on the simulator machine, not on the PI, which uses the .118

7

Getting the same error with your script on the PI:

2022-06-20 09:51:20,156 [INFO]  olympe.scheduler - _destroy_pomp_loop - Pomp loop has been destroyed
Traceback (most recent call last):
  File "takeoff.py", line 23, in <module>
    test_takeoff()
  File "takeoff.py", line 17, in test_takeoff
    state="hovering", _timeout=15)).wait().success()
AssertionError

And these lots of “unknown message” warnings, which might point to a deeper error (maybe related to the way the SDK has been compiled on that device)

8

Hi,

To be honest, Raspbian is not a target that we tested at all for Olympe (and the native SDK in general), so a build issue is definitely possible here.
I’m pretty sure that we’ve seen that kind of issues in the past with (involutary) mixins of 64 and 32 bits code, especially on Raspberry PI’s where an arm6hf version of the OS is installed, while the default toolchain reports that the CPU is 64bits (arm64) capable. I have no guarantee that this is the problem, but trying the build on an arm64 version of the OS (or inversely, on an arm6hf if the current one is arm64) might solve your issue here.

Regards,
Nicolas.

9

The OS installed is Raspbian OS Buster, 32 bit

No, wait: As documented here Installation of Parrot Olympe 7.1 on RPI 4B - #5 it is:

Raspberry PI OS Lite Legacy due to issues with GStreamer

Operating system images – Raspberry Pi.

10

Would you think a 64 bit version could be of help here? Wondering about a way to check if it would be sufficient to just check if the warnings are gone…

11

I also cannot estimate, how severe this problem is. Up to now I had no problem with the “unknown messages”, which might be no guarantee for further tasks down the road.

12

And is there any explanation, why a “real” drone does not have this problem of not being able to obtain the “takeoff.success” state? Just the simulation?

13

Was trying to compile Olympe on Raspberry OS 64 aarch64 to no avial.

postinst step fails

Requirement already satisfied: clang~=6.0 in /usr/local/lib/python3.9/dist-packages (6.0.0.2)

Reading package lists… Done

Building dependency tree… Done

Reading state information… Done

E: Unable to locate package libclang-6.0-dev

E: Couldn’t find any package by glob ‘libclang-6.0-dev’

E: Couldn’t find any package by regex ‘libclang-6.0-dev’

14

OK, managed to compile Olympe on 64 bit Raspberry PI OS Lite (Bullseye).

Simulation works remotely, drone starts and lands, no “unknown messages” anymore.

Solved

15

Unfortunately just half the truth: The new 64 bit OS terminates support for OMX and avenc_h264_omx (Hardware H.264 encoding support), which was required for doing the transcoding of the Anafi video in real-time.

Up to now I don’t have found any running replacement. v4l2_m2m and Co. don’t work for me.

Typical Catch22: Needing a 64 bit OS in order to be able to talk to the drone (?) and simulator (!) but this smashes my well working H.264 hardware endoding…

What a mess…

16

Problem solved too now. No issues anymore regarding this thread.

17

Hi,

I suppose that you were not using the latest release of Olympe (may be a 7.1 instead of a 7.2) on your 32 bits RPi OS. That would explain the “unknown message” errors (unrelated to your issue and harmless).

That being said, that doesn’t explain why you weren’t able to use Olympe on that system but since we don’t perform automated tests on RPi or any 32 bits OS anything is possible… I don’t see anything in your logs that would explain why you weren’t able to control the simulated drone from your 32 bit OS.

I’m glad you’ve found a solution to your hardware encoding issue too. :slight_smile:

18

Thanks @ndessart. Yes, you are right, I had a 7.1 on my 32 bit box. Also a source installation, maybe 2 months ago or so.

You mean the “unknown messages” might have been completely unrelated to a possible 32/64 bit mess? Just an incompatibility between what was running on the simulator (7.2) and on the PI (7.1)? New messages?

Okayyy… Then :slight_smile: I had a lot of headaches on this because of the unknown consequences. Will I miss messages down the road since I don’t understand them? That was the open question.

But what remains is the fact that I wasn’t able to successfully meet the “assert(drone(TakeOff()).wait().success())”. That’s a matter of fact.

OK now I’m no 64 bit bullseye and after fixing the hardware encoder thing everything works again so far. Not too bad.

19

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.