Closed kevin-thankyou-lin closed 3 years ago
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.
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!
--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.
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!
Describe the bug There's a bug when I try to use
DynAviary
onfly.py
To Reproduce Steps to reproduce the behavior:
To
fly.py
, import DynAviary e.g. on line 33:from gym_pybullet_drones.envs.DynAviary import DynAviary
Comment out the VisionAviary and CtrlAvary envs
Add
in place of the
if ARGS.vision
if-else statementsrun
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:
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!