libcflie: communication stop after some seconds

[ein-stein]

Hi,

I tried to compile the libcflie sources with success in Bitcraze VM 0.5.
If I start the example programms like ex-gui the program start communicating with the copter, the parameters are printed, the thrust is set and the pane is displayed and following the gyro. But after about 1 or 2 seconds the communication seems to be broken and the propellers stop turning. Also the pane is not actualizing.
In the original GUI all is working well.

Does anyone have the same problem? is htere a special dependency on a firmware version?

Regards
Christian

[Fr4nky]

Hi,

I also have the same problem.
The Python-client works perfectly fine but when I test the "simple" example of libcflie (I added printing accX) the values stop changing after 0.5s or so and 1-2s after that the motors stop.
I tried different channels and data rates but it did not help, so a packet collision (with WiFi) seems unlikely.
I am in contact with the developer of libcflie (fairlight1337 on the forum) but so far no solution has been found.
He suggested to flash the firmware to the Crazyflie again. It didn't help in my case but maybe you want to try it?

Regards
Daniel

EDIT 1: I also wanted to try a similar program written in Python but the example programs from github seem to be out-of-date (they don't work, several names seem to have changed). Where can i download new versions?
EDIT 2: Just as I wrote EDIT I found this thread:
http://forum.bitcraze.se/viewtopic.php?f=6&t=883
I removed the Alt-Hold part and the parameter of init_drivers and added send_setpoint to the while-loop and the motors keep running as they should.
So it seems like libcflie is in fact the cause of the issues.
This is the code I tested with:

Code: Select all

import sys
sys.path.append("../lib")

import cflib.crtp
import time
from cflib.crazyflie import Crazyflie

# Initialize the low-level drivers (don't list the debug drivers)
cflib.crtp.init_drivers()

print "Scanning interfaces for Crazyflies..."
available = cflib.crtp.scan_interfaces()
print "Crazyflies found:"
for i in available:
    print i[0]

if len(available) > 0:
    # Create a Crazyflie object without specifying any cache dirs
    cf = Crazyflie()

    def handle_connected(link_uri):
        print "Connected to %s" % link_uri
        print "Sending thrust 11000"
        cf.commander.send_setpoint(0, 0, 0, 11000)

    def close_link():
        print 'Closing'
        cf.commander.send_setpoint(0, 0, 0, 0)
        time.sleep(0.1)
        cf.close_link()

    # Connect some callbacks from the Crazyflie API
    cf.connected.add_callback(handle_connected)

    link_uri = available[0][0]
    print "Connecting to %s" % link_uri

    # Try to connect to the Crazyflie
    cf.open_link(link_uri)

    # Variable used to keep main loop occupied until disconnect
    is_connected = True

    try:
        while True:
            time.sleep(0.2)
            cf.commander.send_setpoint(0, 0, 0, 11000)
    except KeyboardInterrupt:
        close_link()
else:
    print "No Crazyflies found, cannot run example"

[Fr4nky]

Hi, it's me again

I think I found the problem.

In order to determine when to send the setpoints in the cycle()-function it is checked if a minimum amount of time has passed since the last sending of the set-points:
From CCrazyflie.cpp (the cout-commands were added by me for debugging)

Code: Select all

  case STATE_NORMAL_OPERATION: {
    // Shove over the sensor readings from the radio to the Logs TOC.
    m_tocLogs->processPackets(m_crRadio->popLoggingPackets());
    
    if(m_bSendsSetpoints) {
      // Check if it's time to send the setpoint
      cout<<"check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: "<<dTimeNow-m_dSetpointLastSent<<" m_dSendSetpointPeriod: "<<m_dSendSetpointPeriod<<endl;
      if(dTimeNow - m_dSetpointLastSent > m_dSendSetpointPeriod) {
      	// Send the current set point based on the previous calculations
        cout<<"sendSetpoint"<<endl;
      	this->sendSetpoint(m_fRoll, m_fPitch, m_fYaw, m_nThrust);
      	m_dSetpointLastSent = dTimeNow;
      }
    } else {
      // Send a dummy packet for keepalive
      cout<<"sendDummyPacket"<<endl;
      m_crRadio->sendDummyPacket();
    }
  } break;

dTimeNow is calculated by the following function (called as: double dTimeNow = this->currentTime(); at the beginning of cycle()) also in CCrazyflie.cpp:

Code: Select all

double CCrazyflie::currentTime() {
  struct timeval tv;
  gettimeofday(&tv, NULL);
  
  return (tv.tv_sec + tv.tv_usec) / 1000000.0;
}

And there is the mistake in the last line (probably introduced with the commit on Feb 3). The last line should instead be:

Code: Select all

  return (tv.tv_sec + tv.tv_usec / 1000000.0);

Now the time calculation works and the numbers make sense, leading to the setpoints being sent in regular intervals avoiding a connection loss (And thus the motors keep spinning and the numbers changing as they should).

There is one more interesting thing I noticed. This is the output I get from the cout's:

Code: Select all

check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00431609 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00433898 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00436091 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00438213 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00440407 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00442505 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00444698 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00446796 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00448895 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.0307779 m_dSendSetpointPeriod: 0.01
sendSetpoint
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.0015111 m_dSendSetpointPeriod: 0.01
check time for sendSetpoint.   dTimeNow-m_dSetpointLastSent: 0.00157404 m_dSendSetpointPeriod: 0.01

The time difference is slowly increasing but then suddenly jumps over the limit. This happens every time. Does someone know why that happens?

Regards
Daniel

EDIT: typo in the code
EDIT 2: the mistake was removed in the git repo

[tobias]

Great that you found and solved it!

[garethdicker]

Hi, I'm having the issue that I run ex-gui or any of the examples and the gui opens up but no data is displayed.

I was having the terminal show USB timeout which I found is a LIBUSB_ERROR_TIMEOUT trigger, but I'm not sure if this is fixed.

At any rate, I don't get any data showing up on the left hand side of the gui. Anyone know why this could be?

[nurp]

I am also having USB timeout problem. I was hoping to see this working

update: mine worked finally! I set the correct address such as: radio://0/80/250K