Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable testing in windy environments #14737

Merged
merged 1 commit into from
Jul 2, 2020
Merged

Conversation

Jaeyoung-Lim
Copy link
Member

@Jaeyoung-Lim Jaeyoung-Lim commented Apr 22, 2020

Describe problem solved by this pull request
Previously, wind was a gazebo model plugin since wind was simulated by applying "force" on a link. Since wind was a element inside the model, models could have different wind simulated even if they are in the same world.

However, this has changed since PX4/PX4-SITL_gazebo-classic#462. Therefore, we can make the wind a property of the "world" and make different vehicles be affected to this no matter which vehicle is spawned in the world.

Describe your solution
To simulate a windy world, simply run the following.

make px4_sitl gazebo_plane__windy

Test data / coverage
Log: https://review.px4.io/plot_app?log=04b3ea46-2489-424d-904c-3e2aadf820cc

Additional context
Depends on PR PX4/PX4-SITL_gazebo-classic#462

@Jaeyoung-Lim Jaeyoung-Lim requested review from dagar and MaEtUgR April 22, 2020 19:12
@TSC21
Copy link
Member

TSC21 commented Apr 22, 2020

@Jaeyoung-Lim the complexity increases, but what if we make the windy another target that composes the final targer, and that you can use with any world?

@MaEtUgR
Copy link
Member

MaEtUgR commented Apr 22, 2020

A maybe stupid question not being fully on the topic: What blocks having 0 wind in all simulations and just setting it higher through a gazebo parameter during runtime if you want/need it?

@TSC21
Copy link
Member

TSC21 commented Apr 22, 2020

A maybe stupid question not being fully on the topic: What blocks having 0 wind in all simulations and just setting it higher through a gazebo parameter during runtime if you want/need it?

Well because that requires one to manually set it on the SDF file. This is just a shortcut with a default value

@Jaeyoung-Lim
Copy link
Member Author

Jaeyoung-Lim commented Apr 22, 2020

@TSC21 Then we need to start generating world files... Wouldn't this be too complicated to be tractable?

@MaEtUgR Nothing actually, it is just that PX4/sitl_gazebo has its own wind messaging definition that is not compatible with upstream. We can also try to make it compatible with upstream wind topics but we have less control over what kind of wind/gust we can generate in this case.

The intention of this PR is to enable people to use windy situations without modify ANY files or any second step modifying through the gazebo client, so that it works out of the box.

@TSC21
Copy link
Member

TSC21 commented Apr 22, 2020

@TSC21 Then we need to start generating world files... Wouldn't this be too complicated to be tractable?

Well not really. A simple python script would easily enable to add some lines to the world files that you wanted to use. No need for templating, although it could be worth to have a single template from where you could add certain properties to the existing world files. I.e imagine you want one specific world with wind - you pick the template, set what world you want to add wind to, and a new world with the suffix _windy is created and used.

@TSC21
Copy link
Member

TSC21 commented Apr 22, 2020

Just to be clear: this PR is fine and the simple approach is acceptable. I was just suggesting we could make it a bit more flexible if that doesn't take too much effort.

@Jaeyoung-Lim
Copy link
Member Author

@TSC21 I had some thoughts about this, and I think generating windy environments can be added separately in sitl_gazebo repository when it is built.

If we add these windy worlds to be generated in build time, would having a windy world for every world be something close to what we want?

We still need these worlds to exist to be able to spawn multiple vehicles into the world, so I think it would be better than generating a temporary world file at every make.

@TSC21
Copy link
Member

TSC21 commented Apr 30, 2020

@TSC21 I had some thoughts about this, and I think generating windy environments can be added separately in sitl_gazebo repository when it is built.

If we add these windy worlds to be generated in build time, would having a windy world for every world be something close to what we want?

We still need these worlds to exist to be able to spawn multiple vehicles into the world, so I think it would be better than generating a temporary world file at every make.

Wouldn't that add too much duplication?

@Jaeyoung-Lim
Copy link
Member Author

@TSC21 Or maybe a small set of environments? What I want to avoid is re-editing the world files when we envoke a makefile. So that it is a bit more simpler and easy to understand what it is doing.

@sfuhrer
Copy link
Contributor

sfuhrer commented May 22, 2020

If I could add my 2 cents here: it would be awesome if we would have an interface to easily set a specific windspeed, either during runntime (guess not easy), or else before running the sim with a environment variable. I really mostly care about the magnitude of the wind (horizontal), and not so much about the variance and variance.
If you guys prefer the approach here, then I'm also fine with it - and for me having just one windy world would suffice.

@Jaeyoung-Lim Jaeyoung-Lim requested a review from TSC21 July 1, 2020 20:58
@TSC21
Copy link
Member

TSC21 commented Jul 1, 2020

@Jaeyoung-Lim can we make a commitment to extend this as suggested in the above conversation we had? This is acceptable as is but I think we can make much more flexible for the different worlds.

@Jaeyoung-Lim
Copy link
Member Author

@TSC21 For sure!

@Jaeyoung-Lim Jaeyoung-Lim merged commit 692cb71 into master Jul 2, 2020
@Jaeyoung-Lim Jaeyoung-Lim deleted the pr-add-windyworld branch July 2, 2020 13:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants