ROS Engineering Team with Automotive, AMR and Logistics Experience Available for New Projects

Dear ROS Community,

my team and I have 5 years of experience with ROS1 and ROS2 in Automotive, AMR, and Logistics Environments. Starting July we are available for new projects.

We are looking for short-term consulting and long-term contracting opportunities as well. Usually, we work as integrated remote team members in our customers’ teams.

Most recently we worked for Wyca Robotics, building an inventory robot and a containerized robotics platform based on ROS2 Galactic, Humble, and Iron.

Key technologies we worked with:

  • High-resolution cameras and GPU-accelerated image processing for barcode recognition
  • ROS2-based containerized Autonomous Mobile Robot platform (using Docker Compose)
  • Nav2 framework for AMR navigation
  • ros2_control framework
  • BehaviorTree.CPP for high-level behavior control
  • Gazebo and Webots simulators
  • We are also working on a custom, lightweight Godot Engine based simulator - which will be released as open-source

We also worked on the ROS-based Augmented Reality HUD system for WayRay. (Demonstration: AR head-up display on public roads? Real cars, real holography by WayRay - YouTube )

We were involved in a number of key projects, including:

  • rebuilt the rendering engine and most visualizations using the Godot Engine
  • created a VR Simulator based on Carla (https://carla.org ) and ROS integrations
  • created high-level SDK based on ROS2 (OMG IDL, code generation in 4 languages)
  • built a mixed ROS1 / ROS2 system using Docker and Android
  • enhanced ROS1 to work over NAT network connections using integrated SOCKS protocol support
  • worked with most major ROS2 backends (Fast DDS, CycloneDDS, Iceoryx, Zenoh)
  • built a Mobile Gateway with Zenoh (My presentation at the Zenoh Summit: Mobile Gateways for ROS2 Systems with Zenoh - YouTube )
  • we worked with ROS using the following languages C++, Python, Java (with some fixes from us), Rust (some Zenoh prototyping) and Lua (our own bindings)

Kind regards,
Gergely Kis (gergely.kis@migeran.com)
Lead Engineer and CTO
Migeran - Reliable Software Engineering
https://migeran.com

We are also working on a custom, lightweight Godot Engine based simulator - which will be released as open-source

What is the rationale for this development? I.e. why not rather contribute to Gazebo instead of developing something new?

Not sure what OP’s reasons were, but well Gazebo releases are always tied to specific ROS versions, so any contributions you make you won’t be able to use for years if you need to stay on a ROS LTS. There’s not much of an incentive to contribute with that in mind.

@MoffKalast Maybe I am missing the specific use case, but in my case ROS 2 and Gazebo interoperability turns down to compiling the ros_gz_bridge from source and/or directly using gz-transport in the ROS 2 nodes. That seems a minimal issue compared to writing a simulator from scratch.

Upon re-read of my question, I assume it might come accross as judgemental.
It is a genuine question though:

  • Rendering engines can be added to gz-rendering as a plugin,
  • Physics engines can be added to gz-physics as a plugin,
  • General simulation functionality can be added to gz-sim as a new system.

I think this was the main rationale to rewrite gazebo classic into ignition/gazebo sim: to provide maximum flexibility and extensibility to all use cases.

So why start from scratch on something new? That seems like such a huge undertaking, not just the initial development but then also the continuous maintenance and further developments.

So I am curious.

@JRTG Dear Johan,

thank you for bringing this point up.

Actually, there are multiple simulation options for ROS, in addition to Gazebo, each with its strengths, including:

  • Webots
  • Carla (with its ROS bridge)
  • Unity Robotics
  • NVIDIA Omniverse Isaac Sim

My team has extensively used Gazebo and Carla (we also did engine customizations, like adding a VR mode that was presented by WayRay at CES 2019) and evaluated Webots and Isaac Sim.

We also have in-depth knowledge of the Godot Engine: we built an AR rendering engine based on it for WayRay, where we also integrated both ROS1 and ROS2 with it, but we could not release those components to open-source.

At WayRay we also created a more lightweight vehicle simulator based on it (including VR mode), that we could use in situations where the photorealistic rendering of Carla (and Unreal) was not necessary, but could be run on less powerful machines and provided better developer experience (e.g. shorter build & startup times).

When designing a system, one can go in multiple directions:

  • The Gazebo team, as you wrote, decided to create a completely modular system, where many modules can be replaced as needed.
  • It is also a valid design choice to choose a generic engine like Unreal (for Carla), Unity, or NVIDIA Omniverse, and build the robotics simulation and ROS integration on top of that.

Our main design goals for our solution are as follows:

  • We wanted to use the Godot Engine as the base because we know it well, and we think that it is a great development platform (this includes developer UX, authoring tools, runtime performance, and support for many different platforms). Godot also provides carefully selected extension points, e.g. it will be possible to integrate different Physics engines, if/when the need arises, and it already supports most GPU APIs out there.
  • We also wanted to build on top of an open-source base, which meant that Unity and Unreal were not an option.
  • We also would like it to support different GPUs, not just NVIDIA.
  • The solution needs to be lightweight, so it can run on less powerful machines or even on standalone VR headsets, like the Meta Quest series which we also have experience with.
  • We are currently targeting the simulation of relatively simple AMRs only (wheeled base + sensors), not a completely generic solution. Of course, if there is interest (and support) from the community, we would be very much interested in extending the scope.
  • We are also interested in providing AR and VR experiences e.g. overlaying point-cloud data from a robot on a real or simulated scene.

You also asked, why aren’t we contributing to Gazebo, instead of starting something new.

One of the reasons we are working with the Godot Engine is to leverage the power of its community. We are also Godot contributors with already accepted patches and other contributions under discussion. And with Godot, we can leverage a larger ecosystem, not just in the context of robotics simulation, but also many others that require related technologies like 3D games, AR / VR experiences, …etc.

So we are building on top of an existing system, just not on top of Gazebo.

This reply is already becoming very long, but I would be happy to continue the discussion. I would also be happy to talk to anyone from the community, who is interested in supporting the project.

For example, I think that industry standards like IFC (from Architecture / Construction) and USD (and its related standards like MaterialX) are very important to support natively in our open-source tools. This will enable easy round-trip engineering between architects and robotics engineers to test automation systems in buildings in virtual environments that have not yet been built and provide valuable feedback during the design phase. The IFC side is coming along nicely with BlenderBIM and more recently FreeCAD, but there is still much to do on the USD front.

Kind regards,
Gergely

1 Like

@kisg
Thanks for your elaborate answer.
It seems indeed that it has been researched but is not trivial to use Godot as a plugin for gz-rendering.


For my context (machine building), it would for sure be great to have an easy to use simulation (or even just visualization) solution for VR/AR.

I haven’t seen wide adoption yet of VR/AR in machine building.

Even though all the big CAD and PLC software manufacturers tout their ‘digital twin’ capabilities (i.e. the marketing word for their AR/VR visualization and simulation solutions), I have only really seen comprehensive adoption in very large companies. For SME’s, the cost and effort involved (licenses, training, implementation time, etc) is typically prohibitive.

Still, the potential benefits are real: a good-looking simulation in VR/AR is not only relevant for development, but also for marketing and sales, training, after-sales service, etc.

I think companies that develop using ROS have a distinct benefit in this respect. Typically the use of a simulator is intrinsic (no pun intended :wink: ) to the development process anyway. So there’s a limited marginal cost to use that simulation also for other things than development. I for one have been very pleasantly surprised by the graphical capabilities of Gazebo and intend to use it in sales meetings. But that’s obviously not in VR.

It still is an elaborate process though, to export models from CAD, apply textures (typically in another software), import them in the simulation, define links, joints, etc. I previously had a look at possible options for VR, but that seemed even more cumbersome.
So if there would be an easy solution to also import the models into a visualisation solution for VR/AR, without too much extra effort (ideally the same models and SDF file), that would for sure have value.

Eagerly waiting to check out your simulator when it is released!

Dear @JRTG,

Thank you for your detailed reply. I agree that AR / VR in machine building or robotics, in general, has great potential.

I think one of the issues that need to be solved is finding the right format to represent the models to simulate.

In the AEC industry, there is IFC, which is (more or less :slight_smile: ) supported by every major player. And IfcOpenShell and BlenderBIM pioneered native IFC authoring support, which means that you can load an IFC model into Blender and edit it natively without first converting it to a Blender internal format and then export it back. This has huge benefits compared to what basically everyone else is doing, which is based on import/export.

For CAD, there are of course the ISO STEP standards (which actually use the same underlying file format and definition language as IFC), but there are many versions, and even the largest vendors don’t seem to have support for all the features of the latest ones.

Contrast this with e.g. how the C++ standard evolves, and where we usually have experimental implementations way before the standard is finalized. I think that it would be great if a similar project emerged for the CAD standards as we have with IFC. That could enable a shorter path from CAD to simulation.

Implementing AR / VR visualizations and simulations using a game engine is a great option because it has most of the building blocks for it already included.

For example, there is also a ROS2 Gem for O3DE built by Robotec.AI and Amazon: o3de-extras/Gems/ROS2 at development · o3de/o3de-extras · GitHub.

I will also definitely share more information about our progress.

Kind regards,
Gergely

While this is not the Godot Engine based AMR Simulator that we talked about above, we just released the initial ROS2 Bridge for the HoloOcean AUV Simulator: