lag while logging

Firmware/software/electronics/mechanics
mzhao
Beginner
Posts: 4
Joined: Thu Aug 31, 2017 8:46 am

lag while logging

Post by mzhao »

I'm getting some noticeable lag (on the order of one to a few seconds) while reading log values from the CF.
For example, the motors will turn on on the physical quadcoptor, but the log values will only arrive seconds later.

Obviously, some lag is to be expected, but is there any way to get more real-time data, even if it means sacrificing something like sampling at a slower rate?
kristoffer
Bitcraze
Posts: 630
Joined: Tue Jun 30, 2015 7:47 am

Re: lag while logging

Post by kristoffer »

I assume this question is related to the crazyflie python lib and scripting.

There should not be a noticeable delay. To see the expected performance, set up logging in the client (the plot tab). Since the client is using the library for communicating with the Crazyflie, this is the same performance you should get in your script.

It is hard to give you any advice other than looking at the examples
* asynchronous (this is the way the lib is used in the client) https://github.com/bitcraze/crazyflie-l ... asiclog.py
* synchronous https://github.com/bitcraze/crazyflie-l ... logSync.py

Maybe you have some code to share?
mzhao
Beginner
Posts: 4
Joined: Thu Aug 31, 2017 8:46 am

Re: lag while logging

Post by mzhao »

When I run the basiclog.py using the original firmware, there is no lag in the log, but with my firmware, the log lags a few seconds behind.
The primary differences made in the firmware were to accept external localization and setpoints, along with several additional variables added to the log. Would any of these be likely to cause lag while logging?

Also, it takes a significant amount of time (almost 10 seconds) for the CF to just connect (i.e., the statement "Connected to ..." is printed in basiclog.py) using my firmware. Any idea why that may be happening? I could just revert the modifications I've made and find out by process of elimination, but I thought I'd ask here anyways.

Finally, what's the difference between the synchronous and asynchronous logs?
kristoffer
Bitcraze
Posts: 630
Joined: Tue Jun 30, 2015 7:47 am

Re: lag while logging

Post by kristoffer »

If you are logging a lot of data the bandwidth of the radio might be a problem. Possible solutions is to reduce the amount of logging and alos make sure you connect with a 2M bit connection.

The connection time manly depends on the number of logs and parameters registered in the firmware. When you connect, a Table of Contents is downloaded and this takes some time. There is a caching mechanism in the Crazyflie object that you can use to speed it up. It is not enabled by default in the examples, but by passing in a path in the rw_cache parameter you will store the TOC for next connection (see https://github.com/bitcraze/crazyflie-l ... t__.py#L72)

The asynchronous example uses the basic API with callbacks. Use this when doing things in parallel.
The synchronous example uses the SyncCrazyflie and SyncLogger classes that wraps the asynchronous API to remove the complexity of callbacks. It is handy when writing a script that just loggs a few parameters for a while.
Astrobiologist
Beginner
Posts: 25
Joined: Fri Jan 19, 2018 10:35 pm

Re: lag while logging

Post by Astrobiologist »

Hello
I am new to this forum.
I am having a similar problem with lag, sometimes extreme lag, with the client.
My situation is as follows.
I built the client from scratch on an old Linux laptop (I am not using bitcraze's own VM).
Actual flight is very prompt, the drone is strictly and instantly following my inputs on my controller. So there is no lag at all for the uplink from the client to the drone.
However, there is clearly a big backlog in the downlink back to the client. This in fact extends for several minutes! So for instance, I just flew a full 8 min or so flight to the point of battery exhaustion. The client carried on displaying changes in the flight data (changes in the artificial horizon display, changes in thrust, pitch etc etc) for several minutes after the drone landed! This carried on until the drone was shown stationary and landed, with zero battery, but this was several minutes after the actual event!
During this time the client is actually locked out and I can't disconnect, or even close the client app in Linux! I just have to wait for it to finish.

This laptop is fairly old (AcerOne, dual core 1.6Ghz, 2gb ram, running Ubuntu 16.04 32 bit) so in case it was underpowered, I also tried building the client from scratch in a 64 bit Ubuntu 16.14 VM on my MacBook.
Please note this is not bitcraze's own VM, this is my own Linux VM, running on VMWare Fusion.
On the Mac VM I have exactly the same problem - a considerable downlink lag after completing a flight when data still keeps coming in for some seconds or minutes.
In the Mac's case, the VM is set up as a single 2.7Ghz i7 core with 3Gb of memory. To my untrained eye, this doesn't seem underpowered.

You might ask: why am I not using bitcraze's own VM?
The answer is, I tried it but it doesn't seem to support the Flow Deck in the client, not even after clicking on the "update all projects" link. For instance there is no hover mode.
So, that is why I tried building the client from scratch, as well as the FlowDeck python libraries etc (there were no problems doing this and I can use MC Commander etc in Idle3 with no trouble)

I run a VM on the Mac, instead of building the client directly on the Mac, because there are no Flow Deck python library installation instructions for Macs and indeed the client install instructions for Macs say you could break other Python applications installing the client directly on MacOS.

Anyway, I am seeing the same massive downlink lag on two different computers and client installations.
The 2M bit connection option is not showing up when I scan for connections, on either computer.

The other suggestions in previous posts go over my head I'm afraid. I was just trying to get the client to work and buzz the drone around my room a bit with a cheap PS3 controller. I have never coded in Python before either, other than running the MC Commander examples for the drone!

Please advise
Many thanks in advance

Oliver
(Astrobiologist)
Proud CrazyFlie2 aviator since Jan 9th 2018
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: lag while logging

Post by arnaud »

Hi,
One reason might be that the radio channel has some interference that causes this delay. You can change the channel and datarate using the "configure 2.0" menu: https://wiki.bitcraze.io/doc:crazyflie: ... figuration

The virtual machine should work for the flow, if it doesn't it is a bug, we will look at it.
Astrobiologist
Beginner
Posts: 25
Joined: Fri Jan 19, 2018 10:35 pm

Re: lag while logging

Post by Astrobiologist »

Thanks for your reply.
I tested it with the higher data link rate (2M) yesterday as you suggested.
However, this didn't improve the problem - there was still an extremely long backlog on the downlink - once again, many minutes after landing.
How is the downlink queued please? Is it basically all downloaded to the client, queued in the order in which it arrived, and then played back in the client (e.g in terms of artificial horizon movements and other parameters reported)?
Is there any way to dial back the reporting frequency of the downlinked parameters?
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: lag while logging

Post by arnaud »

This sounds like your computer is too slow for the client, which is strange for the mac i7. have you tried to run the client directly on the mac? If you have a recent version of python (python >= 3.5), the client can simply be pip installed with 'pip install cfclient'.

There is no easy way to dial back the reporting frequency since it is set independently for each log block. You can disable all the log blocks in the log block tab and re-enable only a subset to see if it helps.

I am suspecting a graphical problem since we have seen that a very long time ago with slow machines, the attitude indicator (artificial horizon) on the flight tab can take some resources. Disabling the log-blocks will also stop the attitude indicator from re-painting. Closing the flight tab will also help if this is the problem.
Astrobiologist
Beginner
Posts: 25
Joined: Fri Jan 19, 2018 10:35 pm

Re: lag while logging

Post by Astrobiologist »

Thanks for getting back to me.

I was not intending to install the client directly on the Mac because I want to use the flow deck python commands, and there are only installation instructions for that for Windows or Ubuntu *.
So I was assuming I would use a VM.

If it is possible to install the flow deck libraries on a Mac, then please could you give me some pointers.

From your website so far, installing the client seems more longwinded than just pip install cfclient, so I would like to make sure I am doing it right. This is the order of commands I am typically typing to set up the client and the libraries for the flow deck from scratch on a fresh Ubuntu installation (e.g as a VM or on an actual spare laptop):

sudo apt install git
git clone https://github.com/bitcraze/crazyflie-clients-python
sudo apt-get install python3 python3-pip python3-pyqt5
Then, from inside the folder established by the git clone:

pip3 install -e .

To launch the GUI application in the source folder type:python3 bin/cfclient
And then lock it to to the launcher for later use.

For the flow deck:

sudo apt-get install python3 python3-pip python3-usb idle3
(Although presumably of course I have already installed the first two of these above)

pip3 install cflib

For the CrazyFlie PA:

sudo groupadd plugdev
sudo usermod -a -G plugdev $USER
echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="1915", ATTRS{idProduct}=="7777", MODE="0664", GROUP="plugdev"' | sudo tee /etc/udev/rules.d/99-crazyradio.rules

Will this all work on MacOS?

I have a more recent, faster MacOS laptop with more cores, given to me by my employer. However I would almost certainly have to use a VM with that one since it is not mine to experiment with! :-)

Any advice gratefully received

Thanks


* https://www.bitcraze.io/getting-started ... ne-bundle/
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: lag while logging

Post by arnaud »

Hi,

The client situation is changing quick-ish lately.

The documentation was not done for mac partially because of time constrain but mostly because the situation of mac was a bit unclear: I would love to be able to run on mac without requiring mac-brew but we are just missing sdl2 for it to work. So for now to get the graphical client to work on Mac you will need to follow the mac-brew instructions (ie. at least python3, pyqt5 and pysdl2 need to be installed with brew). Sorry, my previous comment was a bit misleading.

What you copied for Linux looks correct.

For MacOS, you will not need the udev rules. The rest should be quite similar (with brew instead of apt-get of course).

Have you tried to run the flow scripts to see if you have the same delay problems?

Also a random though: if the problem is graphical, it could be caused by the VM. Have you installed the guest additions in your VM?
Post Reply