Drone does not explore in the Simulation

[Qassim69]

I am working with a swarm of Crazyswarm drones. The simulation is set up as follows:

There is a closed room with a source dispersing gas particles. There are 4 drones (eventually, I will add more) deployed in this environment that must identify the gas source based on specific logic. The simulation of the gas-dispersing environment is created using GADEN2.

Each drone runs a main script that switches between two modes: "Random Point" mode and "Bout Following" mode. The drone first takes off and reaches a certain height. It then switches to Random Point mode, where the algorithm calculates the necessary velocity and direction to reach that point. As it approaches and crosses a threshold of being near that point, it switches to Bout Following mode, where the drone checks for gas plumes. If gas is detected, the drone swirls around; if not, it switches back to Random Point mode and moves towards a new point.

The issue is that in the simulation, the drone takes off and reaches the target height but does not enter Random Point mode. Instead, it starts descending towards the ground. In the terminal, I can see that the scripts are generating the necessary velocity and sending it to crazyflie_sil.py, which then forwards it to the PID controller scripts.

Ascending.mp4

Descending.mp4

[knmcguire]

Hi! So.. this simulation does not look very familiar to me. Is this a project that you made yourself? What is the main part of crazyswarm2 that is blocking you?

We need quite a lot more information here if the scope is outside of the Crazyswarm2 project

[whoenig]

I addition, it seems like most of the application-specific things are not really relevant for the issue at hand. Try to include a minimal example without additional dependencies that demonstrates the issue you are having.

[Qassim69]

So there is a repository called GADEN2 which is runs a 3D simulation of a gas dispersion from a source in a room(with walls and doors). This 3D environment has parameters such as gas type, gas dispersion speed, 3D walls, etc. which are used to create 3D gas dispersing simulation.

I use crazyswarm2 package to deploy a swarm of crazyflie drones(4) in this 3D environment and based on my algorithm it will identify the gas source. So in the algorithm all the 4 drones have to takeoff using the cf.takeoff command(cf is crazyflie script from the crazyflie package) and reach a certain height(0.5m) which it does. After it reaches the height, there is a random point generated within the 3D space and based on drone's current position it calculates the velocity required to move in the direction of the Random Point. The script has 2 modes that the drone follows: Random Point Mode and Bout Following mode.

But in the simulation after the drone reaches 0.5m, all the 4 drones tend to drift and crash to the ground. There is no stable movement in the drone to reach the random point and then switch to the Bout following mode depending on gas it has to swirl around it or not and then switch back to Random point mode and so on. I have added DEBUG lines so I can confirm that the velocity does get sent to crazyflie_sil.py and to the PID controller scripts.

So my logic script generates a velocity which is sent to crazyflie_server.py which then sends it to crazyflie_sil.py and then to the PID controller scripts. This PID controller script then calculates the PWM values for each motor which is then sent to crazyflie_sil.py to convert PWM to RPM values. These values are then sent to crazyflie_server.py which calls the physics backend (np.py). np.py then converts the RPM values to forces. Since np.py is responsible for the simulation i tried tweaking the mass and force values but that did not fix the issue there is still instability in the drone's movement.

I'm not sure if this is causing the issue:

1. Is there a issue in the np.py physics simulator that it is not providing enough thrust to maintain a stable flight?
2. Are there any differences in PID controller scripts and np.py?
3. Is there a issue that the velocity from the logic script to crazyflie_server.py and then to crazyflie_sil.py and then to PID controller scripts and then back to crazyflie_server.py and then to np.py is not being communicated fast or there is a timing issue?
4. Is it that the thrustBase is considered around 36,000 - 40,000 PWM in position_controller_pid.c script which considers the mass of the drone to be 28g and np.py considers the mass as 34g? I'm not sure if its true and causing instability.

[whoenig]

It sounds like you first take off using the high-level commands like goTo. Afterwards, you switch to low-level commands - which ones exactly? Did you try just keep using high-level commands (e.g., goTo) instead?

[Qassim69]

So I use the def takeoff() function from class crazyflie in the crazyflie.py scripts(from crazyflie_py package). After it reaches the height required, my logic script then generates a random point and calculates velocity to reach the Random Point.

These velocity values are published using the def cmdVelocityWorld() function from crazyflie.py.
The velocity values are subscribed using this def _cmd_velocity_world_changed() function from crazyflie_server.py and sends it to crazyflie_sil.py.

The executeController(self) function from crazyflie_sil.py sends it to the PID controller scripts and the def cmdVelocityWorld() function from crazyflie_sil.py stores the velocity values as setpoint and X;Y;Z and yaw are assigned as modeVelocity and not modeAbs and velocity_body is False.

The executeController(self) function from crazyflie_sil.py then sends the PWM values from PID scripts to get converted into RPM values and send the result back to crazyflie_server.py

This line self.backend.step(states_desired, actions) from the function def _timer_callback(self) in crazyflie_server.py calls the physics backend and further functions from the class Backend and the class Quadrotor receive the RPM values which converts to forces.

[whoenig]

My suggestion was essentially to use goTo() instead of cmdVelocityWorld(). The goTo also takes a time-parameter, so you can still achieve a desired velocity. The main difference is that you stay within the high-level mode, which is better tested in simulation (and also should work more robustly on the real drones).

[Qassim69]

I'll try it with goTo(). I wanted a clarification regarding this:
After the takeoff() command drone reaches 0.5m, as per my logic script it generates a random point in the 3D space. If the Random Point is below 0.5m (For eg.: 0.1m) based on this a function generates a velocity in that direction. Then in PID controller the velocity value received is a -ve value. So how exactly would the drone behave with a -ve Z value?

The drone reaches the 0.5m height after the command cf.takeoff. The next command is that a Random Point is generated and velocity is calculated to reach that Random Point. If the drone's current position is (2,3,0.5) and the Random Point is (3, 2, 0.1), it will generate a +x velocity, -y velocity and -z velocity which makes it diagonally reach that Random Point. These x and y values are fed into the PID controller scripts which generate the required roll and pitch. I wanted a clarification how exactly does it process the -z value.
Does it reduce the thrust which means gravity will act higher on the drone making it crash while moving down?

What is thrustBase defined in the PID controller scripts for the drone and does it consider the drone weight to be 0.034kg or 0.028kg in the PID controller scripts because depending on the thrustBase value the drone weight can be identified to be either 0.034kg or 0.028kg.
In the np.py drone weight is considered to be 0.034kg. I just want to know would the difference in weight value of PID controller and np.py affect in the descending movement of the drone.

[whoenig]

• The controller tries to stabilize around the velocity, not a particular position.
• The different weights shouldn't matter match: they'll cause a tracking bias, but not the kind of instability that you describe.

I am not sure if we tested the simulation with velocity commands much. Using goTo is better tested and should have the same behavior that you desire. Does your script work on a real drone?

[Qassim69]

The goTo() function is currently unsuitable for this implementation because it requires a Goal Position, whereas my logic script utilizes a different approach.

In my logic script, the drone’s velocity and magnitude are calculated based on environmental constraints, such as wall boundaries and the proximity of other drones. According to the defined Update Rate, all the drones constantly update their coordinates and each drone checks its proximity with other drones. If another drone enters its proximity, the script immediately diverts the trajectory, recalculating the velocity and magnitude to ensure a smooth transition toward the final Random Point.

Integrating the goTo() function would disrupt this fluid recalculation. Furthermore, the goTo() command lacks the necessary precision for micro-adjustments; when handling short distances, it produces jerky movements that compromise flight stability according to the description in crazyflie.py.