FlightGear simulator support #14539

kaklik · 2020-03-30T23:21:11Z

The PX4 stack seems does not currently support the FlightGear simulator for SITL simulation. The FlightGear has better support for modeling of rotorcraft than the current PX4's mainstream simulator Gazebo.

This pull-request adding the possibility of the use of FlightGear(FG) and was tested on the autogyro TF-G1 simulation model.

It is a stand-alone application, which connect to FG (over UDP generic protocol) and PX4 ( over TCP, Mavlink)

The flight video

The flightgear_bridge has few limitations, which are not fully resolved:

The PX4 is connected to FlightGear thought "generic protocol", which is served synchronously to the simulator graphics engine frame rate. So the PX4 gets the sensor data in frequency, depending on graphics resources and the current scene.
In the future, the bridge can upsample the data by generating noised samples from the last known value it is a terrible way. Question is: What is the lowest acceptable rate of sensors data? We did not find that.
What do you think about the implementation of the auto-download of FG models for FlightGear? The suggestion is to use the submodules architecture to link PX4 simulation supported FG models.
The simulation must be run in no lockstep mode.

To the simulation could be run by

make px4_sitl_nolockstep flightgear_rascal for plane or make px4_sitl_nolockstep flightgear_tf-g1 for autogyro.

TSC21 · 2020-03-30T23:36:09Z

This is really cool! Although, I do think it makes mores sense that the flightgear_bridge is a repository by itself and that it gets included as a submodule here, similarly to sitl_gazebo and jMavSim.

dagar · 2020-03-30T23:42:05Z

Great contribution!

dagar · 2020-03-31T00:04:06Z

This is really cool! Although, I do think it makes mores sense that the flightgear_bridge is a repository by itself and that it gets included as a submodule here, similarly to sitl_gazebo and jMavSim.

@TSC21 I think it's really a question of it being worth maintaining as a standalone project or not.
It very much is a standalone project, but realistically we might be better off maintaining it in tree unless someone wants to set up testing, CI, etc in a new repo.

TSC21 · 2020-03-31T00:11:21Z

This is really cool! Although, I do think it makes mores sense that the flightgear_bridge is a repository by itself and that it gets included as a submodule here, similarly to sitl_gazebo and jMavSim.

@TSC21 I think it's really a question of it being worth maintaining as a standalone project or not.
It very much is a standalone project, but realistically we might be better off maintaining it in tree unless someone wants to set up testing, CI, etc in a new repo.

I think the maintenance effort of something like this is independent if it is on a tree or not. It's more about the commitment to actually maintain it. And that needs to be the same being it on the Firmware tree or not. I just see this being much more organized by being included in its own repo with its own structure and then having it included here as a submodule. I would expect the CI pipeline for it to be relatively easy to setup.

Tools/flightgear_bridge/src/fg_communicator.cpp

Tools/flightgear_bridge/README

ROMFS/px4fmu_common/init.d-posix/17001_TF-G1

Antiheavy · 2020-03-31T01:32:18Z

I love flight gear!

slimonslimon · 2020-03-31T07:15:09Z

At first thank you for extremly fast reaction.

How does it work:

It is stand alone app, which connect To FG (over UDP generic protocol) and PX4 ( over TCP, Mavlink)

There are few limitation, problems, and possible improvements:

as @kaklik mentioned, the gereric protocol of FG is somehow limitated by FPS of FG. So you get sensor data in low frequency, depending on your machine. (bridge can upsample it in terrible way). Question is: What is lower frequency of sensors data? I did not find that..
What do you thing about implementation of auto download of models for FlighGear?
There is strange problem with LockStep: FG build of PX4 need to be builded without LockStep, but I am not able to set up cmake scripts to build PX4 binary for FG without Lockstep and Gazebo Px4 Binary with LockStep. Can you help me? (https://github.com/PX4/Firmware/pull/14539/files#diff-a0bb2f464f832f23df5a4d5b1737cef2) -- I think this demage testes

Jaeyoung-Lim

This is really cool! Thanks!

My concern is that FlightGear only seems to support a subset of the models, but this case is not handled.

Jaeyoung-Lim · 2020-03-31T06:36:16Z

platforms/posix/cmake/sitl_target.cmake

 set(debuggers none ide gdb lldb ddd valgrind callgrind)
 set(models none shell
 	if750a iris iris_opt_flow iris_opt_flow_mockup iris_vision iris_rplidar iris_irlock iris_obs_avoid iris_rtps solo typhoon_h480
 	plane plane_cam plane_catapult
+	TF-G1


Since the rest of the models are using small case and underscores, could we change this? Maybe tfg1

Is it at least possible to leave it at tf_g1? Full name of that UAV is ThunderFly TF-G1.

What about tf-g1 ? I suggest it because in other models in list underscore is used to denote the model variant. But the full name of our model is TF-G1 including the hyphen. (There are much more models in development including TF-G2, TF-G3.. etc.) The letter case does not matter for that.

Renamed to tf-g1

ROMFS/px4fmu_common/mixers-sitl/autogyro_sitl.main.mix

Tools/sitl_run.sh

TSC21

@kaklik are you open that we create a repo under the PX4 org called PX4-FlightGear-Bridge, where you can push the bridge side and then include it here as a submodule? It's being seen as the correct architectural approach.

slimonslimon · 2020-03-31T20:55:00Z

Okey. We will move the bridge there.

But still remains the problem with cmake scripts and simulator LockStep and lists of supported vehicles per simulator. Any Idea?

TSC21 · 2020-03-31T20:57:31Z

Okey. We will move the bridge there.

But still remains the problem with cmake scripts and simulator LockStep and lists of supported vehicles per simulator. Any Idea?

We can solve that step by step. As far as I can tell this is WIP.

slimonslimon · 2020-03-31T21:16:08Z

Okey, I will prepare this step tomorow.

hamishwillee · 2020-03-31T21:22:22Z

This is cool. When this is done, we'll need some docs for environment setup, what is supported, how to use.

In the first instance, probably just a page like - http://dev.px4.io/master/en/simulation/gazebo.html but with setup information for different OS.

For reference, these are the main touchpoints for different platform setup docs/simulation:

kaklik · 2020-03-31T21:33:26Z

@kaklik are you open that we create a repo under the PX4 org called PX4-FlightGear-Bridge, where you can push the bridge side and then include it here as a submodule? It's being seen as the correct architectural approach.

Ok, my opinion is that the best and easier way how to achieve this is the following: We create a new repo named PX4-FlightGear-Bridge under our organization. You can immediately fork that repository in the PX4 organization. Then we make pull-request or you itself should make a submodule link to your Firmware repository.

TSC21 · 2020-03-31T21:42:18Z

@kaklik are you open that we create a repo under the PX4 org called PX4-FlightGear-Bridge, where you can push the bridge side and then include it here as a submodule? It's being seen as the correct architectural approach.

Ok, my opinion is that the best and easier way how to achieve this is the following: We create a new repo named PX4-FlightGear-Bridge under our organization. You can immediately fork that repository in the PX4 organization. Then we make pull-request or you itself should make a submodule link to your Firmware repository.

I don't see where that is easier: that will basically result in two more repositories to maintain, one by you and you only, and another (the PX4 fork) to be maintained by you and us. I think it is preferable that this is under an org where the maintenance responsibilities can be shared.

Regarding the submodule - that needs to be something part of this PR, so I ask you to do that yourselves. I will create the repo tomorrow and give you both write access to it (if I am able to, otherwise it will have to be someone with admin previlieges in the PX4 org). Then you can push the bridge there, if you agree.

kaklik · 2020-03-31T23:06:10Z

@kaklik are you open that we create a repo under the PX4 org called PX4-FlightGear-Bridge, where you can push the bridge side and then include it here as a submodule? It's being seen as the correct architectural approach.

Ok, my opinion is that the best and easier way how to achieve this is the following: We create a new repo named PX4-FlightGear-Bridge under our organization. You can immediately fork that repository in the PX4 organization. Then we make pull-request or you itself should make a submodule link to your Firmware repository.

I don't see where that is easier: that will basically result in two more repositories to maintain, one by you and you only, and another (the PX4 fork) to be maintained by you and us. I think it is preferable that this is under an org where the maintenance responsibilities can be shared.

Regarding the submodule - that needs to be something part of this PR, so I ask you to do that yourselves. I will create the repo tomorrow and give you both write access to it (if I am able to, otherwise it will have to be someone with admin privileges in the PX4 org). Then you can push the bridge there, if you agree.

I see the pro and cons of both ways. For us is mandatory to have multiple users access to the repository because few relatively random developers could experiment on branches in our repo. Therefore we probably could not avoid having a separate copy of that repository under our organization where we have privileges under our control. The main problem which could emerge additionally from the fork of our repository to PX4 organization is the unclear location of the upstream repo for third party contributors. But it should be resolved by submodule path pointing to your fork of the repository under the PX4 organization. I saw you have some repositories included as a submodule in that way. The jMAVSim is one example.

TSC21 · 2020-04-02T21:40:49Z

@kaklik I just took a look at your repo and seems that we might have a licensing issue, since you use GPL license and the PX4 ecosystem overall uses BSD-3clause or compatible. I am not sure we can include it as a submodule that way.

slimonslimon · 2020-04-03T22:44:50Z

In last few commits I tried to solve problem with lockstep disabling for flightgear-bridge. I created a new label for px4_sitl board, which is copy of default, but disables lockstep of simulation.
Then I improved sitl_targets.cmake, and allow gazebo and jMAVSim targets only if lockstep is enabled, and flightgear targets only if it is disabled.

I think, that gazebo and jMAVSim can work correctly without any other modification only if lockstep is enabled. Is it correct?

(and I fixed build of external project, after migration into module)

TSC21 · 2020-04-04T08:56:41Z

@slimonslimon @kaklik are you planning to update your repo's license or not? I think you are ignoring something that truly signifies a Go or No-Go regarding this PR.

slimonslimon · 2020-04-04T09:20:05Z

@TSC21 I'm trying ti solve building and running problems these days. I'm a programmer not a lawyer. I dont know much about licencnces.
(problably by using GitHub, you are agreeing with Microsoft EULA, and all codes shared here is property of Microsoft --- (joke) )

I think @kaklik will change licence as soon as he have time.

Jaeyoung-Lim · 2020-04-25T09:34:41Z

@kaklik @slimonslimon It is really cool that you are improving the flight gear integration.

However, could we freeze this branch and do squash /cleanups so that we can merge this branch?

slimonslimon · 2020-04-25T09:52:08Z

@Jaeyoung-Lim, yesterday we spend lot of time, by debuging the FG connection, but the result is, that problems are probably not in bridge but in FG. ( Flight gear is not so good :-( ).

I will do the squash of commits at this weekend.

Jaeyoung-Lim · 2020-04-25T22:26:33Z

@kaklik @slimonslimon I have tried the rascal vehicle with flightgear 2019.1.1 on Ubuntu bionic.

Not sure if this is something regarding my setup, but here are the problems I have encountered.

It results in a flyaway in mission mode. (See video below) Is this the expected outcome? what would be the correct way to test this?
On startup of the simulation, the vehicle is moving. Is this intended?

Also usability related discussions are being tracked in ThunderFly-aerospace/PX4-FlightGear-Bridge#5

kaklik · 2020-04-26T11:32:52Z

It results in a flyaway in mission mode. (See video below) Is this the expected outcome? what would be the correct way to test this?

We noticed this also, but it seems to be not related to FlightGear connection. It is probably some bug in the PX4 mission solving algorithm. It happens sporadically mainly in situations where the airplane sits on the ground and is oriented directly away from mission beginning takeoff waypoints. The expected behavior is the following:

* On startup of the simulation, the vehicle is moving. Is this intended?

Yes we now that, you have probably used the Rascal model with a combustion engine. The thrust generated by the propeller in idle RPM is large enough to make airplane moving. It could be solved in case PX4 is able to handle gear brakes. But this is not available as I know. The current solution is the use of model with electric engine.

Add flightgear_bridge submodule. Add traget px4_sitl_nolockstep with disabled LOCKSTEP simulation. Add flightgear viewer targets and startup scripts Add a few posible vehicles plane (rascal), autogyro (tf-g1), and rover (tf-r1))

Jaeyoung-Lim · 2020-04-27T16:26:39Z

@kaklik I have installed the model from the repo you have pointed to - How can I use the electric engine model?

roman-dvorak · 2020-04-27T17:01:56Z

How can I use the electric engine model?
The gas and the electric motor has a different make target.

Combustion engine:
make px4_sitl_nolockstep flightgear_rascal

Electric motor:
make px4_sitl_nolockstep flightgear_rascal-electric

The electric motor support is in master since yesterday. So you need to install the latest daily-build of FlightGear.

Jaeyoung-Lim · 2020-04-27T17:06:41Z

@roman-dvorak Okay, where can I get the latest daily-build of flight gear? Please forgive me if these are stupid questions, but as I am not familiar with flightgear, it feels like there are a lot of moving parts.

I have been using flightgear 2019.1.1 disributed with ppa:saiarcot895/flightgear . Does this mean that this cannot be used?

Could you document the exact versioning / system that this has been tested in the readme?

kaklik · 2020-04-27T17:08:42Z

@roman-dvorak Okay, where can I get the latest daily-build of flight gear? Please forgive me if these are stupid questions, but as I am not familiar with flightgear, it feels like there are a lot of moving parts.

Could you document the exact versioning / system that this has been tested in the readme?

The location where you get the daily build of FG is pointed from the Rascal model readme

slimonslimon · 2020-04-27T17:25:25Z

@Jaeyoung-Lim, @kaklik is preparing more detailed documentation for documentation web pages, because it can be maintainted better, than readme in repo (I think). The readme will be updatet soon by @kaklik .

There are lots of problems with FlightGear (versions, data-versions, lots of parameters, undocumended feautres, documentation by some posts on wiki, or forum, single thread implemntation from previous century, etc.). We probably will not be able to write down good and complente documentation for flightgear. But We maybe will try wrote some Introduction to flightgear along with documentation of using bridge with PX4.

Jaeyoung-Lim · 2020-04-27T17:43:46Z

@slimonslimon Thanks, I totally agree. We don't need to document flight gear. I think for a start, a "bullet proof" step by step process to get it up and running will be already really good. I seem to keep running in to problems while depending on the readme of the px4-flightgear-bridge.

Anyway, I would like to get this in @dagar @TSC21 would it be possible to merge this to move forward?

bkueng

Looks pretty good and almost ready to merge.

Do you plan to add lockstep support?

bkueng · 2020-04-28T06:54:57Z

Tools/setup/ubuntu.sh

@@ -203,6 +203,10 @@ if [[ $INSTALL_SIM == "true" ]]; then
 		protobuf-compiler \
 		;

+	# FlightGear
+	sudo add-apt-repository -y -u ppa:saiarcot895/flightgear
+	sudo DEBIAN_FRONTEND=noninteractive apt-get -y --quiet install flightgear


@Jaeyoung-Lim @kaklik this is still unanswered, and I agree, it should be optional / a separate script.

bkueng · 2020-04-28T06:55:33Z

Tools/sitl_run.sh

@@ -121,6 +121,13 @@ elif [ "$program" == "gazebo" ] && [ ! -n "$no_sim" ]; then
 		echo "You need to have gazebo simulator installed!"
 		exit 1
 	fi
+elif [ "$program" == "flightgear" ] && [ -z "$no_sim" ]; then
+	echo "FG setup"
+    cd "${src_path}/Tools/flightgear_bridge/"


Indentation: use tabs (below too)

bkueng · 2020-04-28T06:56:46Z

platforms/posix/cmake/sitl_target.cmake

@@ -146,6 +161,38 @@ foreach(viewer ${viewers})
 	endforeach()
 endforeach()

+#add flighgear targets
+if( ENABLE_LOCKSTEP_SCHEDULER STREQUAL "no")
+    set(models


Indentation: tabs

slimonslimon · 2020-04-28T10:36:32Z

@bkueng I think, it is not posilbe to setup lockstep simulation with FlightGear by this way (communication over generic protocol), because I dont know how to stop the simulation of FG. So we decided to create _nolockstep target and connect FG targets to it.

…ocumentation.

…udes models

…PX4Firmware into flightgear

slimonslimon · 2020-04-28T21:25:19Z

I hope I fixed every 4space->tab.

Then we added model into bridge as submodules. It should help to do "fisrt run" as simple as posible. Some notes are in updated README of Bridge. More Detailed documantation is under developement by @kaklik

bkueng

Thanks for all the good work!

Too bad there's no easy way to do lockstep.

kaklik · 2020-05-18T13:52:27Z

Documentation of FlightGear PX4 support is now available in PX4Devguide

TSC21 requested review from Jaeyoung-Lim, LorenzMeier, dagar and julianoes March 30, 2020 23:33

TSC21 added the Admin: Enhancement (improvement) 💡 label Mar 30, 2020

dagar reviewed Mar 31, 2020

View reviewed changes

Tools/flightgear_bridge/src/fg_communicator.cpp Outdated Show resolved Hide resolved

dagar reviewed Mar 31, 2020

View reviewed changes

Tools/flightgear_bridge/README Outdated Show resolved Hide resolved

dagar reviewed Mar 31, 2020

View reviewed changes

ROMFS/px4fmu_common/init.d-posix/17001_TF-G1 Outdated Show resolved Hide resolved

Jaeyoung-Lim reviewed Mar 31, 2020

View reviewed changes

kaklik mentioned this pull request Mar 31, 2020

Simulation with pixhawk and flightgear #10425

Closed

TSC21 reviewed Mar 31, 2020

View reviewed changes

kaklik mentioned this pull request Apr 3, 2020

Unhandled case of FlightGear supported a subset of the models ThunderFly-aerospace/PX4-Autopilot#22

Closed

TSC21 requested a review from Jaeyoung-Lim April 4, 2020 08:59

weekly-digest bot mentioned this pull request Apr 26, 2020

Weekly Digest (19 April, 2020 - 26 April, 2020) #14761

Closed

kaklik mentioned this pull request Apr 26, 2020

What is the correct way to install the models? ThunderFly-aerospace/PX4-FlightGear-Bridge#5

Closed

Add support for FlighGear SITL.

3199cd2

Add flightgear_bridge submodule. Add traget px4_sitl_nolockstep with disabled LOCKSTEP simulation. Add flightgear viewer targets and startup scripts Add a few posible vehicles plane (rascal), autogyro (tf-g1), and rover (tf-r1))

slimonslimon force-pushed the flightgear branch from 705bb2c to 3199cd2 Compare April 26, 2020 18:30

Jaeyoung-Lim mentioned this pull request Apr 26, 2020

Fixed wing mission sometimes result in a flyaway ThunderFly-aerospace/PX4-FlightGear-Bridge#10

Open

Jaeyoung-Lim previously approved these changes Apr 26, 2020

View reviewed changes

bkueng reviewed Apr 28, 2020

View reviewed changes

FlightGear installation removed. The steps will be explaided in the d…

69247b8

…ocumentation.

kaklik dismissed Jaeyoung-Lim’s stale review via 69247b8 April 28, 2020 21:10

slimonslimon added 3 commits April 28, 2020 23:13

FlightGear Bridge: FIX idents to tabs. Update FG Bridge - now it incl…

e751c21

…udes models

Merge branch 'flightgear' of https://github.com/ThunderFly-aerospace/…

4f32ea9

…PX4Firmware into flightgear

Merge remote-tracking branch 'upstream/master' into flightgear

307c928

bkueng approved these changes Apr 29, 2020

View reviewed changes

bkueng merged commit dfa5ca1 into PX4:master Apr 29, 2020

kaklik mentioned this pull request Apr 29, 2020

Flightgear Simulator support documentation PX4/PX4-Devguide#1033

Merged

Jaeyoung-Lim mentioned this pull request Apr 29, 2020

Switch flightgear bridge submodule to px4 organization #14789

Merged

weekly-digest bot mentioned this pull request May 3, 2020

Weekly Digest (26 April, 2020 - 3 May, 2020) #14814

Closed

FlightGear simulator support #14539

FlightGear simulator support #14539

Conversation

kaklik commented Mar 30, 2020 • edited Loading

TSC21 commented Mar 30, 2020 • edited Loading

dagar commented Mar 30, 2020

dagar commented Mar 31, 2020

TSC21 commented Mar 31, 2020 • edited Loading

Antiheavy commented Mar 31, 2020

slimonslimon commented Mar 31, 2020

Jaeyoung-Lim left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TSC21 left a comment

Choose a reason for hiding this comment

slimonslimon commented Mar 31, 2020

TSC21 commented Mar 31, 2020

slimonslimon commented Mar 31, 2020

hamishwillee commented Mar 31, 2020

kaklik commented Mar 31, 2020

TSC21 commented Mar 31, 2020 • edited Loading

kaklik commented Mar 31, 2020 • edited Loading

TSC21 commented Apr 2, 2020 • edited Loading

slimonslimon commented Apr 3, 2020 • edited Loading

TSC21 commented Apr 4, 2020

slimonslimon commented Apr 4, 2020 • edited Loading

Jaeyoung-Lim commented Apr 25, 2020

slimonslimon commented Apr 25, 2020

Jaeyoung-Lim commented Apr 25, 2020 • edited Loading

kaklik commented Apr 26, 2020 • edited Loading

Jaeyoung-Lim commented Apr 27, 2020 • edited Loading

roman-dvorak commented Apr 27, 2020

Jaeyoung-Lim commented Apr 27, 2020 • edited Loading

kaklik commented Apr 27, 2020

slimonslimon commented Apr 27, 2020 • edited Loading

Jaeyoung-Lim commented Apr 27, 2020

bkueng left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

slimonslimon commented Apr 28, 2020

slimonslimon commented Apr 28, 2020

bkueng left a comment

Choose a reason for hiding this comment

kaklik commented May 18, 2020 • edited Loading

kaklik commented Mar 30, 2020 •

edited

Loading

TSC21 commented Mar 30, 2020 •

edited

Loading

TSC21 commented Mar 31, 2020 •

edited

Loading

TSC21 commented Mar 31, 2020 •

edited

Loading

kaklik commented Mar 31, 2020 •

edited

Loading

TSC21 commented Apr 2, 2020 •

edited

Loading

slimonslimon commented Apr 3, 2020 •

edited

Loading

slimonslimon commented Apr 4, 2020 •

edited

Loading

Jaeyoung-Lim commented Apr 25, 2020 •

edited

Loading

kaklik commented Apr 26, 2020 •

edited

Loading

Jaeyoung-Lim commented Apr 27, 2020 •

edited

Loading

Jaeyoung-Lim commented Apr 27, 2020 •

edited

Loading

slimonslimon commented Apr 27, 2020 •

edited

Loading

kaklik commented May 18, 2020 •

edited

Loading