Closed ng4mf closed 4 years ago
This could be a regression, since I do not frequently test crazyflie_ros by itself but mostly when used in conjunction with the Crazyswarm. Is there a particular reason why you want to use crazyflie_ros over the Crazyswarm?
Thanks for the quick reply!
I'm working on a system that was developed solely with crazyflie_ros as a dependency (as opposed to also using Crazyswarm). I know the two repos are being merged, but I'm somewhat new to both and wasn't sure how much I'd need to change to integrate Crazyswarm, so I was trying to run things in my local copy of the project while making as few changes as possible.
I'll try an older copy of crazyflie_ros to see if that runs, and if not I'll switch to using in conjunction with Crazyswarm. Either way, I'll post what I find out.
If I roll back to commit 1cbd932f533cb917b4008a56183f53b2abce0db0 (April 27, 2018), the issue is not present. I haven't tried commits further in the future, so I can't say whether this is the place where the regression happened, but it is sometime after this commit that it does.
A friend was able to use commit 4859db0f1d713e2ee4bd4c08166ba5a060ec20a8, which is the Aug 30, 2020 commit. I didn't try this commit out myself as I'd gotten it running using the older one by this time, but perhaps the issue was resolved with one of the changes in yesterday's commit.
Thanks for the update! The Aug 30 commit shouldn't have changed anything with respect to this issue, but perhaps some prior change did. Should we close this issue then or is there anything else you'd need from my side?
Hm, the issue has cropped again occasionally. This might just be unfamiliarity with how things are working internally, but could it be that the takeoff service as defined in crazyflie_server is conflicting with how it's defined in crazyflie_controller/src/controller.cpp? Since one definition uses Empty and the other uses, e.g., Takeoff, the md5sums would would be different for the two services and the names would be the same.
As for why it occurs sometimes and not others, my best guess at the moment is that it has something to do with the non-guaranteed node start order in ROS.
I think what I said above just might be the issue. I've pretty consistently been getting the md5sum error today, so I tried commenting out the takeoff and land service advertising in crazyflie_server and ran catkin_make. On the next launch of hover_vicon.launch, takeoff was working again.
Great finding! The controller itself is actually deprecated, since it is now recommended to use the on-board controllers (which are more sophisticated in the first place). I only kept it around as a (bad) example, but also didn't test it for a long time because I personally don't use it.
Ah, got it - thank you! I guess we'll be wanting to do a migration on our side at some point then.
Hi,
I've recently been working on using teleop_xbox360.launch and hover_vicon.launch to run. In both cases, the ServiceProxy calls in controller.py (in crazyflie_demo) cause md5sum errors
self._land = rospy.ServiceProxy('land', Empty)
self._takeoff = rospy.ServiceProxy('takeoff', Empty)
These get resolved when I swap out Empty with actual Takeoff and Land services (after I added the corresponding imports). However, even though there is no error, no takeoff/land actually gets triggered.
I also tried passing arguments for groupMask, height, and duration for the Vicon test (setting group mask to 1), but in that case I get some kind of serialization error, so I switched back to calling no-args self._takeoff() and self._land() (but with the Empty argument in the ServiceProxy call still swapped with Takeoff and Land).
I've tried with Ubuntu 20.04 / Noetic and Ubuntu 18.04 / Melodic (latter in a VM) and gotten the same issues. I've tried a couple of different versions of the firmware for both the Crazyradio PA and the Crazyflie itself. I saw in other posts that this could be due to ROS version mismatches, but in each case I was running a single installation of ROS on the OS. There is a conda setup for the Ubuntu 20 setup, but no virtual environment in the Ubuntu 18 one.
I can get the CF2 to fly using just the axes in teleop mode, but the button triggers don't seem to take effect. I also am able to send cmd_vel messages in a separate script, but nothing I've tried for Takeoff and Land seem to be working.
Is this possible due to some underlying change or am I just missing something simple? I changed some stuff in the VICON launch files and scripts to match what I needed, but the teleop-relevant files are unchanged barring what I wrote above about controller.py.