Crazyflie 2.1 firmware flashing error #162
Comments
|
Which firmware are you trying to flash? The latest firmware images are compatible with 2.0 and 2.1. I recommend flashing either using crazyflie_tools flash or JTAG (with make flash), as the "make cload" tool does not verify if the image was flashed correctly. You should also take a look at the console output (using crazyflie_tools console, or the cfclient) to see if there are any details on what self test is failing. |
|
Hi, |
|
Which launch file are you using? I am not aware of a particular firmware problem that would cause this problem, but I mostly test with the high-level mode (and onboard position controllers). |
|
Hi, |
|
For new projects I don't recommend using the off-board position controller. Instead, use the onboard (PID or mellinger) controllers. One thing I noticed is that you use 3 CFs with 1 radio, and you also leave the logging enabled for all CFs. I don't think the radio has actually enough bandwidth to send control signals and receive the data from the drones. Since you are trying to fly multiple CFs, did you try using the Crazyswarm? The latest version works with the regular official firmware. Otherwise, take a look at https://github.com/whoenig/crazyflie_ros/blob/master/crazyflie_demo/scripts/test_high_level.py to see how the onboard controller can be used in crazyflie_ros. |
|
Just the thing is I’m using a differential flatness based controller which outputs total thrust, roll, pitch, yaw rate commands. That’s why I can’t use the onboard position controller. Another thing I’m using 3 controller.cpp files (one for each drone) because each one subscribes to a different goal and publishes a different cmd_vel commands. I noticed in your multi_waypoint_vicon.launch file you are calling the same controller.cpp file which has only “goal” and “cmd_vel” topics so how does distinguish between different goals and different cmd_vel for different CFs. Lastly I didn’t get what you meant by “I don't think the radio has actually enough bandwidth to send control signals and receive the data from the drones” does it mean one radio can’t control them at the same time at all or just the logging can’t be enabled ? |
|
Own position controller: this makes sense now. In this case you should not use the onboard controllers (unless you want to implement your own controller directly in C in the firmware.) Different goals: The way you did it should be fine: You essentially run the same controller.cpp, but in a different ROS namespace. Each controller node will then pick up the cmd_vel and goal topics from the namespace they are in. Radio: Yes, I meant that with logging enabled there will be a lot of traffic over the radio. I suggest that you try disabling logging and see if that helps. At which rate do you publish your cmd_vel commands? It is hard to tell how many drones you can control with logging enabled (this depends on your logging configurations), but if you disable logging 3+ CFs is not an issue on a shared radio. |
|
Each Controller.cpp publishes the cmd_vel at a 100 HZ frequency. I’m using the original onboard attitude controller and by default it works at 500 HZ. Regarding the attitude controller, does it accept the yaw angle or the yaw rate as an input ? Because I noticed that the CF becomes unstable in the yaw and keeps rotating if my controller yaw rate command is anything other than zero. One last thing, as far as I understood, the logging is related to the data that could be visualized in a client like the cfclient and disabling it will not affect the sensor data coming from the CF such as the imu data etc correct ? |
|
By default, the attitude controller uses desired angles in deg for roll, pitch, and rate for yaw. You can change this behavior using parameters (see https://github.com/bitcraze/crazyflie-firmware/blob/master/src/modules/src/crtp_commander_rpyt.c#L226-L228). Yes, logging only affects data that you transmit from your CF to the PC. In your case, this might not be needed (and if it is, you can reconfigure it to use less bandwidth by reducing the update rate). |
|
I disabled the logging as you suggested, now the CF behaves much better, however, its altitude still drops at the 5th or the 7th second but doesn’t drop all the way to the ground as before. Is there a way to further solve this problem ? Another thing is in Simulink I subscribe to each CF imu data and position and accordingly I publish its goal to its controller.CPP file. The demo localization file I’m using (the one I attached in a previous comment) already connects to all the 3 CFs whether I publish to their goals or not. The problem is in Simulink when I subscribe and publish for 2 CFs they work fine but when I add the third one they become unstable in the Z direction and their attitude as well. Do you suggest it’s a Simulink Problem like legging or smth ? I’m using Matlab 2018b (Student version) or it’s a radia Problem again ? And is there a way to control the 3 CFs using two radios maybe that will solve the problem ? |
|
Drop: Are you seeing this issue flying a single CF, or multiple? This kind of behavior is hard to diagnose, because it can be either a radio problem, a state estimation problem, or a control problem. 3 CF issues: Since you use imu + position, you must have re-enabled logging. In this case the bandwidth is likely not enough. You can switch to two radios (use another channels, and radio://1/... as URI). |
|
Drop: I don’t see this problem when I fly a single CF using the same controller and state estimation so I don’t think it’s a controller problem or state estimation problem because everything is the same, the only change is the demo localization file. 3 CFs issues: I just don’t understand why do I have to re-enable logging? I disabled the logging for the 3 CFs in the demo localization file and it was fine for the first and the second CF until I added the third CF publisher and subscriber in Simulink then that problem of instability in Z and attitude started to happen. Another radio: I add the second radio as radio://1/... as URI in the same demo localization file right ? |
|
If you disabled logging, then you shouldn't be able to subscribe to the imu topic (this data comes from the logging framework). It really just seems to me like a radio bandwidth issue. Try using 2 or 3 radios. You are correct that you just need to change the URI in your launch file. Also, you should use different channels that are spaced at least 2 apart (e.g., channel 80, 82, 84) if you are using the 2M datarate. |
|
I enabled the logging and used three different radios; however, I still have the same problem. I tried with two new different 2.1 CFs, but the problem is always the same. Once I add the goal publisher for the second and the third CFs, the problem happens. My Simulink output is the 4 inputs to the on-board attitude controller, but I publish them to the goal topic, and in the controller CPP file, they get published to the cmd_vel topic. Do you think when I add the second and the third goal publishers in Simulink that causes some lagging or something? And if so, isn't the controller Cpp file supposed to keep running at 100 HZ no matter the rate that Simulink publishes at? I also attached the demo localization file I'm using. |
|
Your launch file looks fine to me. As you said, the controller node executes at 100 Hz and operates independently of your Simulink output. I am a bit confused about why you need the controller in the first place, if your simulink model outputs desired angles/rates. In that case, you should directly publish to the cmd_vel topic from simulink and not execute any controller node. Did you test if the same issue occurs with just 2 CFs? Or is it fine with 1 or 2 CFs, but once you add a third there is an issue? |
|
You are right, I should publish Cmd_vel directly from Simulink and this was actually the first thing I did. However I saw a huge lagging even in only one CF case, the motors would spin on and off. That’s why I decided to publish them first to the controller Cpp file to guarantee a fixed publishing rate. This worked perfect for one CF. When I use 2 CFs I see it oscillating but at least it’s flying and when I add the third CF in Simulink it becomes totally unstable even though I’m using 3 different radios and different channels as shown in the demo localization file I attached before. |
|
Are you using a virtual machine, or anything else that could dramatically impact performance on your PC? Is Simulink running on the same computer, or a different one? |
|
No, I’m using a Linux PC and Simulink is running on the same computer yeah. |
|
Can you check your CPU utilization (htop), and also verify that the topics are published at the desired rate (e.g., rostopic hz cmd_vel)? It is strange, but it seems like some kind of performance issue at one of the nodes. |
|
I've tried it again now. it worked once fine then the following 3 times it did the same problem of oscillating then falling down. I attached the output of the demo_localization launch file, hz cmd_vel command, and rostopic echo cmd_vel command. The flight test was for the third CF where the first and the second CFs were given commands of zeros. |
Hello,
I’ve been trying to flash the firmware to a crazyflie 2.1. After using make cload and flashing successfully, led (1) blinks 5 short red pulses which indicates that self test fails. I’ve tried 4 new different 2.1 crazyflies and the same problem happens with all of them. With crazyflie 2.0 it works fine. So I was wondering if the firmware is made specially for Crazyflie 2.0 and if it’s compatible with 2.1 or not ?
Thanks,
The text was updated successfully, but these errors were encountered: