Bitcraze Forums

Posted: **Tue Nov 15, 2016 10:29 pm**

I'm getting started with the LPS and the 6 nodes. I've got the examples working and got one Crazyflie hovering in the air but if was quite jittery. I have a few questions about the setup which hopefully allows me to get a better idea of what's going on.

On the info page on setting up the LPS (link) it's mentioned that the nodes should be "at least 15 cm from the wall or ceiling". How important is this? To put it differently: what's wrong with placing them very close to walls/ceilings? My guess is that it causes strong reflections back to the radio which might contribute to poor tracking of a Crazyflie, but I'd love to hear your take on it.

About the nodes' radio, I was curious if you know what its radiation pattern is. Is it omnidirectional? And does it matter how the nodes are oriented in relation to where the Crazyflie will be tracked? I.e. is it relevant that the node's radio (more or less) faces the Crazyflie?

Thanks!

Posted: **Wed Nov 16, 2016 3:28 pm**

to add to this with a bit visualisation:

(long side is Y-axis and short one the X-axis)

which setup is preferred and is the angle of the anchors significant?

Also, as we did not manage to get multiple CrazieFlie stable...
do the LPS-decks upon the CrazyFlies use the identity of them? Or do the decks have their own identification?
This got speculated when two drones where on and jittered way too much in ROS.. both of them seemed connected to the anchors, one of them was connected to CrazyRadioPA. But when i switched the drone off that was not connected to Radio the other one regained stable positioning in ROS!

Posted: **Thu Nov 17, 2016 1:44 am**

To refrase the current problem in short:
The tracking is going really wild with the multi-drone launch example
whenever there is more then one LPS-deck communicating with the Anchors (with the second not even connecting to Radio).
One drone on alone is doing good in this launch.
It seems like it has nothing to do with ROS or anything coming back to CrazyRadioPA.
Could it be something in the crazyflie-firmware or lps-node-firmware?

Posted: **Thu Nov 17, 2016 9:14 am**

Hi Newk,

For the first questions:
- Putting the anchors at 15cm from radio reflective material causes problems with reflection: The UWB radio are looking at the channel impulse response, they try to detect the time at which the first path reaches the antenna. If the antenna is close to a reflective surface there will be very strong secondary path very close in time to the first path that will make the first path detection noisy and incorrect. That said we have not experimented greatly and have always kept the anchor far from wall and ceiling so I am not sure of the exact loss in performance you are going to get.
- The radiation pattern is not completely omnidirectional, there is power difference and also propagation time difference depending of the orientation. If you avoid flying in the plan of the anchor PC (just in front of the antenna is the worst) and put the anchors around the flying area there should not be too much effect from it.

For flying multiple Crazyflie you need to enable TDMA in the firmware. So far it is very experimental and described in the commit message: https://github.com/bitcraze/crazyflie-f ... 0385d81e23 (you can run TDMA on the master branch with these parameters). What you are describing looks like the behaviour you would get if TDMA is not activated or if the two copter are on the same timeslot.

Best,
Arnaud

Posted: **Thu Nov 17, 2016 11:49 am**

Hi Arnaud,

Thanks for your answers. I was testing with Newk and with the node antenna at about 13mm from the wall we didn't experience a very bad 3d tracking. But having said that I don't have a frame of reference. In any event it's good to know that the nodes should probably not be parallel to the wall because the 'dead zone' of the antenna radiation pattern is then pointing directly into the room, correct?

Posted: **Thu Nov 17, 2016 12:19 pm**

Hi,

For the anchor orientation, parallel to the wall sounds good, it should not be parallel to the ground unless the anchors are at the very bottom and the very top of the room. There seems to be more problems when crossing the plan formed by the node PCB.

Posted: **Wed Nov 23, 2016 1:06 am**

Hi!
We tried the procedure with enabling TDMA in the firmware
the way pointed out in that crazyflie-firmware commit
(compiling each CF with a different slot and setting the number of bits used according to the number of used CF.. in this case, 2bits )

The Anchors we placed in a pattern like in my first picture (in a few posts back) 18 cm from the walls

The system works pretty fine with 2 crazyflie.. but after a 3rd is being turned on that drone fails to find its position.. even when turning off another drone. We specified a third drone in the launchfile and in rviz. The drones position becomes totally random, what could be causing this?

I guess its better to send on the same channel with each its own 5byte adress. Does it matter that these adresses look similar or is it better to have very diffrent adresses?

The Anchors, do they also need extra configuration for using TDMA?

Posted: **Wed Nov 23, 2016 7:39 am**

Hi Newk,

What configuration are you using for TDMA? The number of copter is decided by the TDMA_SLOT_BIT.

Your problem could also come from the launch file, is it the copter with the TDMA_SLOT=2 that causes problems or the 3rd one from ROS (I am trying to figure out where the problem is).

The anchors do not need any modifications to work with TDMA.

Posted: **Wed Nov 23, 2016 12:55 pm**

Hi Arnaud!
thanx for the quick reply.

for first crazyflie (radio://0/15/2M/AAAA00AAAA) i set crazyflie-firmware/tools/make/config.mk :

Code: Select all

## Copy this file to config.mk and modify to get you personal build configuration

## Set CRTP link to E-SKY receiver
# CFLAGS += -DUSE_ESKYLINK

## Redirect the console output to the UART
# CFLAGS += -DDEBUG_PRINT_ON_UART

## Load a deck driver that has no OW memory
# CFLAGS += -DDECK_FORCE=bcBuzzer

## Enable biq quad deck features
# CFLAGS += -DENABLE_BQ_DECK

## Use morse when flashing the LED to indicate that the Crazyflie is calibrated
# CFLAGS += -DCALIBRATED_LED_MORSE

## Turn on monitoring of queue usages
# CFLAGS += -DDEBUG_QUEUE_MONITOR

## Automatically reboot to bootloader before flashing
# CLOAD_CMDS = -w radio://0/100/2M/E7E7E7E7E7

SENSORS = task
ESTIMATOR = kalman

LPS_TDMA_ENABLE=1

CFLAGS += -DTDMA_NSLOTS_BITS=2 -DTDMA_SLOT=0  # first
#CFLAGS += -DTDMA_NSLOTS_BITS=2 -DTDMA_SLOT=1  # second
#CFLAGS += -DTDMA_NSLOTS_BITS=2 -DTDMA_SLOT=2  # third
#CFLAGS += -DTDMA_NSLOTS_BITS=2 -DTDMA_SLOT=3  # fourth

then compiled for the second CF (radio://0/15/2M/FFFF11FFFF) commented-out first CFLAGS and uncommented the next, like so:

Code: Select all

...
#CFLAGS += -DTDMA_NSLOTS_BITS=2 -DTDMA_SLOT=0  # first
CFLAGS += -DTDMA_NSLOTS_BITS=2 -DTDMA_SLOT=1  # second
#CFLAGS += -DTDMA_NSLOTS_BITS=2 -DTDMA_SLOT=2  # third
#CFLAGS += -DTDMA_NSLOTS_BITS=2 -DTDMA_SLOT=3  # fourth

rest of the config is the same. (Yes i did do "make clean" between compiling them)
for the third CF (radio://0/15/2M/E7E7E7E7E7) we used the third line likewise.

the launchfile for executing "roslaunch bitcraze_lps_estimator dwm_loc_ekf_multi_hover.launch"
we edited to look like this:

Code: Select all

<?xml version="1.0"?>
<launch>
  <arg name="uri0" default="radio://0/15/2M/AAAA00AAAA"/>
  <arg name="uri1" default="radio://0/15/2M/FFFF11FFFF"/>
  <arg name="uri2" default="radio://0/15/2M/E7E7E7E7E7"/>

  <arg name="frame" default="base_link" />

  <arg name="joy_dev0" default="/dev/input/js0" />
  <arg name="joy_dev1" default="/dev/input/js0" />
  <arg name="joy_dev2" default="/dev/input/js0" />

  <arg name="x0" default="3.5" />
  <arg name="y0" default="2.17" />
  <arg name="z0" default="1.5" />
  <arg name="x1" default="3.5" />
  <arg name="y1" default="3.17" />
  <arg name="z1" default="1.5" />
  <arg name="x2" default="3.5" />
  <arg name="y2" default="4.17" />
  <arg name="z2" default="1.5" />


  <rosparam command="load" file="$(find bitcraze_lps_estimator)/data/anchor_pos.yaml" />

  <param name="robot_description" command="$(find xacro)/xacro.py $(find crazyflie_description)/urdf/crazyflie2.urdf.xacro" />
  <node name="rviz" pkg="rviz" type="rviz"
        args="-d $(find bitcraze_lps_estimator)/data/rvizconfig_multi_with_goal3.rviz"/>


  <group ns="crazyflie0">
    <rosparam command="load" file="$(find bitcraze_lps_estimator)/data/anchor_pos.yaml" />

    <node pkg="crazyflie_driver" type="crazyflie_add" name="crazyflie_add" output="screen">
      <param name="uri" value="$(arg uri0)" />
      <param name="tf_prefix" value="crazyflie0" />
      <rosparam>
        genericLogTopics: ["log_kfpos"]
        genericLogTopicFrequencies: [30]
        genericLogTopic_log_kfpos_Variables: ["kalman.stateX", "kalman.stateY", "kalman.stateZ"]
      </rosparam>
    </node>

    <node name="joy" pkg="joy" type="joy_node" output="screen">
      <param name="dev" value="$(arg joy_dev0)" />
    </node>

    <node name="joystick_controller" pkg="crazyflie_demo" type="controller.py" output="screen">
      <param name="use_crazyflie_controller" value="True" />
    </node>

    <node name="controller_bridge" pkg="bitcraze_lps_estimator" type="crazyflie_controller_bridge.py" output="screen"/>

    <node name="pose" pkg="crazyflie_demo" type="publish_pose_teleop.py" output="screen">
      <param name="name" value="goal" />
      <param name="rate" value="30" />
      <param name="x" value="$(arg x0)" />
      <param name="y" value="$(arg y0)" />
      <param name="z" value="$(arg z0)" />
    </node>

    <node name="lps_efk_bridge" pkg="bitcraze_lps_estimator" type="lps_ekf_bridge.py" output="screen">
      <param name="tf_prefix" value="crazyflie1" />
    </node>

    <node name="lps_viz" pkg="bitcraze_lps_estimator" type="lps_viz.py" />

  </group>

  <group ns="crazyflie1">
    <rosparam command="load" file="$(find bitcraze_lps_estimator)/data/anchor_pos.yaml" />

    <node pkg="crazyflie_driver" type="crazyflie_add" name="crazyflie_add" output="screen">
      <param name="uri" value="$(arg uri1)" />
      <param name="tf_prefix" value="crazyflie1" />
      <rosparam>
        genericLogTopics: ["log_kfpos"]
        genericLogTopicFrequencies: [30]
        genericLogTopic_log_kfpos_Variables: ["kalman.stateX", "kalman.stateY", "kalman.stateZ"]
      </rosparam>
    </node>

    <node name="joy" pkg="joy" type="joy_node" output="screen">
      <param name="dev" value="$(arg joy_dev1)" />
    </node>

    <node name="joystick_controller" pkg="crazyflie_demo" type="controller.py" output="screen">
      <param name="use_crazyflie_controller" value="True" />
    </node>

    <node name="controller_bridge" pkg="bitcraze_lps_estimator" type="crazyflie_controller_bridge.py" output="screen"/>

    <node name="pose" pkg="crazyflie_demo" type="publish_pose_teleop.py" output="screen">
      <param name="name" value="goal" />
      <param name="rate" value="30" />
      <param name="x" value="$(arg x1)" />
      <param name="y" value="$(arg y1)" />
      <param name="z" value="$(arg z1)" />
    </node>

    <node name="lps_efk_bridge" pkg="bitcraze_lps_estimator" type="lps_ekf_bridge.py" output="screen">
      <param name="tf_prefix" value="crazyflie1" />
    </node>

    <node name="lps_viz" pkg="bitcraze_lps_estimator" type="lps_viz.py" />

  </group>

 <group ns="crazyflie2">
    <rosparam command="load" file="$(find bitcraze_lps_estimator)/data/anchor_pos.yaml" />
  <node pkg="crazyflie_driver" type="crazyflie_add" name="crazyflie_add" output="screen">
      <param name="uri" value="$(arg uri2)" />
      <param name="tf_prefix" value="crazyflie2" />
      <rosparam>
        genericLogTopics: ["log_kfpos"]
        genericLogTopicFrequencies: [30]
        genericLogTopic_log_kfpos_Variables: ["kalman.stateX", "kalman.stateY", "kalman.stateZ"]
      </rosparam>
    </node>
    <node name="joy" pkg="joy" type="joy_node" output="screen">
      <param name="dev" value="$(arg joy_dev2)" />
    </node>

    <node name="joystick_controller" pkg="crazyflie_demo" type="controller.py" output="screen">
      <param name="use_crazyflie_controller" value="True" />
    </node>

    <node name="controller_bridge" pkg="bitcraze_lps_estimator" type="crazyflie_controller_bridge.py" output="screen"/>
 <node name="pose" pkg="crazyflie_demo" type="publish_pose_teleop.py" output="screen">
      <param name="name" value="goal" />
      <param name="rate" value="30" />
      <param name="x" value="$(arg x2)" />
      <param name="y" value="$(arg y2)" />
      <param name="z" value="$(arg z2)" />
    </node>
    <node name="lps_efk_bridge" pkg="bitcraze_lps_estimator" type="lps_ekf_bridge.py" output="screen">
      <param name="tf_prefix" value="crazyflie2" />
    </node>

    <node name="lps_viz" pkg="bitcraze_lps_estimator" type="lps_viz.py" />

  </group>



  <node pkg="tf" type="static_transform_publisher" name="link1_broadcaster"
        args="1 0 0 0 0 0 1 world lps 100" />

  <include file="$(find crazyflie_driver)/launch/crazyflie_server.launch" />
</launch>

(there was a typo found by bombarie in this example file on github, there was crazyflie1 inside of crazyflie0 group, or still is there for that matter)

Anchors set in room like i said in last post, and anchor_pos.yaml edited to match with measurements in the real world.

So... to come back to our observations: when turning on 2 CF everything seems to be stable (enough), no matter which 2... but when a third one is turned on this one can not find its position.. in Rviz you can see it going all over the place between -10 and 10 in all directions.. sometimes it looks like its going to settle for a bit but is easily disturbed by anything.
Even when turning of another CF the positioning will not settle down accordingly.

Maybe we are missing a vital setting that was not pointed out clearly. We could not seem to figure it out yesterday night, so this evening we will give it another shot. Hope you can give insight that would help us make further progress.
Hope i was explicit enough in our configuration, if need more info to help us, please ask

-----

Another question i want to ask (to rule out heavy radio interference) and have clear for us:
CrazyradioPA operate between 2400MHz and 2525MHz (in 126 channels of 1MHz)
Or was this for the first crazyradio and the new one in the 2.4GHz range? As it's specifications on the website do specify 2.4GHz... which is in the range of WiFi... if so, how are the 126 channels subdivided then? Do the transfer rate of 250K/1M/2M influence the broadcast frequency send on too?

And the anchors are operating in 500MHz channels between the 3.2GHz and 7GHz range..
these channels are to be set somewhere in lps-node-firmware? and in crazyflie-firmware for the lps-decks?
(in our test-room there is no 5GHz WiFi, as far as i can see.. but in our final presentation space at Deutsche Telekom there is a strong 5GHz WiFi)

Cheers!

Posted: **Wed Nov 23, 2016 1:50 pm**

First quick comment: if you can swich on any of the Crazyflie it means that the problem is most likely not on the Crazyflie or LPS side but on the ROS side. Your CF configuration looks good.

To avoid too much surprises or noise at startup you can add your anchor positions in the Crazyflie firmware: https://github.com/bitcraze/crazyflie-f ... c#L89-L101.

I did not answer for the address before, you should avoid continuing the preamble (sequences of 0x5555.. or 0xaaaaa) and avoid having few bit change (lots of 000 or ffff). Anything random enough will work fine. The radio datasheet has a paragraph about that.

I will look at the launch file.

---

Crazyradio PA and non-PA uses the same radio chip: the nRF24LU1p. You can look at the datasheet for more precision. The channel are spaced by 1MHz, from 2.4 to 2.525GHz. 2MBit datarate takes 2 channels, 1M and 250K takes 1. For being resilient to wifi/bluetooth we have experienced that 2M is better since it is shorter packets and so it reduces the chance of collision. Since we are sending setpoints, the system could accept quite a lot of packet loss before being noticeable (depending on how often you update your setpoints).

For the DWM we have less experience but it should very resilient to external narrow-band interference. It would be better to test upfront to be sure that the equipment at the presentation are not having too much of an influence. To change the DWM channel you are correct that you will need to change the node and deck driver code.

Bitcraze Forums

A few questions about nodes and placement

A few questions about nodes and placement

Re: A few questions about nodes and placement

Re: A few questions about nodes and placement

Re: A few questions about nodes and placement

Re: A few questions about nodes and placement

Re: A few questions about nodes and placement

Re: A few questions about nodes and placement

Re: A few questions about nodes and placement

Re: A few questions about nodes and placement

Re: A few questions about nodes and placement