multi-robot support with parallel spawn by anishk85 · Pull Request #294 · JdeRobot/RoboticsApplicationManager

anishk85 · 2026-07-09T19:45:07Z

multi-robot support with parallel spawn

the manager now handles n robots instead of just one, and they spawn in parallel.

what changed

the manager keeps a list of robot launchers/configs instead of a single one.
launch, reset, pause and teardown just loop over it — the state machine is
untouched and doesn't know there's more than one robot.
robot in the launch config is now an array (single-robot exercises are
just a list of one). an old single-object robot still works.
each robot has an entity name, passed to its launch file as entity:= and
used as the ros/gazebo namespace, so n robots get their own cmd_vel, odom,
camera and never collide.

parallel spawn

before, each robot's run() started the launch and then blocked polling gazebo
until it appeared — so robots came up one after another. reset respawns the whole
group, so every reset paid the same cost.

we tried threading it earlier and it hung: the gz spawn-poll is a blocking call
that holds the gil, so the threads just starved each other.

so instead of threads, it's split in two:

run() only starts the launch and returns
wait_spawned() does the spawn-poll, on the main thread
_run_all_robots() starts all the launches, then waits for all of them

the launches run as separate processes, so the group comes up in about one spawn
time instead of n — and reset gets the same speed-up for free.

reset

reset kills every robot launcher, removes each entity from gazebo, resets the
world, then relaunches the group. gazebo's world reset wipes runtime-spawned
entities (and resetting a live one directly segfaults), so respawning is the
right way.

javizqh

Review every single one of the changes. Right now it is not mergeable

javizqh · 2026-07-10T05:24:04Z

@@ -1,3 +1,4 @@
+import re


javizqh · 2026-07-10T05:24:11Z

 from gz.transport13 import Node


+def _find_drone_namespaces():


Remove all of this

javizqh · 2026-07-10T05:24:30Z

+        # reset the AS2 state machine for every drone that's up (not just drone0).
+        # _find_drone_namespaces returns [] for non-drone exercises, so this is
+        # a no-op there and only the world reset below runs.
+        for ns in _find_drone_namespaces():


remove the drone section

javizqh · 2026-07-10T05:24:44Z

            10000,
        )

+        # reset each drone's controller too (not just drone0)


javizqh · 2026-07-10T05:32:53Z

        except Exception as e:
            LogManager.logger.exception(f"Error refreshing GTK applications: {e}")

+    def _kill_all_applications(self):


Remove this function and add it inline where it should go. Functions for 1 line are not needed

javizqh · 2026-07-10T05:33:12Z

        to_lint = app_cfg["linter"]

-        # Unzip the app
+        # the code comes as a base64 data-uri from the browser, strip the header part


Why change the comments. Must be reverted

javizqh · 2026-07-10T05:34:13Z

            try:
-                stop_process_and_children(self.application_process)
-                self.application_process = None
+                # Pause sim first — freezes Gazebo physics immediately so every


Irrelevant comment

javizqh · 2026-07-10T05:35:57Z

-                )
-            except Exception as e:
-                LogManager.logger.exception("Exception terminating scene launcher")
+        # relaunch all robots (in parallel) so they respawn at their start pose


Missing check

anishk85 · 2026-07-11T12:45:48Z

hi @javizqh requested chnages were done please review once

javizqh · 2026-07-11T18:49:47Z

Extra config does not need to be stored

javizqh · 2026-07-11T18:50:59Z

            extra_config = ""

+        # pass the entity name to the launch. entity is the gazebo model name
+        # (used to spawn/remove the model); the launch file decides how to use it


Please remove the last part

javizqh · 2026-07-11T18:52:33Z

        self.world_type = None
-        self.robot_launcher = None
-        self.robot_config = None
+        # one launcher per robot (a list, so N robots are supported the same way


Remove irrelevant comment. It is clear that a list of robot launchers is a list of robots launchers

javizqh · 2026-07-11T18:54:19Z

-            self.robot_launcher.run(
-                robot_cfg["entity"], robot_cfg["start_pose"], robot_cfg["extra_config"]
-            )
+        self._run_all_robots()


javizqh · 2026-07-11T18:55:12Z

        with open("/workspace/code/app.zip", "wb") as result:
            result.write(base64.b64decode(code))
+
+        # just extract evrything to /workspace/code — if theres a processB/ folder


Incorrect. Entrypoints is a list and it decides where are the executables

javizqh · 2026-07-11T18:56:28Z

-                )
-            except Exception as e:
-                LogManager.logger.exception("Exception terminating scene launcher")
+        # relaunch all robots (in parallel) so they respawn at their start pose


anishk85 · 2026-07-12T17:29:28Z

hi @javizqh this is regarding the previous comment "Incorrect. Not all cfgs have a launcher"
i think this one might be a misread

originally i had two parallel lists (robot_launchers + robot_configs) and zipped
them, and you flagged that as "not all cfgs have a launcher".

to fix that i dropped robot_configs entirely — but then the launcher had to keep
its own entity / start_pose / extra_config so it could be re-run on reset,
which is why extra_config ended up stored here. that's what you're seeing now.

so the two comments pull in opposite directions: if i don't store the config on the
launcher i need the second list back (and the zip returns), and if i keep the second
list i'm back to the first comment.

i think the shape that closes both is a single list of pairs, so nothing is stored on
the launcher and there are no parallel lists that could drift:

# each entry: (launcher, config) — appended together, so they cannot diverge
self.robots = []
...
self.robots.append((LauncherRobot(**cfg.model_dump()), robot_cfg))
...
for launcher, robot_cfg in self.robots:
    launcher.run(
        robot_cfg["entity"], robot_cfg["start_pose"], robot_cfg["extra_config"]
    )

that drops extra_config from the launcher and removes the zip at the same time.
does that work for you, or would you rather i keep the config out of the manager
entirely and solve it a different way?

javizqh · 2026-07-12T17:34:05Z

There can be cases where there is no robot assign to a world, so the robot_cfg has a dummy value instead of a real one. In that case it does not have a launcher

anishk85 · 2026-07-12T17:39:19Z

you're right, thanks — i was only thinking about the case where every config is a
real robot. a world with no robot still sends a config, just a dummy one with no
type, so it gets skipped and never has a launcher.

i've restructured it so the two can't drift: the launcher and the config that
produced it are stored together as a pair, and a dummy config is skipped before the
pair is ever created.

self.robots = []
...
launcher = LauncherRobot(**cfg.model_dump())
self.robots.append((launcher, robot_cfg))
...
for launcher, robot_cfg in self.robots:
    launcher.run(
        robot_cfg["entity"], robot_cfg["start_pose"], robot_cfg["extra_config"]
    )

no zip, no parallel lists, and extra_config isn't stored on the launcher any more
either — it stays in the config and is read at run time.
How this seems to you ?

javizqh · 2026-07-12T18:02:37Z

This and the comment above are the same. The problem is that you are missing a simple if statement

anishk85 · 2026-07-12T18:07:51Z

ah, got it — i was overcomplicating this. you're right, it's just an if.

anishk85 · 2026-07-12T18:13:59Z

hi @javizqh requesting a review please pardon for any repeated ones as my local and upstream are litlle messed up.
i will fix that after confirming with these changes.

javizqh · 2026-07-12T18:35:34Z

@anishk85 are you using an LLM to write the comments here, the use of -- and reply patterns are strange? If you are doing so, please refrain from doing it any longer

anishk85 · 2026-07-12T19:36:34Z

@anishk85 are you using an LLM to write the comments here, the use of -- and reply patterns are strange? If you are doing so, please refrain from doing it any longer

Hey, just wanted to clarify something. I don't use any LLM to write my comments.

The difference you might notice is mostly because I switch between my phone and my laptop When I'm replying from my phone (like I did this time), I have the Grammarly keyboard turned on It automatically fixes grammar, punctuation, and sometimes even rephrases things a little, so the message can end up looking more polished than how I'd normally type.

The only reason I use Grammarly on my phone is because typing on a small keyboard is annoying and it's easy to make mistakes. It saves me from constantly fixing typos, especially when I'm having work-related or formal conversations on the go.

When I'm on my laptop, I usually just type everything myself, so my writing is a bit different. You'll probably notice the same kind of variation in my Slack messages too—it really just depends on which device I'm using at the time.

anishk85 · 2026-07-12T19:46:30Z

Okay, noted. Since I can't change it now from my phone at the moment due to some constraints, I'll reply to the GitHub thread from my laptop.

javizqh · 2026-07-12T19:49:22Z

Okay, no problem with that. Just, check the comment before sending it, I do not have the time to read a lot of comments and if they are nonsensical I lose even more time

anishk85 marked this pull request as draft July 9, 2026 21:25

javizqh requested changes Jul 10, 2026

View reviewed changes

javizqh mentioned this pull request Jul 10, 2026

manager.py: support multiple application processes #284

Closed

anishk85 force-pushed the multi-robot-parallel-spawn branch from b3291f8 to 8583162 Compare July 11, 2026 12:43

javizqh requested changes Jul 11, 2026

View reviewed changes

multi-robot support with parallel spawn

c8465a2

anishk85 force-pushed the multi-robot-parallel-spawn branch from 8583162 to c8465a2 Compare July 12, 2026 18:11

		from gz.transport13 import Node


		def _find_drone_namespaces():

Uh oh!

Conversation

anishk85 commented Jul 9, 2026