Developer Meeting (July 5 2023): Webots Simulator

[knmcguire]

The next developer meeting will be on the 5th of July, where we will talk about the Crazyflie model in the Webots simulator and give an hands-on demonstration.

Date: Wednesday, July 5th, 2023
Time: 3 PM Central European Summer Time (check your timezone)
Topic: Simulation in Webots
Hosts: @knmcguire and @ataffanel
Meeting link: Meeting is over! Check the recording here: https://youtu.be/yneriZeUwqY

Agenda
15:00 - 15:30: Presentation, hands-on and discussion
15:30 - 16:00: Generic support questions

Indicate with 👍 if you are planning to join!

[knmcguire]

The dev meeting is starting now :)

[LorenzoLamberti94]

Hi @knmcguire !
Out of curiosity, i was wondering if you ever tried to fly a crazyflie in Isaac Gym by nvidia.
I saw there is a Crazyflie model: https://docs.omniverse.nvidia.com/app_isaacsim/app_isaacsim/reference_assets.html
is it developed by bitcraze or is it an external project?

thanks :)

[knmcguire]

Ah yes I did mention that in the presentation. No I haven't tried it yet!

It has been contributed by someone else (but I do know that they used my model ;) ) I recognize those polygons from anywhere!

Let me know if you have tried it yourself!

[knmcguire]

The recording is online here! https://youtu.be/yneriZeUwqY

[simondlevy]

I am interested in following up on a question raised by Stephane Le Menec in the developer session, namely, calling the Crazyflie C firmware (instead of Python approximations to it) directly in Webots. @knmcguire, you mentioned that you might have some pointers for anyone interested in doing this. Although I generally prefer to prototype new ideas in Python, the advantages of working directly with the C firmware seem pretty obvious. Once one has gotten past the compile/linking issues (which I can probably figure out on my own), the next question would seem to be the most useful level of abstraction at which to call the firmware routines. Minimally I think one would want to call the actual PID controllers being used, but perhaps it would make sense to call the EKF as well (after simulating some noise in the sensors, as I'm currently doing in Python). Mainly I'm interested in whatever direction would most benefit the community, providing a way for C hackers to rapidly prototype-and-deploy new ideas.

[knmcguire]

Hi! yes there are the python bindings I referred to. You can find instructions for that here: https://github.com/bitcraze/crazyflie-simulation#firmware-python-bindings. Just mind that there are some issues remaining so make sure to keep an eye on the issue list: bitcraze/crazyflie-firmware#602. The timing now used in the simulator is now fixed so that might cause some stability issues.

We only got these working for the controller though but hopefully in the new future we'll be able to add the EKF as well. @krichardsson has been working on that on some of his projects.

[simondlevy]

Thanks, @knmcguire! I think a good approach would be to use the python bindings as a step toward getting my Webots simulation to work with the C firmware.

[simondlevy]

I've also been thinking about the possibility of the firmware being in header-only C++ instead of C. Just for fun I tried compiling the current C firmware with the ARM g++ compiler, and with a little tweaking it compiled just fine. Obviously this would be a very big change, but in my experience the abstraction you get with C++, combined with not having to maintain a separate set of .h and .c files, make it worthwhile to consider.

[simondlevy]

... meanwhile I was able to run the Webots simulation pretty easily using your Python firmware bindings! In my fork of the firmware repo I added a little setup script and Makefile line to support the standard distutils install of cffirmware lib, so the controller script doesn't have to add the relative path to it.

[knmcguire]

You can consider making a PR for this one. Actually we are planning to at one point release the python bindings as pypi packages but first want to solve those issues we saw

[simondlevy]

Thanks, @knmcguire; I've create a pull request for this.

On a related topic, do you think it would help if I did pull requests in the crazyflie-simulation and crazyflie-clients-python repos, to support flying the webots sim using the Python GUI? I think this could be a fun way to get people comfortable with the Crazyflie approach, before their first flight on an actual Crazyflie!

[knmcguire]

ohw absolutely! Just a warning, we are a bit swamped this and next week so we will be a bit late with responding but definitely after that we will review it for you.

[simondlevy]

Great, I modified the PC Client GUI and the Webots simulator to work together like this, and did the corresponding pull requests. My new webots controller even uses your firmward PID bindings!

Currently my controller flies only in Hover mode, but I have the client pass along the flight mode along with the stick demands, in case anyone wants to make the sim even more realistic.

[simondlevy]

I'm not sure whether others have commented on this here, but I'm finding that Webots runs C several orders of magnitude faster than Python. Even after commenting-out all but my speed-reporting code [a simple print(1 / (system_time_curr - system_time_prev)), I found that the Python loop runs at around the same speed as the robot's timestep (32 msec => 33 Hz), whereas the C version with the same 32msec timestep runs at around 25kHz! I have to think that this huge difference in running speed would make a difference in the quality of the firmware simulation, but I wonder what others think.

[knmcguire]

I'm not suprised actually, however more of our users are more familiar with python then C. It would be nice to have the option for both though, as the c option might be nice for swarming!

[simondlevy]

Your Python API for the firmware is so nice that I'm using Python after all! :^)

[knmcguire]

@simondlevy I will start a new discussion to discuss the PRs as I feel that they need a bit more of a strategy first ;) It would be good to take a step back and look big picture first. There are some thoughts I have about the process as well, and it will have a better base for the PRs. I can also help you with setting up the PRs, that we don't have the issue that we can't see the right diffs (which we will not be able to merge anyway).

So let's talk there!