Airsim: Fixed Wing Aircraft

[AOS55]

Fixed Wing Vehicle Integration

I am working on adding a FixedWing aircraft class into Airsim, so far I have been documenting my work under issue #2508 but as suggested by @rajat2004 it would be usefult to move this work to a new issue so as to improve visibility for others to work on.

Work so far

Please see this post for a detailed breakdown of what has been added in my forked Airsim repository under the fixedwing branch. I will aim to keep updates on this issue of new files, classes, methods & functions with a view to write comprehensive documentation as the code begins to get to a state where it can be merged back into the master branch on the main repo.

Since the last update post on #2508 I have been updating the FixedWingLibClient files to enable communication with Ardupilot. A linked issue has been opened within the ArduPilot Repo.

FixedWing Branch State

• Compilable from Visual Studio: 🟢
• Runs alone in UE4: 🟢
• Runs with ArduPilot and Mavlink in UE4 over network: 🔴
• Model validated with real comparison: 🔴

Known issues

• I can't compile the code from source in Visual Studio please see the chain back in #2508 for what we have tried so far. I think it is most likely a mistake I have made in the source code. <-- This is currently the most pressing issue.
• I naievly initially implemented the control surfaces at seperate functions getElevatorSignal() etc. I am beginning to realise as I work through the control implementation this was not a good way to go about this and the program is already well setup to accept a more conventional control vector, i.e. the u vector in state-space form. I am planning to go back and correct this to a 4 row u vector.
• The Core APIs I effectively copied over when setting up the controller files include several aspects that I don't think make sense for a Fixed Wing aircraft, for example commandVelocityHold uses the function moveByLocalVelocity that takes a boolean yaw mode switch and rate as a command these are set as false and 0 in the current implementation. But, moveByLocalVelocity may be better of if rewritten for fixedwing.

Planned Future Work

Initially I am aiming to work to resolve all the known issues and turn all the 🔴 in the state to 🟢. Following from this I will aim to add the following functionality:
[ ] Construct a similar Python API as in multirotor <-- hopefully a short term objective
[ ] Implement Undercarriage for fixedWingLandings
[ ] Deep Reinforcement Learning (DRL) based FW landings <-- main PhD objective, expect to write & publish a paper based on this
[ ] Validate model and control on real UAV and FW aircraft, ties in with above.

Motivation

Principally this is for my PhD at the University of Bristol where I am aiming to use a combination of computer vision and Deep Reinforcement Learning to train an autonomous fixedwing agent/aircraft to navigate to and safely land in an unknown location. This is both with and without power and on a range of fixedwing aircraft including fixedWing UAVs, gliders & multiengine light piston aircraft (<5700Kg). Not only this but when discussing AirSim with my colleagues we believe that having a fixedWing simulator capable of highfidelity graphics and SITL that is efficient will be of great benefit.

Ongoing Development

Several users have already been realy helpful (@rajat2004 😀), if anyone has any ideas about how to solve some of the issues I have described above all help is greatly appreciated. In particular if anyone is able to have any success compiling the fixedwing source please let me know as I'm a little stumped 😕 as to why it won't compile.

[rajat2004]

I had a try at compiling your branch, the error message was really quite useless.
Opened https://github.com/AOS55/AirSim-1/pull/1 which fixes that and brings us back to normal compilation errors with understandable messages (for now)

[AOS55]

Progress Update

Aircraft Physics Control Construction

I have been continuing to work on the FixedWingPhysics simulation aiming to resolve compilation errors. I have vectorised the control surfaces so ideally they behave as a u tyoe vector. With this I introduced a new file Aeroplane.hpp that instants each control from the ControlSurface.hpp file as a PhysicsBodyVertex class. I have not introduced the thrust vector yet but this shouldn't be too much of a challenge.

Aircraft links to the structs in AircraftParams.hpp and applies the aero-forces via setWrench. Most fixedwing dynamic models/databases, define the forces and moments around the CG, as dynamicDerivatives. setWrench applies these and then is updated in the loop by FixedWingPhysicsBody.hpp, I'm a little lost as to how the PhysicsBody class updates the aircrafts pose via fastPhysicsEngine. The way I've set up the classes may also be an antipattern and I might need to refactor some of the structs, please let me know your thoughts on how you might setup the structures.

Compilation error

When I run the repo from visual studio I get the following error :

Error C4717 'msr::airlib::ArduPlaneApi::resetImplementation': recursive on all control paths, function will cause runtime stack overflow Blocks C:\Users\quessy\Documents\Unreal Projects\AirSim\Unreal\Environments\Blocks\Plugins\AirSim\Source\AirLib\include\vehicles\fixedwing\firmwares\ardupilot\ArduPlaneApi.hpp 57

Im not sure what this error is being caused by, I'm guessing there is no termination condition in the recursive call. If anyone has experienced this before I'd love to get your thoughts.

[rajat2004]

That's happening cause the function is calling itself here - https://github.com/AOS55/AirSim-1/blob/FixedWing/AirLib/include/vehicles/fixedwing/firmwares/ardupilot/ArduPlaneApi.hpp#L54
It should instead be calling FixedWingApiBase::resetImplementation(), from it's parent class

Note that I haven't tested this myself yet

[AOS55]

Thanks yep that was it was quite obvious now I think about it in more detail. It several unresolved external symbol errors now but I think there a case of sorting out further problems with the API.

[AOS55]

Does anyone have any thoughts on this error coming from FixedWingApiBase.hpp, I thought it was to do with the link between the base class and Mavlink/Px4 implementation override. I can't see anything untawards though:
LNK2001 unresolved external symbol "protected: virtual float __cdecl msr::airlib::FixedWingApiBase::getAutoLookahead(float,float,float,float)const " (?getAutoLookahead@FixedWingApiBase@airlib@msr@@MEBAMMMMM@Z) Blocks C:\Users\quessy\Documents\Unreal Projects\AirSim\Unreal\Environments\Blocks\Intermediate\ProjectFiles\Module.AirSim.cpp.obj 1

[rajat2004]

Functions seem to be missing, are all the files uncommented in the AirLib.vcxproj?

[AOS55]

Thats a good point I've uncommented them now, from AirLib.vcxproj, but Im still getting the same link errors from the compiler. When running build.cmd I also get some errors in the command prompt that are slightly different, perhaps these are what needs to be looked at. These are quite clearly what I should have been looking at, I didn't appreciate the importance of the API src client, server and base files.

[AOS55]

Resolved all build errors now except for one rather unusual one:
"C:\Users\quessy\Documents\Unreal Projects\AirSim\AirSim.sln" (default target) (1) -> "C:\Users\quessy\Documents\Unreal Projects\AirSim\AirLib\AirLib.vcxproj" (default target) (12) -> (ClCompile target) -> C:\Users\quessy\Documents\Unreal Projects\AirSim\AirLib\deps\rpclib\include\rpc\msgpack\v1\object.hpp(202,11): error C2039: 'msgpack_pack': is not a member of 'Eigen::Matrix<float,3,1,0,3,1>' [C:\Users\quessy\Documents\Unreal Projects\AirSim\AirLib\AirLib.vcxproj]

Not sure where this one links to as when I look at the location of the error in object.hpp which I'm not sure where it lives in the repo as dependencies folder not included in push/pull requests.

[rajat2004]

The RPC error was due to the fact that it doesn't know how to pack the Vector3r object, need to convert it into the struct defined in RpcLibAdaptorsBase and then pass it. Opened https://github.com/AOS55/AirSim-1/pull/4 which fixes that, and adds the files to CMake.
After this AirLib compiles, but there are still lots of errors when building the entire Blocks env, undefined references in FixedWingApiBase.cpp, due to function declarations in .hpp, and usage of commented out methods

[AOS55]

Great thanks very much Ill take a look at those errors today, I merged the issue back into fixedwing and have no build.cmd errors on my end too.

[AOS55]

Any thoughts on why I'm getting the following include/visibility related build error from in visual studio? I can see the source file UdpSocket.hpp is still on the repo, could it be related to cmake changes?

• From Visual Studio: C1083 Cannot open include file: 'UdpSocket.hpp': No such file or directory Blocks C:\Users\quessy\Documents\Unreal Projects\AirSim\Unreal\Environments\Blocks\Plugins\AirSim\Source\AirLib\include\vehicles\car\firmwares\ardurover\ArduRoverApi.hpp

• From Output C:\Users\quessy\Documents\Unreal Projects\AirSim\Unreal\Environments\Blocks\Plugins\AirSim\Source\AirLib\include\vehicles/car/firmwares/ardurover/ArduRoverApi.hpp(20): fatal error C1083: Cannot open include file: 'UdpSocket.hpp': No such file or directory

[rajat2004]

That's very strange, Windows shouldn't be affected AFAIK since it uses the .sln files. And if this were a problem, then it would have appeared way earlier since support for Rover has been present for many months
Does this appear when running build.cmd?

[AOS55]

No thats the unusual thing build.cmd doesnt present any errors when run

[rajat2004]

Hmm, maybe try running clean_rebuid.cmd from the root directory, that should rebuild everything.
Do commit any changes made in the files present in the Blocks directory like in the AirLib folder before running though

[AOS55]

Great thanks that seems to have resolved it back to linking problems probably due to decleration again.

[rajat2004]

Nice! Still have no idea why VS decided to remove the header file
Side note, this does somewhat bring into mind that GitHub issues might not be the best way to communicate, especially on smaller problems. Maybe something for future

[AOS55]

Yeah not sure its unusual.
Yes certainly, I'm surprised there isn't a microsoft/AirSim slack setup or equivalent for more direct communication. As you said something for the future.

[rajat2004]

There is a Facebook group, but I myself haven't used it since a long time.
AP uses Discord (earlier Gitter) and has a forum as well, similar with PX4. Maybe after there is more activity and members. Having something like this would definitely reduce the number of issues also, since more confirmed issues will be created rather than duplicate and support ones

[AOS55]

Yes I agree thats a good idea, the documentation for AirSim would need to reflect this too as there is not an obvious point of contact when onboarding new users/developers with the application.

Also after commenting out the linking errors in the application I have managed to compile through to the blocks environment 😀.

[rajat2004]

Awesome, now comes the probably more difficult part of modelling, physics and making sure everything works!
Having a more direct method of communication will also increase community interaction a lot. Which platform to select, etc will have to be decided by the maintainers though, might require collecting some opinions from the users

[AOS55]

Yes I agree, would you like to open up a communication issue, I'm not sure if you can do a poll on github?

[rajat2004]

Don't think I'm the best person to open such a issue, a maintainer should do this probably. They'll also have to setup the platform and maybe maintain it (no other word is coming to my mind right now)
Github doesn't have polls AFAIK

[AOS55]

Yes that makes sense, a moderator or project manager sort of thing. Perhaps if you know anyone you could @ them into this issue so they can set it up. Ok sure you could always make the proposed solution as a comment and get people to vote 👍 or 👎 on the comment.

[rajat2004]

@madratman @saihv @ironclownfish @jonyMarino Do you think having another (more chat & voice type) communication platform will be worthwhile? This will definitely increase community interaction, and will probably reduce support issues.
Just wanted to know your opinions, and definitely don't want to increase your (already heavy) workload too much.
Looking forward to hearing from you!

[rajat2004]

@AOS55 AirLib is actually not compiling for me, getting some undeclared identifier errors for the function declarations which have been commented out. Here's a Travis build - https://travis-ci.com/github/rajat2004/AirSim/builds/181419292, even the Windows build fails.
Did some files not get committed when commenting out the API methods?

Would also recommend activating Travis on your Github repositories (atleast Airsim), that has saved me a few times when making some changes which don't compile on Windows, or breaking something else. (Side note, I did break the Windows build in my first contribution to Airsim (and others later on also), that was a big motivation to get Travis setup properly on Airsim)

[AOS55]

@rajat2004 hmm ok, this is interesting could you please send me the identifier errors you are getting I will cross-check them on my local machine, I just ran update_to_git.bat and had no further changes and I also ran update_from_git.bat in Blocks and it still compiles ok on my end. A couple of thoughts:

• Are you using UE4.25.3 or UE4.24.3? I have been using 4.25.3 I don't know if this would effect the build or travis.
• Did you try rebuilding from the root directory as that seemed to be what caused mine to compile in the first instance?

Nice Idea, I have setup Travis with my branch, and it also appears to fail. Looking at the job log it has the following on line 1457. I wonder if this is unity related or just what the .travis.yml script should print to the command line.

The command "if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then ./setup.sh; ./build.sh || travis_terminate 1; echo "Starting Unity Build!"; (cd Unity && ./build.sh || travis_terminate 1); elif [[ "$TRAVIS_OS_NAME" == "windows" ]]; then export PATH=$MSBUILD_PATH:$PATH_FIX:$PATH; cmd.exe //C 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat' amd64 '&&' build.cmd '&&' cd Unity '&&' build.cmd; elif [[ "$TRAVIS_OS_NAME" == "osx" ]]; then ./setup.sh; ./build.sh || travis_terminate 1; echo "Starting Unity Build!"; (cd Unity && ./build.sh || travis_terminate 1); fi" exited with 1.

[rajat2004]

Very strange that it works on your machine, these are the errors I'm getting -

/home/rajat/Github/AirSim-FixedWing/AirLib/src/vehicles/fixedwing/api/FixedWingApiBase.cpp:514:9: error: use of undeclared identifier 'safetyCheckVelocity'
    if (safetyCheckVelocity(Vector3r(vx, vy, vz)))
        ^
/home/rajat/Github/AirSim-FixedWing/AirLib/src/vehicles/fixedwing/api/FixedWingApiBase.cpp:526:9: error: use of undeclared identifier 'safetyCheckDestination'
    if (safetyCheckDestination(dest))
        ^
/home/rajat/Github/AirSim-FixedWing/AirLib/src/vehicles/fixedwing/api/FixedWingApiBase.cpp:538:9: error: use of undeclared identifier 'safetyCheckVelocity'
    if (safetyCheckVelocity(getVelocity()))
        ^
/home/rajat/Github/AirSim-FixedWing/AirLib/src/vehicles/fixedwing/api/FixedWingApiBase.cpp:562:9: error: use of undeclared identifier 'safetyCheckVelocity'
    if (safetyCheckVelocity(getVelocity()))
        ^
[ 80%] Building CXX object AirLib/CMakeFiles/AirLib.dir/home/rajat/Github/AirSim-FixedWing/AirLib/src/vehicles/multirotor/api/MultirotorApiBase.cpp.o
[ 81%] Building CXX object AirLib/CMakeFiles/AirLib.dir/home/rajat/Github/AirSim-FixedWing/AirLib/src/vehicles/multirotor/api/MultirotorRpcLibClient.cpp.o
4 errors generated.
AirLib/CMakeFiles/AirLib.dir/build.make:230: recipe for target 'AirLib/CMakeFiles/AirLib.dir/home/rajat/Github/AirSim-FixedWing/AirLib/src/vehicles/fixedwing/api/FixedWingApiBase.cpp.o' failed
make[2]: *** [AirLib/CMakeFiles/AirLib.dir/home/rajat/Github/AirSim-FixedWing/AirLib/src/vehicles/fixedwing/api/FixedWingApiBase.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 83%] Linking CXX executable ../../output/bin/MavLinkTest
[ 83%] Built target MavLinkTest
/home/rajat/Github/AirSim-FixedWing/AirLib/src/vehicles/fixedwing/api/FixedWingRpcLibServer.cpp:116:45: error: no member named 'moveByManual' in 'msr::airlib::FixedWingApiBase'
        return getVehicleApi(vehicle_name)->moveByManual(vx_max, vy_max, z_min, duration);
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~  ^
1 error generated.

AirLib compilation doesn't depend on UE, Travis also doesn't have UE, it just tests whether AirLib, ROS wrapper compiles, and there's the recently added Azure Pipelines CI which compiles the entire Blocks project on Ubuntu and Windows and packages it.

Yup, I'm rebuilding from the root directory, ./clean.sh & ./build.sh.

That's just Travis printing the entire command which failed to run, the errors can be seen above it, starting from here

[AOS55]

Ok yeah, I was just looking at the code on my machine and I have those if statements at the lines the compiler called out still there, given I commented them out in the header file I would have expected an undeclared header error. I have commented them out now in the CPP file. Still waiting for Travis.

[AOS55]

Got some further travis build errors in FixedWingRpcLibServer.cpp commented out the moveByManual Function. This now succeeds for macOS and windows but fails for ubuntu 16.04 LTS and 18.04 LTS.

[rajat2004]

@AOS55 this was a problem with the CMake config in ROS wrapper, I've opened #2978 which fixes this. The reason's described there, and as to why it was missed, looks like not many people have named the folder something other than AirSim :)

[AOS55]

Thanks, yep, I should have left it as was, good inadvertent check though. Made equivalent commit to FixedWing branch.

I met with my PhD supervisor earlier and we had a couple of thoughts on what we need to continue developing Fixed Wing Airsim, let me know what you think should be our priorities over the next week and what we have missed:

• Have a runnable fixedwing model in AirSim, I have added a blueprint for a fixedWingPawn. I also have a 3D model of one of our FW UAVs I should be able to implement this as a material and mesh, just working out how to convert in maya.
• I tried to run the FW UAV by writing in settings.json -> "VehicleType": "arduplane" but received in UE4 There were no compatible vehicles created for current SimMode! Check your settings.json.. I'm not sure if that was an error in the json file or if it is related to the above issue or something deeper.
• We have a validated F-16 flight physics model from Heffely & Jewell in Matlab that can be used to test the fixedwing physics hpp file. I think it might be a good idea to setup some test cases so I can validate the flight physics functions. I'm not sure if a similar sort of thing was done to validate for the multirotor model?
• Validate and tune some of the controllers for the Ardupilot Mavlink API I'm not sure how much of this is already done in Arduplane? This will probably also be related to writing a python API but that is probably further into the horizon.

[rajat2004]

Nice! I'll try out the latest commits and have a look at the asset, but I don't have much experience with building models, etc so probably won't be of much help here.
Will test the settings issue too.

I'm not sure how the multirotor model was tested and validated, the maintainers would have a better idea since they wrote this :)
There are many very experienced people in the ArduPilot community who would know about building and validating the physics, might be useful to have a talk with them. I remember there was recently quite a bit of work done on XPlane and RealFlight which are used extensively for Plane simulations

[rajat2004]

Ok, so for the settings, I think there should be a new SimMode added for Plane, so the options would become like Multirotor, Car, ComputerVision & the new FixedWing (or something). This will require changes in a few places, maybe keep following places where "Multirotor" or others are used to compare the SimMode name, this commit can also be helpful - https://github.com/microsoft/AirSim/pull/2861/commits/faee309415fde2d946ad3cefdaafa9e7fb251f60 (From PR https://github.com/microsoft/AirSim/pull/2861), I've tried to make SimMode names constants like kVehicleType*.
For a shortcut right now, you could just add ArduPlane in https://github.com/microsoft/AirSim/blob/master/Unreal/Plugins/AirSim/Source/Vehicles/Multirotor/SimModeWorldMultiRotor.cpp#L95

[rajat2004]

@AOS55 Just tried out the latest commits, the fixedwing model looks awesome :heart_eyes:
For someone following, use UE 4.25, that's the version the assets are saved with. Some pics -

Side Note: Adding to the above parallel discussion going on about a new communication platform (having chat and preferably voice, video) Discord looks like a good option, creating a server's pretty easy, anyone can do it, and supports multiple chat & voice channels, and has video support also

[AOS55]

I have aimed to add the fixedwing class to the AirSimSettings.hpp file. arduplane should be set as the default FixedWing variable, referenced to static constexpr char const * kVehicleTypeArduPlane = "arduplane". This commit shows the changes I made to the repo. In particular I have added variable simmode_name == "fixedwing" to the createSimMode method in simHUD.cpp.

When I run airsim in unreal with "SimMode": "FixedWing" I get an error as follows:
Error at startup: invalid map<K, T> key.

UE4Editor-Win64-DebugGame.exe then logs exception thrown in VisualStudio and produces a breakpoint @ line 73 in AirSimGameMode.cpp. I think this is because it can't StartPlay as it doesn't know where the files are. I'm guessing I have not defined the _keys_ at some point, but not sure where this is? Could it be to do with the VehicleSettings method in AirSimSettings.hpp line 807?

Not sure if this has come up before?

[rajat2004]

Opened https://github.com/AOS55/AirSim-1/pull/5 which fixes a compilation error and the pawn path aka Invalid Key error
After this the ArduPilot Plane backend starts working!

[2020.08.29-18.05.26:678][971]LogTemp: Using UDP port 9003, local IP 127.0.0.1, remote IP 127.0.0.1 for sending sensor data
Using UDP port 9003, local IP 127.0.0.1, remote IP 127.0.0.1 for sending sensor data
[2020.08.29-18.05.26:678][971]LogTemp: Using UDP port 9002 for receiving rotor power
Using UDP port 9002 for receiving rotor power
Error while receiving aircraft control data - ErrorNo: -1
Error while receiving aircraft control data - ErrorNo: -1
...

However I'm seeing some problems with the assets, need to look into them-

[2020.08.29-18.05.26:125][971]LogActor: Warning: BP_CameraDirector_C /Game/FlyingCPP/Maps/UEDPIE_0_FlyingExampleMap.FlyingExampleMap:PersistentLevel.CameraDirector has natively added scene component(s), but none of them were set as the actor's RootComponent - picking one arbitrarily
1001[2020.08.29-18.05.26:128][971]LogLinker: Warning: While loading '../../../../../Github/AirSim-FixedWing/Unreal/Environments/Blocks/Plugins/AirSim/Content/Models/FixedWingUAV/BUDDI3D_1.uasset' failed to load '/AirSim/Models/FixedWingUAV/Budee': Can't find file.
1001[2020.08.29-18.05.26:129][971]LogLinker: Warning: While loading '../../../../../Github/AirSim-FixedWing/Unreal/Environments/Blocks/Plugins/AirSim/Content/Models/FixedWingUAV/BUDDI3D_1.uasset' failed to load '/AirSim/Models/FixedWingUAV/phong4': Can't find file.
[2020.08.29-18.05.26:135][971]LoadErrors: Failed to load /AirSim/Models/FixedWingUAV/Budee.Budee Referenced by FbxStaticMeshImportData_0
[2020.08.29-18.05.26:135][971]LoadErrors: Failed to load /AirSim/Models/FixedWingUAV/phong4.phong4 Referenced by BUDDI3D_1

Removed extra lines, some other preexisting problems with the Airsim master

Side note: I think these kind of errors like the PawnPath name can be reduced, made into constant vars like the vehicle types. The SimMode name changes like in the other PR if accepted would be a good step forward

[AOS55]

Thanks a lot, merged the commit back onto fixedwing branch.
I see the asset problems, and it now proceeds directly to the breakpoint, Ill start looking into what is not there.
Did you get the ArduPilot Plane backend output from the Visual Studio command line output?
Yes I agree reducing the PawnPath names to the same structure as teh vehicle types would make life simpler.

[rajat2004]

I'm on Linux :) So all the output comes on the terminal itself from where UE is launched, makes life simpler.
But more painful for debugging, VS is better for that. Output should be possible from there, but not sure.

Asset problems a PITA, was poking around with some Weather problems today

[AOS55]

Uh ok nice will probably switch back to linux at some point. That makes sense Ill take a closer look what was your settings.json file set as that might be it? I have this:
{
"SeeDocsAt": "https://github.com/Microsoft/AirSim/blob/master/docs/settings.md",
"SettingsVersion": 1.2,
"SimMode": "FixedWing"
}

Haha, ok sure that sounds like fun.

[rajat2004]

Yeah sorry, my settings.json -

{
  "SettingsVersion": 1.2,
  "SimMode": "FixedWing",
  "Vehicles": {
    "Plane": {
        "VehicleType": "ArduPlane",
        "UseSerial": false,
        "LocalHostIp": "127.0.0.1",
        "UdpIp": "127.0.0.1",
        "UdpPort": 9003,
        "ControlPort": 9002
    }
  }
}

Wouldn't call it fun per se, ran my system at full throttle though, packaging multiple times does that. Issue #2988 if interested
I progressed (more aptly regressed) from crashing binary to when API called, then when pressing Play and finally starting up itself plus compilation, in an infinite loop

[rajat2004]

Also, just remembered this, you'll want to use SteppableClock for AP, so need to add the simmode here - https://github.com/microsoft/AirSim/blob/master/AirLib/include/common/AirSimSettings.hpp#L1116
Not sure about PX4, but AP definitely would like SteppableClock

[AOS55]

Great thanks, just ran with that settings.json and got the same in the VS output.

Yes Im sure Ill take a look, and likewise the BLUEPRINTS are also new to me. It looks very frustrating Ill feedback if I can think of anything while debugging the FixedWing blueprints.

I was thinking about that today actually, yeah its certainly going to be needed at some point. Cool Ill add kVehicleTypePX4Plane into there and an or "FixedWing" in the if statement.

[AOS55]

Ive made some more progress with the errors and ArduPilot/ArduPlane. I renamed and updated the aircraft mesh within ardupilot on the fixedwing side this resolved most of the can't find file errors discussed earlier. I still have some of the earlier weather can't find errors described above as a current issue.

The following is the final outpu with ErrorNo: 10040, an error in red.
```[2020.08.30-09.41.01:179][159]LogTemp: Plane
[2020.08.30-09.41.01:184][159]PIE: Server logged in
[2020.08.30-09.41.01:186][159]LogTemp: Error while receiving aircraft control data - ErrorNo: 10040
[2020.08.30-09.41.01:186][159]PIE: Play in editor total start time 0.539 seconds.

I have updated the Arduplane SITL on the [FixedWing branch](https://github.com/AOS55/ardupilot) with an arduplane implementation. This can be compiled and run with WAF by typing: `sim_vehicle.py -v ArduPlane -f airsim-plane --console --map` within the ardupilot directory. This is yet to be merged with the main repo and is currently on a fork. 

Any thoughts on the error im getting `Error while receiving aircraft control data - ErrorNo: 10040`. Im not sure if the correct ports are exposed on the ArduPilot SITL side as it produces the following on start:

```SIM_VEHICLE: Run MavProxy
SIM_VEHICLE: "mavproxy.py" "--map" "--console" "--out" "127.0.0.1:14550" "--out" "127.0.0.1:14551" "--master" "tcp:127.0.0.1:5760" "--sitl" "127.0.0.1:5501"
RiTW: Starting ArduPlane : /home/quessy/ardupilot/build/sitl/bin/arduplane -S --model airsim-plane --speedup 1 --defaults /home/quessy/ardupilot/Tools/autotest/default_params/plane.parm,/home/quessy/ardupilot/Tools/autotest/default_params/airsim-plane.parm -I0
xterm: cannot load font "10x20"
xterm: cannot load font "-Misc-Fixed-bold-R-*-*-13-120-75-75-C-60-ISO8859-1"
xterm: cannot load font "-Misc-Fixed-medium-R-*-*-13-120-75-75-C-120-ISO10646-1"
xterm: cannot load font "-Misc-Fixed-bold-R-*-*-13-120-75-75-C-120-ISO10646-1"
xterm: cannot load font "-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1"
Connect tcp:127.0.0.1:5760 source_system=255

Not sure if it is connecting to 14550 rather than 9002, 9003 or is 14550 the Xming graphical port?

[rajat2004]

Awesome, thanks for the asset fix! Will try out the new commits and the AP branch soon.
From a brief search, the error code 10040 seems to indicate that the packet sizes are not matching. The plane_packet sent by AP is defined here- https://github.com/ArduPilot/ardupilot/commit/83ea2fc1f30d3cf4c763b2015c13be98e828fdb9, and has an extra tla field which is not defined on the AirSim side, so the buffer size is too small and hence the error. Fixing that should solve the problem, but need to test

[AOS55]

Cool that was actually it commented out that line and then the asset loaded into unreal, see image below. I have set the axis slightly wrong on the static mesh so the front is currently the side, think I need to move the camera back a bit as the defaultUAV model is much larger than the default quadcopter.

Im going to start analyzing the physics model and I will add in some sensible parameters for the aircraft. This skywalker paper offers quite a nice american derivative non-linear model for the skywalker UAV that will be fine for now. They have also made an opensource matlab project for their results.

Im also going to have a think about setting up some kind of hpp or python output test file that can work out whether or not the model is correctly implemented, perhaps by running some quasi-sim based flight test. Or there might be something more direct by running the simulation hpp files in isolation and giving them a datum input & output.

[AOS55]

Just realised that the skywalker x8 is a blended wing body design and doesn't have seperate aileron elevator and rudder controls. I might implement the aircraft dynamics as described for now and artificially add in control surfaces just to see how it performs.
There are other models I might take a look at there is a nice collection in Heffely and Jewell despite it being a pain to read through. Aircraft Control and Simulation also has an F16 fixedwing model. There might be a case of scaling back a generic fixedwing dynamic model for a generic-UAV model if setup in a conventional configuration. There is quite a lot out there on similtude for dynamics.

[samuelctabor]

An option you might want to consider would be using the same coefficients as the ArduPilot built-in fixed-wing simulator coefficients defined here https://github.com/ArduPilot/ardupilot/blob/master/libraries/SITL/SIM_Plane.h

This would have the advantage that the ArduPlane tuning would be correct from the start, and if it flies well using these that would be basic validation of physics implementation.

[AOS55]

Cool thanks a lot, didn't realised that existed I will just use that makes life much easier. Ill set that up as the genericAircraft on the airsim side too.

[AOS55]

I've added the fixedwing aircraft from SIM_Plane.h along with the model from the Skywalker X8 paper. Im going to start looking at running some tests today and using ardupilot in some more detail. I might also start looking at how to expose the API to a python client to make a helloPlane.py type script.

[AOS55]

Does anyone know how to change the initialization altitude in the blocks environment. I have tried initializing the aircraft with the following JSON but it keeps starting the aircraft on the ground:

{
  "SettingsVersion": 1.2,
  "SimMode": "FixedWing",
  "Vehicles": {
    "Plane": {
      "VehicleType": "ArduPlane",
      "UseSerial": false,
      "LocalHostIp": "127.0.0.1",
      "UdpIp": "127.0.0.1",
      "UdpPort": 9003,
      "ControlPort": 9002,
      "OriginGeopoint": {
        "Latitude": 47.641468,
        "Longitude": -122.140165,
        "Altitude": -800
      }
    }

  }
}

I thought this would start at 800m above the ground but is still starting on the floor.

[rajat2004]

OriginGeopoint goes outside the Vehicles section, along with SimMode, SettingsVersion

[AOS55]

Great thanks, it now looks sort of like it is dropping in but immediately ends on the floor, do you set the fps from the settings.json as the mavlink console says FPS avg=333.33 Im wondering if its running so fast that you cant see it descending. Or do you know of a method to get a log from ardupilot or airsim

[rajat2004]

The 333.33 Hz FPS is the physics rate, not the visual one. FastPhysicsEngine runs at that fixed rate, can be slowed using ClockSpeed. I'm not sure what you mean by dropping immediately, the Alt reported by Mavproxy windows goes to 0? A screen capture would be nice, will try it out soon.
AP stores logs in a folder called logs, in the current directory

[AOS55]

Ok that makes sense, yes sorry should have been clearer as the object renders into unreal it looks like the tail comes down and then it lies flat on the ground but that could just be it initializing. I have a screen grab here, great thanks.

I can't see the logs folder is it in the ardupilot directory or the airsim directory, I see mav.tlog but that seems to be a binary or is unreadable with cat mav.tlog.

I also notice that Ardupilot calls APM: Ground start complete in the console do you know what that does or is it just a sensor initialization command?

[rajat2004]

Okay, I think the logs haven't been created since the vehicle isn't armed, you can set LOG_DISARMED to 1, that will generate the logs without arming the vehicle. Also, the logs are binary files, you can explore them using Mision Planner or Mavexplorer.py. See https://ardupilot.org/dev/docs/common-logs.html

Probably sensor initialization, I haven't played too much with Plane so not sure

Also, there seems to be some connection problems, you're using WSL? 1 or 2?

[AOS55]

Cool, got that working added LOG_DISARMED = 1 into airsim_plane.parm, it seems to be starting on the ground in a vertical attitude from the logs:
.

Ok sure.

Im on WSL 1

[rajat2004]

You could also uncomment the #if 0 & #endif here, that'll log the raw data sent by AirSim as well in separate messages. It might be better to discuss about the physics and log analysis with the much more knowledgable folks over at AP's Discord server or the forums.

Hmm, haven't had any problems with WSL1 when I tested, maybe something's changed, does it reconnect or stay disconnected?

[AOS55]

Hmm ok, uncommented them now and removed ' as this was throwing a warning, thats a good idea Ill send a message in general. I can't seem to see where the ASM1 log message appears

I think it reconnects not sure though this is what typing messages into MAVExplorer.py gives me:

MAV> 2020-09-01 15:16:08 Throttle failsafe off
2020-09-01 15:16:08 ArduPlane V4.1.0dev (1ecc1618)
2020-09-01 15:16:08 5f2e394f13010c736f29b85d5f312ef0
2020-09-01 15:16:08 Param space used: 260/3840
2020-09-01 15:16:08 RC Protocol: SITL
2020-09-01 15:16:08 New mission
2020-09-01 15:16:08 New rally
2020-09-01 15:16:10 Airspeed 1 calibrated
2020-09-01 15:16:14 GPS 1: detected as u-blox at 230400 baud
2020-09-01 15:16:15 EKF2 IMU0 initial yaw alignment complete
2020-09-01 15:16:15 EKF2 IMU1 initial yaw alignment complete
2020-09-01 15:16:20 EKF2 IMU0 tilt alignment complete
2020-09-01 15:16:20 EKF2 IMU1 tilt alignment complete
2020-09-01 15:16:25 EKF2 IMU0 origin set
2020-09-01 15:16:25 EKF2 IMU1 origin set
2020-09-01 15:16:51 EKF2 IMU0 is using GPS
2020-09-01 15:16:51 EKF2 IMU1 is using GPS

[rajat2004]

@AOS55 Just tried out the latest commits, things look okay to me from the logs, noticed that there were some problems with the logs, opened https://github.com/AOS55/ardupilot/pull/1 which enables the logging of Airsim data
Here's a log file with the ASM1, ASM2 messages - https://drive.google.com/file/d/1ZhiCmiXtN6-KAdYzklJlkL6k6HlzI5tN/view?usp=sharing

[AOS55]

Great thanks a lot Ive commited that back to master, I also added support for tla in the message packet and a very simple linear physics implementation for this.

Thanks how did you view the log file, was there a specific command in MAVExplorer.py?

• Ive tried graph ASM1 but it doesn't seem to give any output.

[rajat2004]

Try graph ASM1.Alt, after ., it should autocomplete.
MAVExplorer is somewhat strange, if you want, we can discuss about the problem on chat or voice, since it can get messy with logs and all, not particularly well suited on an issue

[AOS55]

Cool that sounds good which program do you want to use/ what works best for you?

[rajat2004]

Sorry, missed the message, Github didn't show notification
Discord works?

[AOS55]

Yeah discord is good

[AOS55]

https://discord.gg/xd4PrN

[AOS55]

Hey Ive been looking at debugging some of the flightphysics problems with the FixedWing class I think I've worked out what is wrong with the implementation but not sure how to fix the implementation. The fixedwing physics files in AirLib/include/vehicles/fixedwing/ should construct an aircraft as follows:

• Basic AircraftControls are implemented in ControlSurfaces.hpp but no forces are communicated in this method only the control signal.
• Airplane.hpp contains the main aircraft physics and should apply a wrench to the aircraft
• As in the multirotor, FixedWingPhysicsParamsFactory.hpp inits the params_ object based on the setupframe... defined in AircraftParams.hpp.
• FixedWingPhysicsBody sets the aircraft pose and advances the model through the simulation.

Currently the methods in Airplane.hpp outside of initialize are not being called ideally the class should execute the following methods:

1. Based on state setAoA and setAirspeed and createControls using the method defined in ControlSurfaces.hpp
2. Aerodynamic forces are then calculated using createAeroForces
3. The aerodynamic forces are then applied to the Airplane : PhysicsBodyVertex class using setWrench, I think the setWrench method is currently not being called and the new forces & moments not applied to the vehicle around the loop.

Do you know how to apply forces and torques to a PhysicsBodyVertex child?

I think the createDragVertices method used in the multirotor implementation might make the most sense but this only applies forces offset from the CG rather than a single vertex with forces and moments defined about the CG as is done in Aircraft.hpp?

[rajat2004]

Not exactly sure what's going on, will need to run and try to understand the flow, but from a first glance, there are 2 derived classes from PhysicsBodyVertex, one is Airplane.hpp, and the other's ControlSurface
Don't think that's intentional, might give some clues as to why some methods are not being called

[AOS55]

Sure, I think thats from where I initially built the ControlSurface class based on the RotorActuator class from Multirotor. Im not sure if ControlSurface should still be a derived class, it will need to update in the loop. As it receives command signals from the Ardupilot Api and then sends these signals to the Airplane Class in createControls.

Given Control surface just returns control deflection do you think it needs to be a PhysicsBodyVertex derived class.
Also looking at the multirotor in further detail the PhysicsBodyVertex::update() function call should be responsible for the setWrench method being used. Perhaps the update() method in Airplane.hpp is never called.

[AOS55]

Hey, Its been a couple of weeks since I put something up here. Ive been looking back over the program. I noticed in MultiRotorPhysicsBody an override is used to override the function, and assigns the forces to the PhysicsBody. I didn't include this as I thought my setWrench method in the Airplane.hpp class was doing this, its quite clearly not.

Do you know if there is a way to get the getWrenchVertex to be used for just a single structure rather than the class templated as a vector. I could change add a new getter into PhysicsBody something like getSingleVertex without a for loop, I don't know if this is a bit of an antipattern however. Would be great to get anyones about how to best restructure this.

[rajat2004]

I haven't looked deeply at this, but you could possibly move the parts in PhysicsBody not suitable for FixedWing to MultiRotorPhysicsBody, which I guess includes this. That'll have the benefit of making the PhysicsBody more generic. The functions called in PhysicsBody::update() anyways are actually implemented in MultiRotorPhysicsBody

[AOS55]

Yes that makes sense I'm not entirely sure how PhysicsBody actually calls getWrench though. I have tried the following implementation calling the same getWrenchVertex, this returns an unreal textbox error stating error at startup: invalid vector subscript. Then goes to this UE4 triggered breakpoint. Any ideas?

[rajat2004]

getDragVertexCount() seems missing, maybe try adding that? But don't think that'll actually affect anything, since the base implementation in PhysicsBody returns 0 which will cause the loop to not run
Also try adding some print statements or breakpoints here and there to make sure things are being called correctly

[AOS55]

Thanks yeah I tried playing around with it but doesn't make any difference. Ive reorganized Airplane.hpp slightly. setWrench wasn't an actual vector before I realised this should now be fixed. I've been trying to work through the various base classes surrounding the physicsEngine.

A useful part in FastPhysicsEngine shows how getBodyWrench from PhysicsBody is used. When debugging I keep getting the error window shown below when going through breakpoints is this something you have come across before? Tried pressing load and playing with symbols in visualStudio tools but with no success.

Im also still not sure what is causing the error at startup: invalid vector subscript message from unreal.

[rajat2004]

Nope, haven''t seen that earlier

[AOS55]

Cool np, Ive sent a message over to the unreal forum (which is awaiting mod approval) and the same message to the UE4 subreddit. There might be some more people there who are more familiar with the UE4 side of things.

I've been going through the breakpoints line by line trying to work out the differences between my method and multirotor and also where the differences lie. The following questions/potential solutions have come up Im going to keep investigating further:

• MultirotorPhysicsBody.hpp has the rotors_ struct as a vector of instances, whilst FixedWingPhysicsBody.hpp Im wondering if FastPhysicsEngine expects the returned wrench to be a vector, I can't see anything in the class's method to suggest that to be true though. If anything it should be a wrench as is passed, it may not be in FastPhysicsEngine at all.

• Within MultirotorPawnSimApi.cpp the rotor_count variable to control is passed with wrenchVertexCount, this causes the wrenchVertexCount method from MultirotorPhysicsBody.hpp to run (not sure if it overrides into PhysicsBody as well at this point). This combines the thrust and controllers into one object. On the FW airplane however the control surfaces impart no force directly _they are not a wrench_ instead when the control is deflected the airplane : PhysicsBodyVertex class runs and the new control input sets the force change in the loop. control_count is found using a method that just gets an unsigned int from params. This is not coupled to the forces or wrench and I'm not sure where it would be but I may have upset the way wrench is called. Running through the code with breakpoints I found that resetImplementation is an important call for setWrench and as updatableObject is a base class of several methods is how a lot of the virtual functions get overriten in the initial instance. So as long as uint wrenchVertexCount != 0 the wrenchVertexCount method will run. It may be however the UE4 vector error comes up because airplane_ is a class and not a vector of class instances as is the case for rotors_.

• Finally, I might try also try working back from where UE4 places the error i.e. in AirSimGameMode.cpp the problem could be to do with the FixedWingActor as implemented through unreal I'm not sure where to trace this back, I have FixedWingActor but Im not sure where the spawned pawn/actor gets updated. Im guessing UpdatableObject is somehow linked to this but not sure where this and the API links with an unreal method.

Sorry bit of a long post, mainly put up to keep track myself, are there any other thoughts of where might be useful to look?

[AOS55]

Update:

Managed to solve the UE4 error with some assistance from one of my colleagues. The controlSurfaces were not being constructed in the aircraft and a function was called to a vector<struct> that caused the array problem. Have a loss of connection with Airsim and unreal now due to [2020.09.21-17.44.45:574][215]LogTemp: Error: Linear velocity had NaN! error being returned in the command line. Not quite sure what is causing it yet but certainly making some more progress.

[AOS55]

AirSim Physics

I might open this up in a seperate issue thought I'd put it here first. Does anyone know the orientation of the following outputs from kinematics. In the current fixedwing commit the values of aero forces are becomming very large and causing an overflow/nan error. I have used the following to define each input:

• Aircraft orientation as quaternion kinematics_->getState().pose.orientation the body axis defined relative to earth axis horizon of form [s + q1i + q2j + q3k].
• Aircraft position as displacement from orgin kinematics_->getState().pose.position [xe, ye, ze].
• Linear Velocity along body axis kinematics_->getState().twist.linear [u, v, w].
• Angular Velocity along body axis kinematics_->getState().twist.angular [p, q, r].
• Linear acceleration along body axis kinematics_->getState().accelerations.linear [axb, ayb, azb].
• Angular acceleration along body axis angular_acceleration = kinematics_->getState().accelerations.angular [pdot, qdot, rdot].
• To calculate the aircraft's orientation in the body axis the function toEuler converts a quaternion to an euler vector representation of the aircrafts orientation. This should contain the angles [roll, pitch, yaw].
• The wind axis orientation should then be found from the dot product between the velocity vector and the orientation vector calculated prior, the function angleBetweenVectors is used to accomplish this. This should the aircrafts aero angles as input [alpha, beta, psi] (note psi the zw to zb axis angle is unused assume symmetric in this sense).

I think the most likely cause of the problem is either:

• Aero angles are defined with wrong reference i.e. pose/twist/acceleration is relative to earth axis not body axis.
• Incorrect implementation of controls in ardupilot
• Incorrect coefficients used I have assumed pose is setup in radians NOT degrees

[rajat2004]

Yeah, probably might be a good idea to open a new issue. I myself mostly won't be able to take a look at all this anytime soon, but hopefully others will help,
There's also another PR #2956 which might be of interest, that one also fixes an FPE which happens with extreme values with AirSim+ArduPilot Rover

ArduPilot side, as you probably already have been doing, could capture some logs and maybe ask on the Discord server also.

[AOS55]

Thanks, I added #2956 into the distro but it doesn't seem to have had any effect, if anything it appears its accelerating far too much and has too much dynamic pressure i.e. runaway, (perhaps not enough drag, but L/D seems to be 5 which is pretty normal).

As I've been debugging stuff further today I think the problem may actually be to do with ground collision in fastPhysicsEngine in particular getKinematicsOnCollision, Ill keep looking at it but it seems to cause huge linear and angular accelerations on the body resulting in the values blowing up. Not sure why yet?

[AOS55]

I've been working through debugging the physcis with the fixedwing vehicle. I have debugged most of the issues that were present in the aerodynamics side of things. I had a couple of dimensionless coefficient mistakes and was returning the aeroforce to fastPhysicsEngine in wind axis rather than body axis. This is now fixed and the force is in body axis. I still have the variables blowing up in places however, I'm beggininig to think this might be in the fastPhysicsEngine itself.

The engine uses Verlet Integration to solve the problem which appears to scale with O(delta_t^2) error. Most fixedwing simulations I have seen in the past tend to solve the state-space system of equations with the euler method instead, which notably scales with O(delta_t) error. I'm not sure about the time complexity comparison of each method without investigating further maybe this is why its called fastPhysicsEngine?

Does anyone know how to change the value of dt to a smaller increment as Im wondering if the simulation problem is actually a numerical integration error.

[seanmcleod]

@AOS55 your other general option is to make use of an external simulation engine like JSBSim for the aerodynamics and physics modeling rather than re-implementing most of it within AirSim's physics engine. Then use the pose data from JSBSim to drive AirSim in computer vision mode in order to retrieve high-fidelity camera images for computer vision machine learning etc.

I sent you an email a couple of days ago to your university email address regarding this option with a bit more detail, may have ended up in your spam folder.

[AOS55]

@seanmcleod thanks your email had indeed gone to my spam inbox, response now in your inbox. I think this certainly a good idea and I'll aim take a closer look over the next week.

[jonyMarino]

@madratman @saihv @ironclownfish @jonyMarino Do you think having another (more chat & voice type) communication platform will be worthwhile? This will definitely increase community interaction, and will probably reduce support issues.
Just wanted to know your opinions, and definitely don't want to increase your (already heavy) workload too much.
Looking forward to hearing from you!

Hi @rajat2004! It is something we are already discussing. In my opinion is something necessary. Will update.

[tensarflow]

Wow really awesome stuff you guys are doing there, appreciate it!
I was using gazebo for fixed wing UAV simulations occasionally for several years. Since I would like to do some realtime computer vision I would like to have a photorealistic environment within the simulation too. That's when I came across this thread.
It is not really clear though, what the current status is since your first comment on this thread. Could you guys maybe write a quick recap of what we can use on your branch and how?
Unfortunately I don't really have the time that I can invest by contributing here (which I very much would like), since it's more of a hobby. That's why I am also looking for a more quick-and-dirty kind of solution if your branch is not quite usable. So in that direction something came to my mind :)
In gazebo fixed wing UAVs are very well supported. At least it satisfies my needs. How about just running the physics stuff on gazebo, then somehow subscribing to the position/direction/velocity etc. messages of Gazebo inside Unreal Engine and only updating that information. Putting the 3D Model of a UAV would be pretty much optional in that case. A flying camera would do it for me :)
What do you think? Does that make sense?

[seanmcleod]

How about just running the physics stuff on gazebo, then somehow subscribing to the position/direction/velocity etc. messages of Gazebo inside Unreal Engine and only updating that information.

I mentioned that option, although I suggested using JSBSim for running the physics/aerodynamics, see my comment a couple of comments back - https://github.com/microsoft/AirSim/issues/2955#issuecomment-708978788

[xxEoD2242]

I've been working through debugging the physcis with the fixedwing vehicle. I have debugged most of the issues that were present in the aerodynamics side of things. I had a couple of dimensionless coefficient mistakes and was returning the aeroforce to fastPhysicsEngine in wind axis rather than body axis. This is now fixed and the force is in body axis. I still have the variables blowing up in places however, I'm beggininig to think this might be in the fastPhysicsEngine itself.

The engine uses Verlet Integration to solve the problem which appears to scale with O(delta_t^2) error. Most fixedwing simulations I have seen in the past tend to solve the state-space system of equations with the euler method instead, which notably scales with O(delta_t) error. I'm not sure about the time complexity comparison of each method without investigating further maybe this is why its called fastPhysicsEngine?

Does anyone know how to change the value of dt to a smaller increment as Im wondering if the simulation problem is actually a numerical integration error.

Have you thought about changing this value in the Fast Physics Engine? I linked to the place where dt is instantiated. I'd be really careful with this, as the time step calculations for this process may be heavily dependent on a sufficient timestep. Have you thought about taking the underpinnings of JBSim and modifying the FastPhysicsEngine to be something like kindFastPhysicsEngine with more realism?

https://github.com/microsoft/AirSim/blob/d59ceb7f63878f5e087ea802d603ba0fd282ff56/AirLib/include/physics/FastPhysicsEngine.hpp#L76

Myself and a team are looking to implement a fixed wing drone for a drone competition but we also want to update the physics models to be a bit more realistic for dynamics information so that we can implement our state-space models more efficiently then writing them externally in Python.

[AOS55]

Hi @xxEoD2242 thanks for this. I think a JSBSim physics engine is what we should be heading towards it makes a lot of sense and prevents us reinventing the wheel. I have been working on a python implementation over the last month. But having it native to airsim in C++ would be ideal. The problem I've begun to realise over the past couple of days is that by pose forwarding JSBSim to airsim in CV-mode the collisions cannot be easily calculated from unreal as there is no physical mesh geometry like you get in the multirotor or car pawn.

I'd certainly be keen to work together on this though. A native C++ framework is certainly the way to go long term, with a python API similar to multirotor. I think it might be best to let JSBSim deal with all of the fixedwing physics. JSBSim also has a ground interaction component, but I'm not entirely sure how it works yet, the aircraft I have defined so far does not have any ground-reactions in the aircraft XML file.

[xxEoD2242]

@AOS55 That makes sense. I think the appropriate solution would be to implement JBSim natively in the build process with AirSim and have the selection of JBSim for dynamics information. I work with Purdue University researchers a lot so I'll see if there would be interest from the faculty there in exploring how we would achieve this. Signal routing through the same FastPhysicsEngine routes would be my biggest concern, especially from a memory standpoint to ensure that AirSim stays as optimized as possible. If we decide to go down this route, I'll let you know and possibly fork your branch since you have so much done.

[AOS55]

The documentation and tests leave a little to be desired at the moment but you might find my FixedWing-AirSim repo useful, it just implements the pose forwarding with CV mode described above and then runs JSBSim for the flight physics.

The key classes are in jsbsim_simulator.py

[xxEoD2242]

Awesome. Thanks!

I think there is a desire to implement the physical drone as well and I have a teammate who is working on creating custom environments and scenarios. If we can figure out the blueprints and meshes correctly, we will try to implement that as well, which should help with the issue you are having in CV mode.

[AOS55]

@AOS55 That makes sense. I think the appropriate solution would be to implement JBSim natively in the build process with AirSim and have the selection of JBSim for dynamics information. I work with Purdue University researchers a lot so I'll see if there would be interest from the faculty there in exploring how we would achieve this. Signal routing through the same FastPhysicsEngine routes would be my biggest concern, especially from a memory standpoint to ensure that AirSim stays as optimized as possible. If we decide to go down this route, I'll let you know and possibly fork your branch since you have so much done.

Great that would be really useful and its always useful to get others opinion on how to best implement this. Yes I'm not sure on the difference in efficiency JSBSim presents @seanmcleod may be able to help there.

Awesome. Thanks!

I think there is a desire to implement the physical drone as well and I have a teammate who is working on creating custom environments and scenarios. If we can figure out the blueprints and meshes correctly, we will try to implement that as well, which should help with the issue you are having in CV mode.

Great also would be very helpful

[seanmcleod]

in CV-mode the collisions cannot be easily calculated from unreal as there is no physical mesh geometry like you get in the multirotor or car pawn.

Yep, I see a feature request was raised for collision detection in CV-mode in Aug 2020 - https://github.com/Microsoft/AirSim/issues/1565

So for now you would need to make use of JSBSim's collision detection via it's ground callback mechanism etc.

I had originally suggested the JSBSim pose forwarding idea to Airsim in CV mode as a quick and fairly easy mechanism to implement. Linking JSBSim into AirSim and having some integration and switching mechanism with Airsim's physics engine is definitely doable but a lot more work.

Would the Airsim repo maintainers be interested in incorporating JSBSim in this way? Or would you have to maintain your own fork?