search

PX4 / PX4-Devguide

PX4 Devguide GitBook
http://dev.px4.io
Other
194 stars 482 forks source link

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

Open hamishwillee opened 6 years ago

hamishwillee commented 6 years ago

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."

hamishwillee commented 6 years ago

@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 commented 6 years ago

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

Defining the px4 modules / parameters

Building with the custom model

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

Comments:

hamishwillee commented 6 years ago

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

hamishwillee commented 6 years ago

@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 commented 6 years ago

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

hamishwillee commented 6 years ago

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

TSC21 commented 6 years ago

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

mamariomiamo commented 5 years ago

is there any update with this issue? :)

hamishwillee commented 5 years ago

is there any update with this issue? :)

@TSC21 ?

kuiskas commented 5 years ago

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 commented 5 years ago

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

hamishwillee commented 5 years ago

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

lamping7 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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:

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

I see 2 solutions with the new structure:

lamping7 commented 5 years ago

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

jannsta1 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

jannsta1 commented 5 years ago

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:

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

lamping7 commented 5 years ago

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.

jannsta1 commented 5 years ago

OK - had been trying using $ make posix_sitl_default gazebo_MODEL_NAME to test but will also try with the launch files.

No doubt there are better examples out there but in case its helpful my Frankenstein Iris/typhoon_h480 model is attached (iris body, typhoon gimbal and startup parameters altered for ekf2 to use mocap data). The rcS file is still in the old format.

bee_model_files.zip

ChuplesKai commented 5 years ago

Thanks @bkueng! That seems to have resolved issues and I'm finally seeing the script run to completion and my SDF loading in Gazebo! For everyone's sake, I'll post what steps I took to see things running.

Getting your SDF to Gazebo

There are a couple of ways to do this it seems. You can directly add your model to Firmware/Tools/sitl_gazebo/models as suggested by @jannsta1 which should be the simplest solution.

Alternatively, you can have your SDF outside the Firmware tree by modifying your GAZEBO_MODEL_PATHenvironment variable to include an additional models directory. This is what I did, and it seems to work fine.

In either case, make sure that you set the sdf argument of posix_sitl.launch appropriately to point to your model.

Building the Firmware for your model

I don't know if all of these steps are necessary, but this is everything I did (for FW 1.8):

jannsta1 commented 5 years ago

@ChuplesKai - thanks for sharing - could you post the git commit id that you're using? (I think some of these changes are post stable release v1.8.0). Appending GAZEBO_MODEL_PATH is a good idea too. From memory I think you can put stuff in ~/.gazebo/models and it's available without it being added to the path.

@lamping7 - A quick tutorial / example case would be really appreciated. Even if this was done with one of the existing airframes that is already in the new form (this is probably how most customised models probably start anyway) as a copy/paste exercise. I think the gazebo model part is fairly straightforward just the rcS file (if its still referred to as that) that's proving tricky.

ChuplesKai commented 5 years ago

@jannsta1 I'm working off of commit cfac2cc (slightly out of date). Now, as far as I know, this is an unstable development step, but it sounds like you have an idea that the process will be slightly different with the 1.8 stable release? I'm still having some hard-to-identify issues here, so I'm wondering if I should be backing up to the stable release and working from that.

ChuplesKai commented 5 years ago

Also, I can't seem to figure out what is going on, but somehow the custom model is causing the simulation to hang (I never see localization fusion starting). This might just be a separate issue (so feel free to tell me so), but I think it might be related to an error I'm seeing early on in the initialization process: INFO [Unknown] Creating symlink /home/chuples/src/Firmware/ROMFS/px4fmu_common -> /home/chuples/.ros/etc 33 WARNING: setRealtimeSched failed (not run as root?)

Now it seems weird to have to run as root, but could the lack of this symlink be causing PX4 to hang?

jannsta1 commented 5 years ago

@ChuplesKai - it seems like the Firmware build/boot process is undergoing some fundamental changes at the moment - some have been added after your commit level. This is welcome if you're using custom models as merging with Firmware updates is more straight-forward (as it won't be necessary to edit the cmake files) but its possible there are still some teething issues with the new setup - don't get too attached to your current setup just yet :).

I'm not sure the rosinfo message you are seeing will cause a hang. Did you try setting the verbose flags in the px4 roslaunch files to true? I noticed that if gazebo can't find models it hangs, but you only get a warning if the verbose flag is set.

ChuplesKai commented 5 years ago

@jannsta1 Right yeah, it seems things are still changing quite a lot... I'm going to need to try to reproduce all of this on stable because our company is working toward a deliverable, so I'll need something.. well, stable.

I haven't tried the verbose flag, but Gazebo does seem to load up fine and it shows my model. Gazebo itself doesn't appear to throw any errors.

I realized I might need to do as you have and instead of invoking the generic build make posix_sitl_default gazebo, I should probably try the build with my model... but that's really not working (looks like it's an issue of needing a <vehicle>.world model, but it could also be other things).

lamping7 commented 5 years ago

I'm not really sure what is confusing you @jannsta1 and @ChuplesKai: I think it's the 10 month old info at the top. I also don't think it is understood how the setup and launching works. The basic thing to know that might remove some confusion is that there are two main ways to launch PX4 and Gazebo. One is with make and the other is with roslaunch. I play around with ROS, so I'm going to only touch on that.

Let's do a simple example: I'm going to show you how to make a copy of the iris model and launch it, explaining it a bit on the way. I'll call this new vehicle iris-copy. Hopefully this will show you what parts are important, where they live, and what changes are required.

Prerequisites:

  1. Clone PX4 Firmware
  2. Enter PX4 Firmware directory
  3. Build the firmware make posix_sitl_default
  4. Build sitl_gazebo, and do not launch gazebo yet make posix_sitl_default sitl_gazebo
  5. Setup your environment. For example, this is in my ~/.bashrc: 
    # PX4
export PX4_SRC_DIR=~/px4/Firmware
source ${PX4_SRC_DIR}/Tools/setup_gazebo.bash ${PX4_SRC_DIR} ${PX4_SRC_DIR}/build/posix_sitl_default
export ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:${PX4_SRC_DIR}:${PX4_SRC_DIR}/Tools/sitl_gazebo

Here we go:

  1. Go to the models directory in your PX4 Firmware directory cd ~/Firmware/Tools/sitl_gazebo/models
  2. Copy the model directory, and enter it cp -R iris iris-copy cd iris-copy
  3. Rename the file and some bits inside them mv iris.sdf iris-copy.sdf sed -i 's/iris/iris-copy/g' model.config sed -i 's/name='"'"'iris'"'"'/name='"'"'iris-copy'"'"'/g' iris-copy.sdf
  4. Go to the startup (rcS) file directory cd ../../../../ROMFS/px4fmu_common/init.d-posix
  5. Make a copy cp 10016_iris 10017_iris-copy
  6. Enjoy! roslaunch px4 posix_sitl.launch vehicle:=iris-copy
ChuplesKai commented 5 years ago

I'll try to make things more clear @lamping7. There are a lot of reasons why this thing is confusing.

First of all this is the first time I've seen it recommended to run those two particular build targets. It's very confusing when there are so many different targets. Also note that those specific build targets have not resolved my issue.

Looking over your .bashrc, unless PX4_SRC_DIR is somehow used by the Firmware, my setup exports and sources the same stuff (as directed by the PX4 install instructions).

Now, your example of creating this IRIS copy doesn't quite fit for our needs with a custom SDF, I believe I have taken the necessary steps to create all of the appropriate configuration files, and I have a custom SDF file which does load in Gazebo as I would expect it to.

Despite doing the steps you've outlined, it still doesn't work.

lamping7 commented 5 years ago

@ChuplesKai You're not giving me enough info to help you. Saying it doesn't work doesn't help me help you. Regarding the build targets: There are many ways to do this. I just shared what I do and what will work to replicate the process I shared. If you carefully read the .bashrc you'll see that PX4_SRC_DIR is only used there. I use it because I often have different versions of the firmware I'm playing with and want to be able to quickly change between them, while using it for other scripts. You can ignore it if you like; it is just an example. @jannsta1 asked if I would do a simple example.

Even if this was done with one of the existing airframes that is already in the new form (this is probably how most customised models probably start anyway) as a copy/paste exercise.

So I did as he requested. I would've used his model, but it doesn't adhere to the new configuration style and I don't have time to do it for him. Carefully look over the steps above and notice the changes that are required to match each other for this to work.

jannsta1 commented 5 years ago

Thanks @lamping7 - following these steps worked. I guess by the time I was adding the right files I was starting gazebo via make rather than roslaunch - this is why I was getting error messages. I'm not sure if this matters - I would normally use roslaunch so current level of support is OK for me. I tried following the same process for the typhoon_h480 (with associated .post file) and this also seemed to work. Could be worth adding something in the docos about these .post files?

ChuplesKai commented 5 years ago

Going over the steps @lamping7 provided, I was able to recreate the working IRIS copy, even for the stable release of 1.8, which is definitely good progress. There still seems to be some issue though when I try to use my custom model, which is increasingly leading me to believe that there is something in how my .sdf file is formatted which is upsetting the simulation.

Specifically, when running with my .sdf, the simulation seems to hang right after the spawn_model process of Gazebo finishes, whereas when I run the default IRIS model, I see it continuing on to start the simulation. The following line:

INFO [simulator] Got initial simulation data, running sim..

Appears when I run with IRIS or the IRIS copy, but not with my model. The biggest notable difference is that my SDF is outside the Firmware tree, but I'm not sure why this would cause a problem.

jannsta1 commented 5 years ago

@ChuplesKai did you try running iris-copy out of tree?

ChuplesKai commented 5 years ago

@jannsta1 good suggestion. Trying it out, the iris-copy does indeed work out-of-tree.

Somehow, the custom .sdf file must be the issue.. it parses just fine in Gazebo but it somehow makes the simulator hang.

jannsta1 commented 5 years ago

sounds like either GAZEBO_RESOURCE_PATH or GAZEBO_MODELPATH are not fully populated or the XML tags in the .sdf have some issue. If you establish the paths are OK (just use $: ```echo $GAZEBO[path of interest]```) then you can just comment out sections of the .sdf until you find the offending section(s).

ChuplesKai commented 5 years ago

Hey @jannsta1, I've been looking at things and poking at it a bit, but I'm pretty stumped.

As for the paths, I think things are set up correctly. The model path is pointing to my custom models directory, and I am able to see my model load in the Gazebo GUI. There's no complaint from Gazebo at all, so I'm assuming that is okay. You'll have to forgive my ignorance about the resource path, but I'm not sure that's a problem, as it seems to only really matter for loading .world files. Now, I can see iris.world does exist in the Firmware tree, but I never created an iris-clone.world file, but the iris-clone still runs. It just seems to default to empty.world, which is fine for now.

As for the .sdf model, I cannot figure out what might be wrong. Doing as you suggested, I systematically began removing parts of the model to see if it would prevent the hang in the mavlink simulator, but it happens every time. I've even tried stripping the model down to just a single base_link, but that still causes issues. I thought the problem might involve having multiple collision/visual bodies on a single link, so I also removed all but one.. but that also does not seem to be the issue. I almost think it's a problem that I've omitted something, but comparing my file with iris.sdf, I think I have everything that is relevant (including rotors and the imu link).

I've been able to track the hang to a specific loop of simulator_mavlink.cpp in FW 1.8 (Lines 746-780), but that's the best I've been able to figure out. I haven't yet been able to decipher exactly what's going on in the code there.

lamping7 commented 5 years ago

Have you looked at the gazebo output when passing the verbose flag in the launch file?

ChuplesKai commented 5 years ago

@lamping7 thanks for the advice! I didn't think Gazebo was having trouble, but putting that verbose flag true reveals a very different story. Hopefully this will let me fix whatever is upset.

taleteorganista commented 5 years ago

Hello, does anyone know how to set and launch px4 sitl using a user-defined world file? I'd like to use a custom world file but I do not know how to make posix it... I do not want to artificially modify an existing world (as I've done so far...) I didn't find any documentation, I would appreciate any suggestions.

jannsta1 commented 5 years ago

There is an argument 'world' in the px4 launch files (e.g. see posix_sitl.launch) you can pass the file path of your custom world to this parameter in the usual way.