Understanding ROS and Unity Architecture

Hey there! I am a game developer working my way into robotics simulation through the Robotics Hub tutorials. ROS is completely new to me, so please bear with me.

Does it make sense to treat Unity as an authoritative server / control interface, with multiple ROS-controlled devices as clients? What would be your approach to this?

The tutorials seem to be pretty locked in as 1 sim environment to 1 device so I'm not sure if I'm trying to fit a square peg in a round hole.

 

Hi Laurie, thanks for the reply.

It's pretty interesting because it seems like the fundamental design principle is more like a peer-to-peer network then, which (if I'm speculating) makes sense as there seems to be a lot of focus on each unit being autonomous. What's a bit different about my case is that it's targeting collaboration between devices. For example, one robotic arm orienting and holding an object while another arm traces the edges.

I'm trying to approach this carefully so as to conform to established design philosophies rather than reinventing the wheel or building something too naively.

Going on your thought of Unity simulating a world and publishing to multiple other components. Let's go with using the Nav2-SLAM tutorial project, how would you go about connecting 0..N components to one instance of Unity? I've seen it suggested to use a distinct port for each component but have concerns about scalability with that approach.

I've been theorycrafting around doing something like the following, but need a sanity check:

• Maintain a DB with basic information (device ID, last known state, etc)
  
• Scale ROS docker instances with kubernetes using info from the DB
  
  • Docker instance is fed a device ID from DB document
    
  • In the wild, the device would be deployed with a predefined device ID and initiate a connection on startup
• Device connects to Unity with its device ID
• Unity provides initial information to the device
  
• Logic on the Unity side acts as coordinator, sending instructions to devices and waiting for feedback

Contrary to my randomly chosen name, I'm very open to changing this plan if there's a better approach that tackles needs and greatly appreciate any feedback on what I can do better.

 

Excellent questions!

1. The terminology should definitely be clarified. By ROS controlled device, I ultimately mean robots with an onboard computer controlled by ROS. Right now we are doing simulations but want to keep communication with the robots as close to a live environment as possible.
2. In this case, I mean that Unity will publish environment information to the robot as well as determine which actions the robot should take in the form of commands. E.g., [MoveTo {pos:<3, 1, 2>}], [GrabObject {type:Tile pos:<5, 1, 3>}]. Robots will provide feedback, but lack significant autonomy. I know, it's not nearly as cool, but in this case we need reliability and verification over speed or cool factor.
3. While I'm working on getting more comfortable with Docker, I am far from an expert. It could very well be that I don't need kubernetes to scale the number of docker containers. It just seems like the proper tool to solve for scaling the number of containers to simulate 0..N robots. Do you think it is unnecessary complexity? Ultimately we will have multiple groups of dockers but that will require an entirely different system to scale anyway.

Thanks for the email, and much thanks for the support.