DynAviary nnlsRPM bug

[kevin-thankyou-lin]

Describe the bug There's a bug when I try to use DynAviary on fly.py

To Reproduce Steps to reproduce the behavior:

1. To fly.py, import DynAviary e.g. on line 33: from gym_pybullet_drones.envs.DynAviary import DynAviary

2. Comment out the VisionAviary and CtrlAvary envs

3. Add

                   num_drones=ARGS.num_drones,
                   initial_xyzs=INIT_XYZS,
                   initial_rpys=INIT_RPYS,
                   physics=ARGS.physics,
                   neighbourhood_radius=10,
                   freq=ARGS.simulation_freq_hz,
                   aggregate_phy_steps=AGGR_PHY_STEPS,
                   gui=ARGS.gui,
                   record=ARGS.record_video,
                   obstacles=ARGS.obstacles,
                   user_debug_gui=ARGS.user_debug_gui
                   )

   in place of the if ARGS.vision if-else statements

4. run python fly.py --physics dyn

Expected behavior I'm expecting the drones to fly similar to CtrlAviary. Instead, the drones immediately fly out of view on the 2nd step of the simulation.

The warnings are:

[WARNING] iter 5 in utils.nnlsRPM(), unfeasible thrust 17106.24 outside range [0, 0.60]
[WARNING] iter 5 in utils.nnlsRPM(), unfeasible roll torque 17106.24 outside range [-0.01, 0.01]
[WARNING] iter 5 in utils.nnlsRPM(), unfeasible pitch torque 17106.24 outside range [-0.01, 0.01]
[WARNING] iter 5 in utils.nnlsRPM(), unfeasible yaw torque 17106.24 outside range [-0.01, 0.01]
[WARNING] iter 5 in utils.nnlsRPM(), unfeasible squared rotor speeds, using NNLS
Negative sq. rotor speeds:       [-525076195938723.56, 1516331668969410.00, -525076195938723.62, -412045601889035.19]           Normalized: [-0.30, 0.87, -0.30, -0.24]
NNLS:                            [0.00, 1378983135006398.25, 0.00, 0.00]                        Normalized: [0.00, 1.00, 0.00, 0.00]            Residual: 1630457287724757.50
[WARNING] iter 5 in utils.nnlsRPM(), unfeasible thrust 17965.44 outside range [0, 0.60]

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information): Ubuntu 18.04, Python 3.7 (everything else works as normal)

Thanks for your time!

[JacopoPan]

Hey @kevin-thankyou-lin,

DynAviary expects an action is thrust and torques so it wouldn't work with script fly.py where actions are RPMs returned by a PID controller.

Is https://github.com/utiasDSL/gym-pybullet-drones/issues/37 what you are trying to achieve? If so, yes you should try option --physics dyn but with the original CtrlAviary class (that bypasses the use of PyBullet's applyExternalForce for a simple dynamics update written in Python).However, I'm not sure on your reasoning about p.setRealTimeSimulation(1), are you sure that is what you are looking for?

By default, the physics server will not step the simulation, unless you explicitly send a 'stepSimulation' command. This way you can maintain control determinism of the simulation. It is possible to run the simulation in real-time by letting the physics server automatically step the simulation according to its real-time-clock (RTC) using the setRealTimeSimulation command. If you enable the real-time simulation, you don't need to call 'stepSimulation'. Note that setRealTimeSimulation has no effect in DIRECT mode: in DIRECT mode the physics server and client happen in the same thread and you trigger every command. In GUI mode and in Virtual Reality mode, and TCP/UDP mode, the physics server runs in a separate thread from the client (PyBullet), and setRealTimeSimulation allows the physicsserver thread to add additional calls to stepSimulation.

[kevin-thankyou-lin]

Hi @JacopoPan, thanks for the fast response!

Gotcha

Yes, #37, I'm planning to run in simulation and then on hardware. Gotcha, --physics dyn work and subverts the need for applyForces, but when I set p.setRealTimeSimulation(1), on around line 140 of fly.py (and remove these lines from BaseAviary)

    #### Obtain the PyBullet Client ID from the environment ####
    PYB_CLIENT = env.getPyBulletClient()
    p.setGravity(0, 0, -9.8, physicsClientId=PYB_CLIENT)
    p.setRealTimeSimulation(1, physicsClientId=PYB_CLIENT)
    p.setTimeStep(1/ARGS.simulation_freq_hz, physicsClientId=PYB_CLIENT)

the drones just drop to the ground i.e. different behavior from p.setRealTimeSimulation(0, physicsClientId=PYB_CLIENT).

Would you know how to fix this?

Thanks for your help, again!

[JacopoPan]

--physics dyn really subverts PyBullet entirely other than using it for the GUI and/or rendering. I don't necessarily see why you think p.setRealTimeSimulation(1) would help moving towards hardware. What type of policy are you trying to implement or learn? The CtrlAviary in fly.py is intended for a low level attitude/position controller that would need to be ported to C to run on a real Crazyflie.

[kevin-thankyou-lin]

Okay, that's fair. True, I was just thinking I could use the real time sim as a heuristic, but that's true about porting to C. I'm not quite focusing on end to end policy learning (if that were the case, yeah, I wouldn't need a PID controller). I'm more decoupling control from perception so that's why I need a PID controller.

Thank you!