Crazyflie shutdown while running about crazyflie_ros HOT 10 CLOSED

I've only seen that if the controller is used (and not properly configured using the yaml file). How does your launch file look like? I did test it using the const_thrust.py script (https://github.com/whoenig/crazyflie_ros/blob/master/crazyflie_demo/scripts/const_thrust.py), however there is no demo launch file included at the moment.

from crazyflie_ros.

I've only worked with turtlebot before thus I didn't have a launch file. I created a package and ran it as a test file. I did pid control with pressure and imu data to try to make the drone hover. I first launched crazyflie_server.launch and then added my crazyflie with crazyflie_add.launch, and then i ran the executable i wrote. Is this caused by different update time maybe?

from crazyflie_ros.

The approach sounds reasonable. As a third step, try running const_thrust.py (from my previous post) instead of your custom node to check if it is an issue with the crazyflie_driver. The driver sends a setpoint command every time it receives a cmd_vel message (https://github.com/whoenig/crazyflie_ros/blob/master/crazyflie_driver/src/crazyflie_server.cpp#L158). You want to make sure that your update frequency is high enough, but not too high (something between 30 and 100 times per second). You can use rostopic echo /cmd_vel to check whether your custom node actually sends enough messages to the driver.

from crazyflie_ros.

I tried to run the constant thrust file and it worked the first time. I tried to modified the thrust input to a larger number say 38000 and 40000, it showed the same problem i had. I changed it back to 12000 and i had to specify the queue_size when declaring the publisher to make it work again. But a higher thrust input with the queue_size specified still doesn't work.

from crazyflie_ros.

There is no logic in the ROS driver for handling the thrust differently, so I think that is rather an issue somewhere else.
a) Which firmware are you running?
b) If you use the Bitcraze python SDK and use ramp.py (https://github.com/bitcraze/crazyflie-clients-python/blob/develop/examples/ramp.py), changed such that you send a constant thrust of 40000 rather than ramping up -- does that work?

I am not sure why you where seeing issues with the queue_size. There might be a warning, however if it is not specified it should go into blocking mode (i.e. wait until the message was received by the crazyflie_driver). If that wait does not return, that means that there is some communication issue between the nodes (see http://wiki.ros.org/rospy/Overview/Publishers%20and%20Subscribers#queue_size:_publish.28.29_behavior_and_queuing).

c) Are you running everything on the same machine? Is it a native installation or VM?
d) Which ROS version are you testing on?

from crazyflie_ros.

I did some testing and it seems like initially the pressure data will be null and when it starts reading the data the crazyflie will just shut down. I've tried multiple ros looprate and the same thing happens. Even echoing the pressure topic will cause the crazyflie to shut down.
I'm running everything on native installation of Ubuntu 14.04 and hydro.

from crazyflie_ros.

Does it work if you run crazyflie_add.launch with enable_logging set to False? I didn't test on hydro, but I doubt that this will be a problem. Do you run on x86 architecture or ARM? ARM is untested and there might be some issues with the endianess.

from crazyflie_ros.

The connection between ros and crazyflie wouldn't establish with enable_logging set to False. I'm running on x86.

from crazyflie_ros.

How do you know that the connection doesn't work? Reading sensor data such as pressure wouldn't work, however you should be able to send thrust commands.

from crazyflie_ros.

I decided to get rid of everything related to the pressure node and I restarted everything. It seems to be working perfectly fine now! Thanks a lot for your help. I'll let you know if there's any further questions!

from crazyflie_ros.