gsilano/CrazyS

Statespace controller for Crazyflie in ROS Gazebo using Matlab

danialwaleed opened this issue · 5 comments

Hi There,

First of all of thank you for the work that you have done with ROS and Gazebo for Crazyflie. Your work has really helped a lot. I have been trying to use your files in order to develop a state space controller for Crazyflie 2.0. My main aim is to essentially maneuver the quadcopter in Gazebo any way I like using waypoints and generation of RPM via the control output. So far I have had moderate successes. This how far I have been able to figure out things.

  1. My state space controller is essentially a high level controller that generates the required RPM in order to move to a desired position.
  2. I am assuming that this is enough because using mav_msg/Accuators I can publish RPM to the quadcopter in Gazebo

When I implement this controller for an altitude(hovering) test, initially everything runs fine but then all of a sudden the quadcopter losses control and falls down. After much deliberation, I was convinced that this has to do something with the sampling time. I then stumbled upon your other discussion (ethz-asl/rotors_simulator#487). Where I was able to confirm some of my doubts.

  1. Running a Gazebo simulation control without pausing leads to issues
    Sol) Introduce Pause in the simulation using the script provided in (https://github.com/ethz-asl/rotors_simulator/wiki/Interfacing-RotorS-through-Matlab)

So I implemented that in my control system but to no avail the quadcopter still falls down after some time. I really don't know why because I have done countless simulation in Matlab were based on the parameters the controller works totally fine.

I am also attaching my Matlab files that I hope helps(Crazyflie quadcopter control ROS.zip . Please use the file run_Crazyflie_control.m after opening crazyflie_without_controller in you linux machine.

  1. Another issues that I was hoping to solve is to use Simulink for the control, but I found it very difficult to send data on mav_msg/Actuators. For some reason Simulink assigns it 128 size of data that I really don't know how to tackle . If you have solved this issue please let me know.

Any help will be highly appreciated.

Thanks for opening your first issue here! Make sure that no other issues on the same topic have already been opened!

Yeah, this is an existing problem. I mean, make MATLAB and Gazebo work together synchronously. Unfortunately, I don't have time to go through your code and figure out what's wrong. I am sorry about that.
I highly recommend that you take a look at this problem (#26) where someone has already tried to figure out the problem or at least had the same problem.

At that time, when I was working on MATLAB and Robotics System Toolbox (it was a very early stage), I figured out the problem by using a MATLAB script to manage the synchronization between Gazebo and MATLAB. There, a Simulink had to run the control algorithm.
Looking at this implementation from an old perspective, I would say that perhaps Simulink is not needed. You could run everything in a MATLAB script. Furthermore, I would propose to separate the control from the synchronization algorithm, thus having the possibility to easily explore new control techniques. This would make the simulation faster and improve the readability of the code.

I hope this helps. Please let me know if you need any further clarification from me.

Hi, thanks for replying, I completely understand that you cannot go through my code because of your commitments and that is totally fine. My request is that whenever you are free and if you can go through the code, that will be highly appreciated. I will also contact the author of (#26) and see if he has had better luck.

I do have three small requests that I hope you can help me with.

  1. Do you have any idea whether lower level control for the crazyflie is really required. I have been going through the work done in (https://www.mathworks.com/videos/matlab-and-simulink-robotics-arena-simulating-quadcopter-missions-1510058448836.html) and in this the control of the quadcopter is done by sending out velocity commands. This is interesting, as on a purely demonstrative purpose this simulation is impressive. However, I do understand that the code developed cannot be fully transferred to an actual quadcopter system due to incomplete code structure.

  2. What are your thoughts on the reason why initially the controllers works fine but then losses control. I assume the reason behind this is that at present my control algorithm publishes rpm values directly. Whereas, from your implementation you have middle controllers that produce PWM values which are then used to generate RPM values. Is the absence of such a controller the main problem, I am not sure but if somebody can help me figure this out that would be great.

  3. What are your opinions on what is required to formulate a waypoint control for the crazyflie. If you can highlight points that need to be worked on, I can start work on those points and see if I can improve the current situation on waypoint control.

Hope to hear from you on these three points.

Simulation is a great way to test and tune control algorithms for quadcopters. Julien Cassette talks about using Simulink, Robotics Operating System (ROS), and Gazebo to simulate quadcopter missions from student competitions.

Of course, I added it to my calendar. I should have some time during my vacation (August 2021). I will keep you updated.

My answers are in order:

  1. Well, I think that is necessary. If you are planning to perform real-world experiments with the platform, the low-level controller (the Crazyflie input interface) should reflect what you can physically do with the vehicle. This was the aim of having such a simulator in Gazebo (i.e., CrazyS) trying to reply to the needs of researchers and developers. However, if you don't mind performing any experiment with the vehicle, I would say that any vehicle is fine for you. So that you can enter with waypoints, velocity commands, or whatever your interface provides as input.
    I don't know the MathWorks example, but I think it is made for Parrot's devices. As you know, MATLAB has a dedicated toolbox for this.

  2. As I said, I tested with MATLAB in the loop without any problems. The only thing that comes to my mind, could be a possible loss of communication among the two or an asynchronism between MATLAB and Gazebo. You should check if something like this is happening. As I said, the best and easiest option is to use stop and start Gazebo services to make sure that MATLAB and Gazebo really work together.

  3. Wel, I think that first, you should start understanding the low-level controller and what the Crazyflie parameters are (the drone model is the same for any vehicle you are going to use). Then, try designing a simple waypoint controller in MATLAB (the literature is full of these results). After that, you could figure out the status of the current software implementation, if something is missing or wrong, and finally implement your solution (I don't expect more than a .cpp file). Sure, I could help you at this stage. I mean, supervise your work.

stale commented

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.