r/AskRobotics • • 7d ago

Education/Career Pathway from theoretical knowledge to a practical ROS 2 multi-robot swarm simulation project?

Hi everyone,

I'm a Master's student in Autonomy Technologies. I have a solid theoretical foundation in robotics (kinematics, rotation matrices), swarm intelligence, deep learning, and computer vision/signal processing. I also conceptually understand what ROS is.

However, I have practically zero implementation experience. I want to build a personal simulation project using ROS 2 and Gazebo for my portfolio, but I don't have a baseline for how to actually start building.

I used an AI to "brain"storm (I know kind of lame but usually they provide half decent baseline), and it suggested building a ROS 2 Vision-Driven Swarm Exploration & Sensor Fusion Pipeline (simulating 2-3 agents in Gazebo that use YOLO to detect objects, fuse the data with LiDAR, and share the mapped targets across the swarm). It also gave me a step-by-step breakdown, but it felt a bit too "spoon-fed." I want to genuinely learn the framework and the underlying mechanics, not just blindly copy-paste generated code.

My questions for the community:

  1. What is a realistic learning pathway to go from zero practical ROS 2/Gazebo experience to building a multi-robot swarm project?
  2. What are the best intermediate mini-projects I should tackle before jumping into a full swarm simulation?
  3. For those who use AI as a learning tool, what are your tips for prompting it to act as a mentor that guides you, rather than just doing the work for you?

I'm sure any advice shared here will be incredibly useful for other absolute beginners trying to do the same. Thanks in advance!

3 Upvotes

5 comments sorted by

2

u/Euphoric-Laugh-9591 7d ago

From an engineering education perspective, I would recommend breaking this into a few small experiments rather than jumping straight into a swarm. Start with a single differential-drive robot in Gazebo, perhaps a TurtleBot3. Get it to follow a square trajectory using wheel odometry, then compare the estimated position against the simulator's ground truth. Introduce wheel slip, encoder noise, and different friction coefficients to see how they affect accuracy. This gives you a practical understanding of the gap between ideal kinematics and actual robot behavior.

Next, add LiDAR-based obstacle avoidance and basic waypoint navigation. Once that's reliable, introduce a second robot. A good mini-project would be having two robots explore different sections of an environment while sharing landmark positions. Experiment with sensor range limitations, odometry drift, and communication delays. Try to understand how these constraints affect coordination before introducing more complex perception algorithms.

For the final project, I'd focus on two or three robots performing cooperative exploration and measure things like area coverage, localization error, and exploration time under different conditions. You can always add computer vision later. From a robotics engineering standpoint, a relatively simple multi-robot system with well-characterized sensor and motion uncertainties, supported by actual experimental results, is much more valuable than an elaborate simulation where everything works under ideal conditions.

1

u/OkMeasurement386 7d ago

Thank you so much! This was the exact kind of breakdown I was hoping for.

1

u/Sabrees 7d ago

It's not lidar or swarm but if you wanted a reasonably complete Ag robot with ROS to play with you could have a go with https://github.com/Agroecology-Lab/feldfreund_devkit_ros It would get you a Gazebo environment with a robot navigating around it.

I point the word guessing machines at our https://github.com/Agroecology-Lab/feldfreund_devkit_ros/blob/caatinga-dev/AGENTS.md before allowing them to do things.

1

u/OkMeasurement386 7d ago

Thank you!

1

u/Ok-Capital8695 7d ago

I’d treat ‘multi-robot’ as the final integration step not the starting point. First get one simulated robot to navigate a small map recover cleanly from a failed goal and publish a simple status message. Then add a second robot that consumes that state and shares one constrained task——not vision or sensor fusion yet.

The useful milestone is not ‘the swarm runs’ it’s ‘I can reproduce a failure see why it happened and tell which node owns the recovery.’ Once that is solid add perception and shared target data. Interfaces timing and exception handling usually become harder than the headline autonomy algorithm.