Second connect to Roadrunner hangs using USB

[BeyersBots]

Description

I seem to be experiencing the same as crazyflie-clients-python/Issue #350 on the Roadrunner using the latest firmware as of 6 Mar 2020. This issue is also similar to crazyflie-firmware/Issue #393, but I cannot connect to the Roadrunner on subsequent executions of the basiclog.py script. Not sure if it is a crazyflie-lib-python issue or a crazyflie-firmware issue.

How to reproduce

1. Connect Roadrunner to USB and boot it.
2. Run the https://github.com/bitcraze/crazyflie-lib-python/blob/0.1.7/examples/basiclog.py script and let it complete (do not press CTRL+C).
3. Attempt to rerun the basiclog.py script.

Expected result:
A clean connection and running of the basiclog.py script again.

Observed result:
Works great the first time and occasionally on subsequent attempts. But it appears sometimes the rr.close_link() will close the link and then cannot open the link in subsequent connections. I see this issue with any script and first found it when running with ROS.

Typically get the following from the log file:
WARNING:cflib.crazyflie.log:Error no LogEntry to handle id=2
WARNING:cflib.crazyflie.log:Error no LogEntry to handle id=3
WARNING:cflib.crazyflie.log:Error no LogEntry to handle id=4

Versions

All SW/Firmware is latest and greatest from git repos as of 6 Mar 2020.

Hardware/OS

Roadrunner
Raspbian Stretch/Python 3.5.3

[BeyersBots]

@knmcguire thank you for the quick response on the other repo. After more investigation, this is definitely not a ROS issue, and may be a logging/USB issue. Looking into it more.

[knmcguire]

Thanks, give us an update!

Currently we are working from home so I don't have a roadrunner lying around at moment, but this should might also happen on a Crazyflie. I guess you don't have a CF at home yourself?

[BeyersBots]

I had one of my students try it with the crazyflie and we experience the same issue. Therefore, it is exactly like crazyflie-clients-python/Issue #350. Sometimes I can run the script a few times and it works, but it eventually hangs up on connection. Is there a good method to stop and remove the logs before closing the connection? Any examples of this?

[BeyersBots]

Updated the code a bit to enable us to stop and delete log blocks. This did not help.

log_pos.stop()
log_stab_att.stop()
log_pos.delete()
log_stab_att.delete()
rr.close_link()

[knmcguire]

Hi!

I tried the basiclog.py 10 times with a crazyflie, and it always connect and logs without problem while connected to usb://0. Here are a couple of pointers that are a bit confusing to me:

• The example in the first post of this issue, shows that you are using the 0.1.7 version of the basiclog.py. Is this just a copy past error?
• I don't recognize anything in the basiclog.py about rr.close_link and such, also is there no ROS integration in the examples of this repository. Are you sure that you are looking at the same script as this? https://github.com/bitcraze/crazyflie-lib-python/blob/master/examples/basiclog.py

Could you please try the above script, a complete new clean version updated to master without integrating any ROS functions?

[BeyersBots]

@knmcguire, sorry for the confusion! I am testing multiple different scripts. So let me be clear as to what I have done today: I cloned the entire crazyflie-lib-python library into a new folder. Connected a crazyflie2.0 with the latest firmware (release 2020.02). Ran the basiclog.py script without any ROS integration. Works about 6-10 times. Then no readings from the crazyflie and then no connection can be made and it just hangs up. I repeated this method with the Roadrunner and same thing occurs just more frequently (will only run 1-2 times before unable to connect).

[BeyersBots]

Ok, new information: I repeated everything above on a laptop running Ubuntu 16.04.6 LTS and no hang up at all. Ran 36+ times on both the Crazyflie and Roadrunner. So more information about the Raspberry Pi we are running:
RaspberryPi 3B+, Raspbian GNU/Linux 9.8 (stretch) which is a form of Debian, Kernel is Linux 4.19.36-v7+, arm architecture.
I will investigate moving to a different image for the RaspberryPi.

[knmcguire]

Was the previous computer still 14.04 ? We should probably add this to the readme so that users will know it, but since 14.04 is not supported by ubuntu anymore, we probably will not fix this issue.

Btw, are you aware that since of recently we got support for serial communication with CRTP through this pull request? #140. those who implemented this also did this since they wanted to connect to it through a raspberry pi. Might be a good alternative instead of using usb

[BeyersBots]

@knmcguire I will check out the serial communication. I have tested using the Roadrunner with the Raspberry Pi 3B+ with the following:
Raspbian GNU/Linux9.8 (stretch) with Linux 4.19.36
Raspbian GNU/Linux10 (buster) with Linux 4.19.36
Ubuntu 16.04.6 LTS (Xenial Xerus) with Linux 4.19.50

All three have had the same hang up with USB issue. So it appears to me to be a Raspberry Pi issue and not an OS issue. Next up is to try out the serial connection. Thanks again for all of the help and ideas!

[knmcguire]

Ahh okay, Thanks for checking it out.

Probably that is the reason why the others of the pull request settled for serial instead. So give it a try and if you want me to connect them with you let me know.

In the mean time, since this is not a problem of this lib apparently, I will close this issue for now.

[BeyersBots]

@knmcguire I am not having much luck with the UART and am curious if you had any guidance for implementing this. What I have done so far is update the firmware to include the CFLAGS += -DUART2_LINK_COMM enabled in the config.mk and reflashed the Roadrunner. Made sure I had the latest version of crazyflie-lib-python, enabled the serial port on the Raspberry Pi, and then ran the basiclog.py. It gets to the point of "Connecting to serial://ttyAMA0" and sits there. I'm not sure if there is anything else I need to do in the process. Thanks again for all of your help.

[knmcguire]

Just as a reference for others, the uart issue has been fixed in this thread here #140