Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CF Ignores some of the high-level commands #140

Open
tugayalperen opened this issue May 17, 2019 · 8 comments

Comments

Projects
None yet
3 participants
@tugayalperen
Copy link

commented May 17, 2019

Hi all,

I was doing repetative tests to make sure our Crazyflie 2.1's stability is okay. The test I was doing is simply using a script so much like test_high_level.py, with 2 CF takeoff-go 2m forward relatively-land and backwards and forwards again... The thing I faced is this, after 15-20 trials, one of the CFs ignores a command such that it does not takeoff, does not land or does not go forward. If I try again, everything works fine. Also I have no warning about link quality issue and I use 2 Crazyradio PA for 2 CFs.

I have tried with latest firmwares for stm32, nrf51, crazyradio PA in addition to release verisons of them. When they are flying, stability is perfectly okay. Only problem is that ignoring behaviour.

@whoenig

This comment has been minimized.

Copy link
Owner

commented May 17, 2019

Could you share your test script? If you use broadcasts for takeoff, then there could have been simply a packet loss. In the crazyswarm, we greatly reduce the probability of this happening by repeating broadcast commands at least 10 times.

@tugayalperen

This comment has been minimized.

Copy link
Author

commented May 19, 2019

`#!/usr/bin/env python

import rospy
import crazyflie
import time
import uav_trajectory

if name == 'main':
rospy.init_node('test_high_level')

cf1 = crazyflie.Crazyflie("cf1", "/cf1")
cf2 = crazyflie.Crazyflie("cf2", "/cf2")

cf1.setParam("stabilizer/estimator", 2) # Use EKF
cf1.setParam("stabilizer/controller", 2) # Use mellinger controller

cf2.setParam("stabilizer/estimator", 2) # Use EKF
cf2.setParam("stabilizer/controller", 2) # Use mellinger controller

cf1.setParam("commander/enHighLevel", 1)
cf2.setParam("commander/enHighLevel", 1)

cf1.setParam("kalman/resetEstimation", 1)
cf2.setParam("kalman/resetEstimation", 1)

time.sleep(2.0)

cf2.takeoff(targetHeight = 0.7, duration = 5.0)
cf1.takeoff(targetHeight = 0.7, duration = 5.0)

time.sleep(6.0)

cf2.goTo(goal = [2.0, 0.0, 0.0], yaw=0.0, duration = 10, relative = True)
cf1.goTo(goal = [2.0, 0.0, 0.0], yaw=0.0, duration = 10, relative = True)

time.sleep(10.0)


cf2.land(targetHeight = 0.03, duration = 3.0)
cf1.land(targetHeight = 0.03, duration = 3.0)
time.sleep(3.0)

cf2.stop()
cf1.stop()

`
I want to ask that what are you repeating 10 times? Is it something you did between high-level commands and crtp packages or you have just repeated "cf1.goTo(..)" command 10 times? I guess everytime this function called, cf calculates a trajectory for that travel. Wouldn't this be a problem for crazyflie computationally to calculate that trajectory in a short time?

@tugayalperen

This comment has been minimized.

Copy link
Author

commented May 19, 2019

I don't know if you meant the method I have used below or not, but I tried it and with more than 30 trials, there was no missing command. But still I would like to know if there is any side effect of doing so.
`
#!/usr/bin/env python

import rospy
import crazyflie
import time
import uav_trajectory

if name == 'main':
rospy.init_node('test_high_level')

cf1 = crazyflie.Crazyflie("cf1", "/cf1")
cf2 = crazyflie.Crazyflie("cf2", "/cf2")

cf1.setParam("stabilizer/estimator", 2) # Use EKF
cf1.setParam("stabilizer/controller", 2) # Use mellinger controller

cf2.setParam("stabilizer/estimator", 2) # Use EKF
cf2.setParam("stabilizer/controller", 2) # Use mellinger controller

cf1.setParam("commander/enHighLevel", 1)
cf2.setParam("commander/enHighLevel", 1)

cf1.setParam("kalman/resetEstimation", 1)
cf2.setParam("kalman/resetEstimation", 1)

time.sleep(2.0)

cf2.takeoff(targetHeight = 0.7, duration = 5.0)
cf2.takeoff(targetHeight = 0.7, duration = 5.0)
cf2.takeoff(targetHeight = 0.7, duration = 5.0)
cf1.takeoff(targetHeight = 0.7, duration = 5.0)
cf1.takeoff(targetHeight = 0.7, duration = 5.0)
cf1.takeoff(targetHeight = 0.7, duration = 5.0)

time.sleep(6.0)

cf2.goTo(goal = [2.0, 0.0, 0.0], yaw=0.0, duration = 10, relative = True)
cf2.goTo(goal = [2.0, 0.0, 0.0], yaw=0.0, duration = 10, relative = True)
cf2.goTo(goal = [2.0, 0.0, 0.0], yaw=0.0, duration = 10, relative = True)
cf1.goTo(goal = [2.0, 0.0, 0.0], yaw=0.0, duration = 10, relative = True)
cf1.goTo(goal = [2.0, 0.0, 0.0], yaw=0.0, duration = 10, relative = True)
cf1.goTo(goal = [2.0, 0.0, 0.0], yaw=0.0, duration = 10, relative = True)

time.sleep(10.0)


cf2.land(targetHeight = 0.03, duration = 3.0)
cf2.land(targetHeight = 0.03, duration = 3.0)
cf2.land(targetHeight = 0.03, duration = 3.0)
cf1.land(targetHeight = 0.03, duration = 3.0)
cf1.land(targetHeight = 0.03, duration = 3.0)
cf1.land(targetHeight = 0.03, duration = 3.0)
cf1.land(targetHeight = 0.03, duration = 3.0)
time.sleep(3.0)

cf2.stop()
cf1.stop()

`

@whoenig

This comment has been minimized.

Copy link
Owner

commented May 20, 2019

Your script does not use broadcasts, so your first version of the script should have worked without issues. All the commands are direct communication commands, that are resend until an acknowledgement is received (https://github.com/whoenig/crazyflie_cpp/blob/master/src/Crazyflie.cpp#L1324-L1346). I think in principle it might be possible that an acknowledgement is sent in the NRF firmware, but the packet later on gets lost (because of full queues?) in the STM firmware. See also https://forum.bitcraze.io/viewtopic.php?f=11&t=3507.

@tugayalperen

This comment has been minimized.

Copy link
Author

commented May 20, 2019

The forum post that you have sent is also my post so I am waiting for another aspect from Bitcraze itself. Do you have any idea what can produce that loss? I can state that I see this problem especially when I use more than one crazyradio PA to communicate with multiple cfs, such that one radio for one crazyflie. I have tried with 3 cf at most until now.

@whoenig

This comment has been minimized.

Copy link
Owner

commented May 20, 2019

I posted in the forum to see if Bitcraze has some idea. I think there might be places in the firmware where packets can get lost. Your observation with multiple CF might only be related to the probability of it occurring, if you assigned unique addresses to each CF (if you have multiple, it is more likely to see at least one CF showing an issue.)

@tugayalperen

This comment has been minimized.

Copy link
Author

commented May 20, 2019

I guess you are right about probability aspect. I assigned different addresses and channels at 2M data rate to avoid a possible loss, in addition to killing all 2.4Ghz transmitters nearby.

@wydmynd

This comment has been minimized.

Copy link

commented May 22, 2019

I experienced the same issue, my solution was to use absolute coordinates (relative=False) and re-issue the cf.goto at 2 hz (twice per second) . this way the re-issuing of the commands does not alter the course.

also , if you can afford, upgrade to cf 2.1 , much better radio performance

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.