Tuning of drone internals at runtime - Howtos

How to emulate network packet loss ?

sphinx exposes iplink components to control firmware network QoS at runtime. For each network interface of a firmware, sphinx creates an <interface_name>/iplink component with the following runtime parameters for both ingress and egress traffic:

  • percentage of lost packets: in_loss_percent and out_loss_percent
  • percentage of corrupted packets: in_corrupt_percent and out_corrupt_percent
  • packet transmission delay in milliseconds: ìn_delay_ms and out_delay_ms
  • packet transimision delay variation in milliseconds in_delay_variation_ms and out_delay_variation_ms

To disable all communications of an interface, just set a 100% packet loss for both ingress and egress traffic for this interface.

Typically a drone has two available network interfaces:
  • eth0: the drone wifi access point interface
  • eth1: the drone virtual ethernet interface accessible at 10.202.0.1 from the host

See interface and stolen_interface elements in the drone section of your .drone file (Anatomy of a ‘.drone’ file) to get the actual names of your drone net interfaces.

How to play with wind ?

Pretty simple.

If not already present, add the wind plugin in your world file. The lines below need to be located AFTER the plugin fwman. Otherwise, the controls via JSON-RPC will not be available.

<plugin name="fwman" filename="libsphinx_fwman.so">
  ....
  ....
</plugin>

<!-- Load the plugin for the wind -->
<plugin name="wind" filename="libsphinx_wind.so">

  <!-- Wind mean speed in m/s -->
  <magnitude_mean>0.0</magnitude_mean>
  <!-- Wind mean direction in decimal degrees -->
  <direction_mean>0.0</direction_mean>
  <!-- Wind mean elevation in decimal degrees -->
  <elevation_mean>0.0</elevation_mean>

  <!-- Lowpass filter time characteristics in seconds.
       A value of 0 seconds deactivate the filter. -->
  <magnitude_time_for_rise>10.0</magnitude_time_for_rise>
  <direction_time_for_rise>30.0</direction_time_for_rise>
  <elevation_time_for_rise>0.0</elevation_time_for_rise>

  <!-- Wind expressions where "val" is the mean value. -->
  <!-- Example: The following defines an horizontal sinusoidal wind with
       an orientation that turns 360° every 60 seconds. Note that the mean
       direction and mean elevation are unused. -->
  <magnitude_expr>val*(1+0.05*sin(2*pi*time/15))</magnitude_expr>
  <direction_expr>360*time/60</direction_expr>
  <elevation_expr>0.03*noise()</elevation_expr>
</plugin>

Now, you can start a simulation. Then, use either the web interface or the command line in order to change wind properties at runtime. Note that the wind plugin is NOT attached to any drone. Therefore, it belongs by default to a drone called world.

For example, to set the speed mean to 5.0 m/s:

echo '{"jsonrpc": "2.0", "method": "SetParameter", \
"params": {"machine":"world", "object":"wind/wind", "parameter":"magnitude_mean", "value":"5.0"}, "id": 1}'\
 | nc -U <path/to/unix/socket> | python -m json.tool

How to modify runtime parameters before firmware startup ?

This section shows how to set up runtime parameters before the firmware starts up. This way, we can check the firmware initialization with custom parameter values.

First, you need to start sphinx with the -U (--pause-firmware) option.

sphinx -U empty.world

Once sphinx is started, all runtime parameters are accessible and can be modified even though the firmware is waiting to be launched.

Finally, you just have to start your firmware by sending the start_firmwares action, located in world/fwman/fwman/actions. This can be achieved either from the web interface, or using the command line:

echo '{"jsonrpc": "2.0", "method": "TriggerAction", "params":\
{"machine":"world", "object":"fwman/fwman", "action":"start_firmwares"},\
"id": 1}' | curl -d @- http://localhost:<port> | python -m json.tool