General comments

When a problem occurs, the first thing to do is to check the traces left by the software. In particular, the shell from where you launched sphinx may show valuable pieces of information. To increase the verbosity, just launch sphinx with the option --log-level dbg.

Another source of logs is syslog (/var/log/syslog). It mainly contains the logs posted by firmwared.

Unable to connect the drone via the virtual ethernet interface

While the simulation is running, ifconfig should show an interface ‘fd_vethx’ up:

$ ifconfig

fd_veth0  Link encap:Ethernet  HWaddr 66:a8:ad:06:b2:6b
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::64a8:adff:fe06:b26b/64 Scope:Link
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:422 (422.0 B)  TX bytes:534 (534.0 B)

If this is not the case, the network-manager coming with your linux distribution may interfere with sphinx. A solution consists in disabling the network-manager while you are using sphinx.

The simulation does not start

There can be many reasons for that. Here is a short list.

Sphinx crashes when starting, mentioning the locale

A simple export LANG=C can resolve the problem.

Sphinx has crashed leaving behind a running firmware

Despite our best effort in rare circumstances Sphinx may crash leaving behind some zombie running firmwares. In such scenario, those running firmwares may use system resources preventing you from launching any new simulation. When it’s time to clean up everything use the following command:

$ fdc drop_all instances

This command will kill any running firmware instance and unmount all firmware instances.

During the simulation the drone acts erratically, gets uncontrollable and/or falls.

The reasons for that issue are likely to be numerous. We are going to focus on the most relevant ones.

  • The real time execution is disturbed by another process. It is highly recommended to avoid running any CPU/GPU consumming task while sphinx is on.
  • On some laptop, the energy saving mode can lead to some disturbances. In that case, check if a kernel module called “intel_powerclamp” is present. If yes, remove it:
$ sudo rmmod intel_powerclamp

To inhibit it once for good:

$ echo "blacklist intel_powerclamp" > /etc/modprobe.d/disable-powerclamp.conf

My wifi interface got its name changed after exiting the simulation

To workaround it and set the wifi interface name once for good, proceed as follows:

  • Create a new udev rule file:

    • /etc/udev/rules.d/76-netnames.rules for Debian 9+
    • /etc/udev/rules.d/70-persistent-net.rules for other distributions
  • Add and adapt the following instruction:

    SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="<Wifi_card_MAC>", NAME="wlan0"

    Replace <Wifi_card_MAC> by the wifi MAC address. You can find it easily with the ip addr command.

    Important: Wifi MAC address needs to be written in case-sensitive way, meaning the same way as provided by ip addr

  • Deactivate/reactivate the wifi card so that the changes are taken into account by udev.

That way, the wifi interface wifi always has the name wlan0 from now on.

The simulation is very slow / does not work

This might be due to the front camera activation. Sphinx users wishing to active video and having a graphics card not sufficiently powerful can choose the low_gpu mode, accessible within the machine_params.

With the low_gpu mode activated, if you are able to connect to the drone but still can’t take off, you should retry with the drone front camera completely disabled.

See Drone machine_params

I followed system requirements about wifi, but it is like wifi does not work

When you are testing a new WiFi USB adapter it might be important to check that the chipset integrated in your adapter is really what you think it is. Indeed, it is a common practice among WiFi adapter brand distributors to change the chipset reference and/or the chipset vendor without changing the reference of their retailed product. Some of them increment a hardware revision number (e.g. A1, A2, B1, etc ..) and print this number on the packaging or on the product itself. If in any doubt you suspect that something is wrong, you can try to obtain more information on the integrated chipset by following the instructions below:

  1. Find your device ID (XXXX:YYYY) in the output of the following command:
$ lsusb
  1. See if there is any useful chipset information (vendor name, reference, …) in the output of the following command:
$ lsusb -vd XXXX:YYYY | head -n 20
  1. Try to check those information against this community database to identify your device hardware reference/revision/driver.