DynAviary nnlsRPM bug about gym-pybullet-drones

[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 #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!