New X4 Configuration Request

Issue #252 resolved
Neil Johnson created an issue

We wanted to make a request for a new sensor configuration for the X4 drone. We have modified a few files in subt_ign and subt_ros as well as in the fuel models to allow us to test this different configuration. It has the following changes:

  1. Includes a VGA RGBD sensor (instead of QVGA)
  2. Includes a 2D lidar (10 meter range I believe)
  3. Includes a point laser that faces up (to detect the ceiling)
  4. Includes a point laser that faces down (to detect height above ground)

We have the vehicle working in ignition sim now. What is the process to submit this to the Tech Repo for possible inclusion in future circuits?

Comments (32)

  1. Ian Chen

    @Alfredo Bencomo let me know if you need to test this out.

    I can help upload the models to fuel and be part of the official robot configurations if this gets approved.

  2. Sophisticated Engineering

    I like the idea to have sensors for the distance to the ground and to the ceiling. Using a point laser might have problems when there are small holes or gaps in the bottom or in the ceiling. (In the past there were problems with gaps where the tunnel sections are connected.)

    Just an idea: Wouldn’t it be better to use a sensor that looks not only at a single point but at a small area e.g. using an ultrasonic sensor?

  3. Zbyněk Winkler

    We are just starting to use VL53L1X sensors in the real world so having that available also in the simulation would be great. However, I have no idea how to add a new sensor.

  4. Martin Dlouhy

    Is there any progress on this issue or better general “how to add new robot configuration with CloudSim”? We would like to add new configuration of ground vehicle X2 + lidar (30m) + RGBD camera. My colleague experiment with it but it seems that on start it access online (!) prices/points for the configuration? So far it does not work. For us it is “blocker” as for Urban we need better 3D info.

  5. Arthur Schang

    Martin there is currently a plan to release documentation regarding the process of adding new robot configurations and models to SubT repository for Ignition. Work has already begun on the aforementioned documentation.

  6. Sophisticated Engineering

    In the past, we had to add a pull request (for the dual camera configs) in a private repository which was a clone of the original repository. Will this be in principle the same with ignition, or will this change?

  7. Martin Dlouhy

    Hello,
    I’ve got instruction from my colleague how to add RGBD camera to robot X2 (replace configuration “X2 Config 1”):

    The following changes have been made in both cloudsim_bridge and cloudsim_sim to add rgbd camera to X2_SENSOR_CONFIG_1:

    • edit files as in add_rgbd.diff2
    • call catkin_make
    • call catkin_install

    Additionally, in cloudsim_sim the following file has been modified:
    /home/developer/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/X2 Config 1/11/model.sdf

    Is a month old “New X4 Configuration” already merged? Can there be some X2_SENSOR_CONFIG_7 created??

  8. Derek Vasquez

    Yesterday I submitted a request for the new X4 configuration that @Neil Johnson and I have been working on. I ran into a few issues while following the instructions posted by @Angela Maio, specifically the instructions ‘Adding a Custom Configuration to Existing Vehicles’ in step 4, and the generation of a URDF. I’m curious to know if anyone else is having similar issues.

    The instructions mentioned in step 4 refer to a specific branch of osrf/sdformat. In order to get the specific branch I followed the instructions for compiling from source found here with the following exception:

    I replaced this line:

    hg up sdf_2.0
    

    With the clone command from the branch:

    hg pull && hg update sdf_to_urdf_sdf8
    

    The first step in these instructions tells you to remove sdformat. When I did this, a lot of associated ignition stuff was also going to be removed. I went ahead and did this because the machine I was using was not our primary subt development machine, but this is unfortunate. Would it work to build this branch from source without removing pre-existing sdformat?

    To build, this specific branch of sdformat requires g++ 8, which I made sure was installed:

    sudo apt-get install g++-8
    

    My machine (Ubuntu 18.04) was still defaulting to g++ 6.5, so I had to export the environment variables to get sdformat to build:

    export CXX=g++-8
    
    # and for good measure, not sure if it's necessary because
    # I wasn't getting any errors about gcc
    export CC=gcc-8
    

    sdformat was then able to build and I got the option to use the -u tag on ign sdf, which does not show up in other branches of sdformat. I passed in my model.sdf file and the output was printed to the terminal.

    I followed the other instructions without any problem. I am still waiting on a response to the pull request to ensure everything is set up correctly.

    Takeaway questions: Is this the best or intended way to go about generating the URDF file? If so, is removing sdformat before installing from source with the new branch absolutely necessary?

  9. Arthur Schang

    @Addisu Z. Taddese might can help with the urdf from sdf questions/issues.

    @Derek Vasquez I’m looking over the PR now and sent an initial reply. I should be able to dive deeper and confirm everything else is in line by Monday. The mostly accurate/slightly incorrect/temporary alternative to generating an urdf from sdf when reusing x1/x2/x3/x4 ONLY is to use the urdf from x1/x2/x3/x4_description package’s urdf in the subt repository.

  10. Addisu Z. Taddese

    @Derek Vasquez If you're building sdformat in catkin/colcon workspace, there is no need to uninstall the pre-existing sdformat. If you're building without a workspace, just make sure not to install it to a system directory. You can do this by setting a different path on CMAKE_INSTALL_PREFIX. i.e cmake .. -DCMAKE_INSTALL_PREFIX=<non-system path>. Otherwise, it would interfere with the sdformat that is installed as part of ignition-blueprint.

  11. Neil Johnson reporter

    We are trying to complete this effort, but are a little confused. Right now, we dont' see an example spawner.rb file. Instead, the individual ign files (like tunnel_circuit_practice.ign, etc) spawn X1-X4 vehicles inside the ign file. We have had luck modifying those files to change the sensor configurations, and we would like to submit our changes as “X4_SENSOR_CONFIG_5” or whatever. Can we do that rather than jumping through all of the hoops in the model preparation guide? We would adjust the vehicle weight to account for the extra sensors we’re adding, but other than that, our vehicle is very similar to the existing X4 configurations.

    Also, I see that there is a “submitted_models/x1_sensor_config_6” branch. Can we follow suit and submit this a an x4_sensor_config_5 pull request?

  12. Neil Johnson reporter

    We are running into another issue: we are trying to build our new model off of the urban_circuit branch, but that branch has some errors in the “subt_ros/launch/vehicle_topics.launch” file: it refers everywhere to “ros_ign_bridge” instead of ros1_ign_bridge. This causes an error when spawning the vehicles (their topics do not show up). Should we be working off a different branch?

  13. Alfredo Bencomo

    Neil,

    Run the commands below:

    sudo apt-get update && sudo apt-get install --only-upgrade libignition*
    sudo apt-get install --reinstall ros-melodic-ros-ign  # (NOT ros1)
    sudo reboot
    

  14. Neil Johnson reporter

    Please ignore the last couple comments. I think I have been able to understand the sequence of things to do…we will checkout out the team_submission_example branch and make sure the localModel method of spawning works.

  15. Neil Johnson reporter

    Ok, I have gotten our new model to build and run locally. However, I based it on the team_submission_example branch which uses ros1_ign (which is different than urban_circuit!). You should update team_submission_example branch to use the same ignition packages…

  16. Sophisticated Engineering

    x4 config 5 is already used for the two 2D cameras config. So I would say that you should use config 6 or higher.

  17. Arthur Schang

    I don’t believe submission_example is meant to be a staple forever, it’s just an initial example until submitted models started rolling in. I suspect everyone else’s community models to be the example moving forward.

    In this case, I believe it’s acceptable to submit as x4_sensor_config_6. x4_sensor_config_5 already exists (the stereo camera configuration as previously noted).

  18. Neil Johnson reporter

    @Arthur Schang , I added you as a user on my fork/pull request. I am not sure where to find the lidar lite ignition model. Is that something you would like me to modify on the pull request? I’m hoping to get the x4_sensor_config_6 accepted soon.

  19. Neil Johnson reporter

    Arthur,

    I pushed a change to the pull request branch that updates the upward and downward lasers to be modeled after the lidarlite v3 (from your x4_sensor_config_7 branch). I also modified the 2D lidar to be modeled after the RPLidar S1. I pushed those changes. Will you confirm that those changes take effect in the pull request? Let me know if I need to do anything else to get the pull request accepted.

  20. Log in to comment