Missing Topic: How to integrate customised Gazebo copter models into the code base

[hamishwillee]

From #391 "Another nice to have would be how to integrate customised gazebo quadcopter models into the code base. Took me a bit to figure that out and I’m still not sure that I’m following best practices."

• Do we have advice on that?
• Who is best person to ask how that should be done
• Where best place to document that?
• What are the sections/sub questions that would need to be answered for this - e.g. how to dimension the motor models

[hamishwillee]

@jannsta1 ,@TSC21 suggested we open a standalone issue for your question in #391. Do you think you might be able to share the approach that you used to seed our documentation efforts? My experience is that it is much easier to get feedback if you say "I did it this way, is that right" than to ask for someone to start the docs from scratch.

[jannsta1]

Hello @hamishwillee, perhaps this is a useful starting point?:

Creating custom gazebo models for use with px4 sitl

There are 2 situations where this is useful. Specifying a new physical model and/or specifying a new px4 software environment. These can be achieved independently but both cases require a rebuild of the posix-configs build.

Incorporating a custom physics model

• Guides for creating compatable models can be found elsewhere (e.g. on the rotors website. Looking at the existing models in /Firmware/Tools/sitl_gazebo/models is also a good starting point).

• Once created, the custom model is added to /Firmware/Tools/sitl_gazebo/models along with any related mesh and .sdf files.

• we also must create a world in /Firmware/Tools/sitl_gazebo/worlds

  • it appears like this has to match the name of the model??

Defining the px4 modules / parameters

• a config file must be added to; Firmware/posix-configs/SITL/init/lpe (copying and renaming an existing config is a good way to start).
• nb lpe is an example, this must be changed to the desired build type.
• this config file is where sitl modules and initial px4 parameters are specified. Again these files are relatively self-explanatory so looking at existing files in this location a good way of understanding how they work.

Building with the custom model

• Once created or modified, the whole posix-configs build must be repeated in order for the model to become available.

• the model target name must be added to: Firmware/src/firmware/posix/sitl_target.cmake

  • it is added to the following line (currently line 84 in release 1.6.5):

set(models none iris iris_opt_flow ... rover hippocampus <add your model name here>)

• The model is parsed by /Firmware/Tools/sitl_run.sh so it is worth examining this bash script for an understanding of what happens in the build process.

Comments:

• It would be beneficial if the step of adding to the list of models in the .cmake file was not necessary.
• I think the solution to this as it stands is to fork rather than clone the repo but this involves merging/rebasing for each update.
• More flexible .world file usage may be of interest for some users (those not launching gazebo and mavros seperately).

[hamishwillee]

Yes @jannsta1 - definitely. I will have a proper look at this after Xmas (away today). Thank you!

@TSC21 in the meantime, can you look at the advice above and comment

• what else needs to be said/what would you like to say
• are there better ways to do the above
• can we address any of those comments?
• is there anyone else you suggest we involve in this discussion?

[hamishwillee]

@TSC21 Appreciate you may be off on holiday. Do you think you could ETA when you might have time to discuss this/ and suggest others that might be interested in being involved?

[TSC21]

@hamishwillee Sorry I missed the above. I will have write some comment soon.

[hamishwillee]

Thanks @TSC21 - I'm watching you :-)

[TSC21]

Yeah just cleaning and tightening some stuff on sitl_gazebo now and will get back to docs after, including this.

[mamariomiamo]

is there any update with this issue? :)

[hamishwillee]

is there any update with this issue? :)

@TSC21 ?

[kuiskas]

Hi, did the procedure change? I have been working in an older version, but now I wanted to upgrade to 1.8 and there is no ekf2 or lpe config files... in the step Defining the px4 modules / parameters as it used to be under posix-configs/init. Can somebody tell me how to implement now the px4 parameters for sitl? thanks in advance

[kuiskas]

I found it (I believe) it is moved to ROMFS/px4fmu_common/init.d-posix, is that right?

[hamishwillee]

@kuiskas I think so. The recent changes for startup in posix and nuttx are captured in System Startup

[lamping7]

Some of that above is not necessary depending on what is being done or what the objective is. LPE normally shouldn't be used, you don't need a world, and you don't need to touch make. Just follow the existing models as a guide and edit models, rcs, and launch params approperately.

[jannsta1]

@lamping7 - could you confirm the directory that a custom rcs file for a posix_sitl_default build should go (running with sitl/gazebo)? Have tried putting my custom file, 'bee', in Firmware/build/posix_sitl_default/tmp/rootfs/etc/init.d-posix but I get the following error:

INFO  [Unknown] Calling startup script: /bin/sh etc/init.d-posix/rcS 0
Error: Unknown model 'bee'
etc/init.d-posix/rcS: 48: exit: Illegal number: -1
ERROR [Unknown] Startup script returned with return value: 512```

[lamping7]

@jannsta1 it doesn't matter where you put it if you're just using a launch file to spin all this up as long as you change the parameters in the launch file to point there. ~~You can also look at the supplied launch files to find the default location and put it there~~ (not after v1.8.0).

[jannsta1]

Oh yeah, makes sense, thanks! - sorry should have gotten that. The updates to the build procedure is apparently making the code much easier to use / interface with. Its just a bit of overhead rejigging launch files and unlearning my work arounds from before.

[ChuplesKai]

I've also been trying to work through this and make it work, but I'm not having much luck. In addition to the above instructions, I noticed that there's also a CMakeLists.txt in the configuration folder (Firmware/ROMFS/px4fmu_common/init.d). Changing this has not helped get things running.

@lamping7 When you say that you need launch files to point to the model, which argument to the script are you referring to (the first argument or what comes after the -s)?

[lamping7]

@bkueng Did some magic getting all this cleaned up, but it still essentially works the same, from what I can see (correct me if I'm wrong Beat, I haven't tried my custom models with master yet (still on v1.8.0)). Here are the main PRs: https://github.com/PX4/Firmware/pull/10173, https://github.com/PX4/Firmware/pull/10222; with some minor documentation changes here https://github.com/PX4/Devguide/pull/600.

One new thing with launching the px4 app with a custom model is the -s for specifying the startup file. Before it was more of a positional arg. Anyway, just put the whole path and name of the startup file after the -s: https://github.com/PX4/Firmware/blob/181b2f69ed53d3c4d011f2b5465fac4c16e0ecd9/platforms/posix/src/main.cpp#L558 and https://github.com/PX4/Firmware/blob/181b2f69ed53d3c4d011f2b5465fac4c16e0ecd9/platforms/posix/src/main.cpp#L205

The cool thing that was added (that you normally won't be using with a custom model is the auto rcs loading): https://github.com/PX4/Firmware/blob/719bfd10730310f3b897dd7f6f0c44d24eb3d19a/ROMFS/px4fmu_common/init.d-posix/rcS#L42. So, by default it loads the generic startup and auto selects the right one according to the vehicle. None of this matters for your custom model though.

[lamping7]

Additionally, in regards to "where to put the startup file" you can't just drop it in a folder anymore, like you used to be able to (my comment a few above this, may be misleading) https://github.com/PX4/Firmware/commit/273988c124d68031c300dcdcac1c4b4150d432de#diff-277741a901ccb3e1f2c296310691a8e6. You have to change the arg manually. Perhaps we should put the rcS arg back in the launch file? This will allow users to avoid having to directly modify the launch file. Any opinions here?

[bkueng]

Previously the way people did it was to copy an existing rcS file and do their modifications. That partially worked because the file was self-contained. However this was never a good solution because:

• when upstream added/removed modules the copied rcS file would break
• changed parameters in the upstream rcS files could lead to more subtle errors, like bad tuning gains.

Essentially you would have to maintain the whole rcS file yourself.

I see 2 solutions with the new structure:

• in-tree: add your own vehicle to https://github.com/PX4/Firmware/tree/master/ROMFS/px4fmu_common/init.d-posix (with a unique autostart ID). Then the arg vehicle can be used to specify it.
• out-of-tree: allow the env variable PX4_SIM_MODEL (or some other) to point to an arbitrary vehicle rc file somewhere in the file system (e.g. https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d-posix/1011_iris_irlock), and then the rcS file would load that.

[lamping7]

Yeah. That makes sense. But for now users can just maintain the whole rcS as how it previously was.

[jannsta1]

I get some errors from a custom sdf file that previously worked OK - my sdf file is called bee but is pretty much the same as the old typhoon_h480 sdf. If I set -s etc/init.d-posix/bee when launching the px4 node I get:

etc/init.d-posix/bee: 105: etc/init.d-posix/bee: vmount: not found
etc/init.d-posix/bee: 106: etc/init.d-posix/bee: camera_trigger: not found
etc/init.d-posix/bee: 108: etc/init.d-posix/bee: mavlink: not found
etc/init.d-posix/bee: 109: etc/init.d-posix/bee: replay: not found

[lamping7]

You need to either revert back to 1.8.0 or fix your startup file according to the new way all this is arranged. Those modules are not in the same place. See the PRs I posted above.

[ChuplesKai]

After reading through some of the recent comments I've made some progress on this, but I'm not sure I'm understanding the whole process. I now have files for my custom airframe in both px4fmu_common/init.d and px4fmu_common/init.d-posix (since I'm trying to do SITL over our custom SDF), and both are using the unique identifier 0001 (is that allowed as an autostart ID?).

PX4 no longer seems to complain about finding the vehicle, but now I am getting Error: no autostart file found as an error. I thought that it should use some generic autostart script, but it seems I was mistaken. Where do I need to add this custom autostart?

[bkueng]

@ChuplesKai What you are doing sounds correct, but I'd have to see all your changes to be able to diagnose it. 0001 should be fine. What are your file names and what vehicle names do you use? The file in init.d-posix (you are doing it in-tree, right?) needs to be named 0001_<vehicle>.

[jannsta1]

OK, for a sanity check is $ make posix_sitl_default gazebo_typhoon_h480 currently working without any warning messages? I see:

INFO  [Unknown] Calling startup script: /bin/sh etc/init.d-posix/rcS 0
Error: no autostart file found
etc/init.d-posix/rcS: 155: exit: Illegal number: -1
ERROR [Unknown] Startup script returned with return value: 512

I think this was working before (post the build changes discussed here) but I've tried completely wiping and re-cloning the firmware and all submodules and rebuilding and I still see this error.

[bkueng]

0001 should be fine.

Just had another look, you cannot use 0001, because the preceding 0's will be stripped.

OK, for a sanity check is $ make posix_sitl_default gazebo_typhoon_h480 currently working without any warning messages? I see:

Indeed, I broke that :/ I'll look into it, it's because of the additional 6011_typhoon_h480.post file.

[bkueng]

Fix is up: https://github.com/PX4/Firmware/pull/10631

[jannsta1]

Good news. Is it possible for someone to summarise all the steps required for a custom sitl config to be added to the new build structure? I've got:

• add gazebo model to Firmware/Tools/sitl_gazebo/models
• add config file to Firmware/ROMFS/px4fmu_common/init.d-posix (the file name must be of the form XXXX_MODEL_NAME, where XXXX is a unique number that can't begin with 0 and MODEL_NAME matches the gazebo model name)

This on its own doesn't seem to work. Is editing cmake or any other files required?

[lamping7]

Don't forget to set the vehicle arg for the launch file, where vehicle matches what you called MODEL_NAME. This tells the launch file which model to load and sets the PX4_SIM_MODEL env variable so that the rcS can auto select and load the right the specific startup for that model. No cmake or other files is required. If someone wants to share their model and startup files, we can make an example of it.