I build modular ROS 2 systems for mobile robots and manipulators β from navigation and planning to control, transforms, simulation and deployment.
ROS 2 Β·
Nav2 Β·
MoveIt 2 Β·
ros2_control Β·
C++ Β·
Python Β·
Gazebo
|
A complete ROS 2 + Nav2 autonomous navigation pipeline for a mobile robot, covering mapping, localization, planning, obstacle avoidance and mission-level autonomy. Engineering focus: lifecycle management, TF tree integrity, costmap tuning, QoS, behavior trees and reproducible launch configuration. Stack: |
A MoveIt 2 manipulation pipeline for collision-aware motion planning, kinematics, planning-scene interaction and trajectory execution through ROS 2 controllers. Engineering focus: planning groups, robot model configuration, controller interfaces, scene updates, IK targets and execution reliability. Stack: |
| Area | Technologies / Concepts |
|---|---|
| ROS 2 Core | Nodes, Topics, Services, Actions, Parameters, Launch, QoS, Lifecycle Nodes |
| Navigation | Nav2, AMCL, SLAM Toolbox, Costmaps, Planners, Controllers, Behavior Trees |
| Manipulation | MoveIt 2, OMPL, Planning Scene, IK/FK, MoveIt Servo |
| Robot Control | ros2_control, Controller Manager, Joint Controllers, Hardware Interfaces |
| Robot Modeling | URDF, Xacro, TF2, robot_state_publisher |
| Simulation | Gazebo / Gazebo Sim, RViz2 |
| Development | Modern C++, Python, CMake, Git, Linux, Docker |
I care about more than βmaking the node runβ. I try to build systems that are observable, modular and maintainable.
flowchart LR
S[Perception / Sensors] --> T[TF2 + State Estimation]
T --> N[Nav2 / MoveIt 2]
N --> C[ros2_control]
C --> H[Robot Hardware / Simulation]
L[Launch + Parameters] --> S
L --> T
L --> N
L --> C
Q[QoS + Lifecycle + Diagnostics] -. engineering discipline .-> S
Q -.-> T
Q -.-> N
Q -.-> C
- Correct frame semantics before algorithm tuning.
- Lifecycle-aware startup for deterministic bringup.
- Parameter-driven configuration instead of hard-coded behavior.
- Clear package boundaries between perception, planning, control and hardware.
- Reproducible simulation before hardware deployment.
- Logs, diagnostics and tests that make failures explainable.
Nav2 Β· MoveIt 2 Β· ros2_control Β· TF2 Β· RViz2 Β· Gazebo Β· SLAM Toolbox Β· AMCL Β· BehaviorTree.CPP
When I publish a robotics repository, I aim to include:
- Clear package / workspace structure
- One-command or documented launch flow
- Parameter files with sane defaults
- TF tree / frame documentation
- Architecture or data-flow diagram
- RViz / Gazebo demonstration
- Reproducible setup instructions
- Known limitations and failure modes
- Screenshots, GIFs or short demo video
- Technical notes explaining design decisions
Navigation β robust Nav2 behavior trees & tuning
Manipulation β MoveIt 2 planning + controller integration
Control β ros2_control hardware interfaces
Architecture β reusable ROS 2 bringup and launch patterns
Replace this block with what you are actively working on. It makes the profile feel alive without turning it into a wall of badges.
If you are building robots with ROS 2, Nav2, MoveIt 2 or ros2_control, feel free to reach out.
Built around real robotics work β not a badge collection.
