Skip to main content

Roadmap to Embedded & Robotics Engineering

· 23 min read
Ben Li
Ben Li
Software engineer
Chat GPT
Chat GPT
AI Assistant

Month 1: ROS 2 Foundations & Microcontroller Basics (Weeks 1–4)​

  • Week 1 – ROS 2 Setup and Fundamentals: Install ROS 2 (latest LTS) and set up your Linux development environment. Review ROS 2 architecture (nodes, topics, services, parameters) and command-line tools . Complete introductory tutorials (talker/listener, turtlesim) to build basic ROS 2 skills . Milestone: You can run a simple ROS 2 talker/listener demo and understand the core concepts.

  • Week 2 – ROS 2 Nodes & Packages: Create your first custom ROS 2 package. Write a C++ node that publishes a dummy sensor message (e.g. a counter or random number) and a Python node that subscribes to it. Practice building with colcon and using rviz or rqt to visualize topics. Explore ROS 2 client libraries and differences from ROS 1 (if applicable). Milestone: A custom ROS 2 package with C++ and Python nodes communicating successfully.

  • Week 3 – Microcontroller Environment Setup: Set up development tools for STM32H753ZI (e.g. STM32CubeIDE or PlatformIO). Blink an LED and read a button input on the STM32 to verify the toolchain. If using an RTOS (FreeRTOS), create a basic task for blinking LED. Repeat a similar “blinky” test on the ESP32-S3 (using ESP-IDF or Arduino framework) to familiarize yourself with both controllers. Milestone: Both STM32 and ESP32 environments are verified by running basic firmware (LED blink, serial hello-world).

  • Week 4 – C++ on MCU & Sensor I/O: Write a simple C++ program on the STM32 to interface with hardware peripherals. For example, read an IMU sensor over I²C (or SPI) and output the readings over UART. Implement a basic PID loop in the microcontroller: e.g., use a potentiometer as input and a LED brightness (PWM) as output to simulate controlling a “process” to a setpoint, just to practice control logic timing. Keep code efficient and use interrupts or RTOS for timing if needed. Milestone: You can read a sensor and actuate an output with a control loop on the STM32, and understand microcontroller C++ basics (registers, HAL libraries, interrupts).

Checkpoint (End of Month 1): You have a solid grasp of ROS 2 basics and a working embedded dev setup. You can develop simple ROS 2 nodes and microcontroller firmware in C++, setting the stage for integration.

Month 2: ROS 2 ↔ Microcontroller Integration (Weeks 5–8)​

  • Week 5 – Intro to micro-ROS: Learn how micro-ROS brings ROS 2 into microcontrollers . Read the micro-ROS docs about the client-agent architecture (ROS 2 nodes on MCU acting as clients to an agent on PC). Follow a tutorial to set up micro-ROS on the STM32 (e.g. using FreeRTOS + micro-ROS) . Start with a basic micro-ROS publisher on the STM32 that sends IMU or dummy data to a PC ROS 2 node (the micro-ROS agent). Milestone: STM32 board successfully publishes a ROS 2 topic via micro-ROS (e.g. a sensor_msgs/Imu or a custom message) and you can echo it on the PC.

  • Week 6 – Two-Way Communication: Extend to a subscriber on the microcontroller. For instance, a PC ROS 2 node could publish a command (like an LED toggle or motor speed), and the STM32 (or ESP32) running micro-ROS subscribes and acts on it. Ensure real-time behavior by running the micro-ROS node in its own task (if using RTOS). This solidifies understanding of DDS-XRCE communication. Experiment with both STM32 and ESP32-S3 for comparison – ESP32 has Wi-Fi, so you might try a UDP transport for micro-ROS. Milestone: Achieve bi-directional ROS 2 comms – send a command from a ROS 2 terminal to toggle an MCU LED or move a servo, and confirm feedback from MCU sensors in ROS 2.

  • Week 7 – Motor Control 101: Begin controlling motors with the microcontroller. Start simple: a DC motor or servo motor. If using a DC motor with encoder, set up a timer interrupt to read the encoder and a PWM output to drive the motor driver. Implement a basic velocity PID controller on the MCU to maintain a set speed. If using a servo (which has internal control), practice commanding positions via PWM. This will prepare you for Field-Oriented Control later by understanding control loops. Integrate ROS 2 by sending motor commands from a PC node to the MCU. Milestone: One motor can be controlled in closed-loop (speed or position) by the microcontroller, with commands and telemetry accessible in ROS 2 (e.g., you can set a speed via a ROS topic and the motor maintains it, reporting encoder ticks).

  • Week 8 – Real-Time Control & Sensing: Refine the motor control with real-time considerations. Use FreeRTOS on STM32 to run the control loop at a fixed frequency (e.g. 1 kHz for motor PID) in one thread, and ROS communication in another. Add the IMU into the loop: mount the IMU on the motor or a platform and try a simple balancing experiment. For example, if you mounted a rod or platform on the motor, attempt to keep it upright (inverted pendulum style) using the motor – a classic control problem to tune your PID. This may be challenging, but even partial success teaches a lot. Meanwhile, stream IMU and encoder data to ROS 2 for debugging (e.g. plot angles in rqt_plot). Milestone: Hard real-time control is running on the MCU, and you’re comfortable with multitasking on FreeRTOS and tuning PIDs. You have possibly achieved a simple balance control or at least a well-tuned motor controller.

Checkpoint (End of Month 2): Your microcontroller acts as a ROS 2 node , bridging the embedded and ROS worlds. You’ve controlled a motor with feedback, a critical step for any robot. You’re ready to build actual robotic hardware.

Month 3: Building a Mobile Robot & Advanced Control (Weeks 9–12)​

  • Week 9 – Build a Basic Robot Platform: Using your hardware skills, construct a simple ground robot for testing control algorithms. One suggested project is a self-balancing two-wheeled robot (like a mini Segway): it uses two motors and an IMU – leveraging your Week 8 progress. Alternatively, build a single-leg test rig: a 2-DOF leg (hip and knee) with encoders. The balancing robot is easier as it’s a well-known project, so consider starting there. Assemble the chassis, mount the STM32 (or ESP32) as the controller, and wire up the IMU and motors (and motor drivers or ESCs). Milestone: Mechanical build completed for a small robot (balancing bot or leg prototype), and all sensors/motors are interfaced with the microcontroller.

  • Week 10 – Balance Control with Feedback: Program the balancing robot to achieve upright balance. This involves using the IMU to sense tilt and adjusting motor speeds to correct it (a classic inverted pendulum control problem). Use a PID or even more advanced controllers if needed. You might spend a lot of time tuning gains here – that’s normal. Integrate ROS 2 for monitoring and high-level control: for example, create a ROS 2 node that sends a target tilt angle or velocity to the robot. Achieve remote control: send a forward command, and the robot leans forward to roll that direction while self-balancing. If working with the single leg instead, focus on inverse kinematics – move the leg end-point in a straight line by coordinating hip and knee joints, using kinematic equations. Milestone: The balancing bot can stand upright for an extended period and respond to simple ROS 2 commands (e.g., move forward/backward while balancing), or the single leg can precisely move to commanded positions, showing mastery of kinematics and feedback control.

  • Week 11 – Toward a Quadruped – Actuators Setup: Begin planning your quadruped robot (robot dog). Determine the actuator setup: for high performance, use brushless BLDC motors with encoders on each joint to enable torque control; or initially, use simpler servos to prototype leg motion. Given your goal of 4–6 Field-Oriented Control (FOC) motors, you may choose to use 8–12 motors (3 per leg for a true quadruped). If you have brushless gimbal motors and encoders (common in drone gimbals), try the SimpleFOC library or reference designs to control them on the STM32. Each motor will run FOC for smooth torque control – critical for legged robots to act compliantly. Milestone: One joint module is set up with a BLDC motor + encoder under FOC control. For example, you can command a joint to hold a position or apply a certain torque. (FOC enables “superior torque control” for brushless motors , which is why we pursue it.)

  • Week 12 – Quadruped Mechanical Assembly: Design or obtain a frame for your quadruped. You might 3D print parts or use an open-source design like Solo 8 as inspiration (an open-source torque-controlled quadruped) . Assemble the quadruped’s legs and body, starting with a minimal setup (even two legs to form a biped can be a start, then add others). Mount motors, encoders, and necessary microcontrollers on the robot. If using multiple MCUs (one per leg or per few motors), set up a communication bus (CAN bus or serial) between them, or have each run micro-ROS and communicate via the ROS 2 agent on a central computer. Milestone: The physical quadruped robot is assembled with all actuators in place. When powered, you can individually command each joint via your microcontroller code (e.g., each leg can be moved through its range under control).

Checkpoint (End of Month 3): You have a working small robot (balancer or leg) and a proto-quadruped assembled. Crucially, you’ve implemented FOC motor control and multi-motor coordination on microcontrollers, a big step toward dynamic leg control . At this stage, you’re comfortable with sensors, actuators, and ROS 2 integration on real hardware.

Month 4: Gait Development & ROS 2 Integration (Weeks 13–16)​

Solo 8 open-source quadruped performing dynamic motion. By this phase, you will have a basic quadruped robot and start developing locomotion gaits, leveraging torque-controlled joints similar to those in Solo 8 .

  • Week 13 – Basic Gait Implementation: With the quadruped’s hardware ready, program a simple walking gait. Start with a crawl gait (one leg moves at a time, keeping 3 on ground for stability). Write a schedule for leg swings and use your motor controllers to move joints accordingly. Initially, use position control (move joints to predefined angles for each phase of gait). Test on the real robot slowly – you might need to support it to prevent falls during tuning. Use ROS 2 to send high-level commands like “walk forward” or “turn”, which your MCU code translates into gait patterns. Milestone: The quadruped takes its first steps, albeit slowly and quasi-statically. You can command it via ROS 2 to walk forward a short distance on flat ground.

  • Week 14 – Feedback and Stability: Incorporate feedback to improve stability. Use the IMU on the robot body to detect if it’s tilting too far. Implement a basic stabilization: e.g., adjust leg positions or timings if pitch or roll exceeds a threshold (a simple form of balance control). You could also add foot sensors (switches or pressure sensors) to detect contact – ensuring a leg has touched ground before lifting another. Start experimenting with more dynamic gaits like trot (moving diagonal legs together) once you have some feedback control. In trot, the robot will have moments with only two legs on ground, so your IMU-based balancing becomes crucial. Milestone: The robot can trot a few steps without falling, using IMU feedback to self-correct minor disturbances.

  • Week 15 – ROS 2 Perception Integration: Mount a camera (e.g. an ESP32-CAM or USB camera feeding into a PC) on the robot. While locomotion is still under refinement, begin integrating perception to move toward an “AI-capable” robot. For instance, use the camera feed in a ROS 2 node running on a companion computer (like a laptop or Raspberry Pi) and perform a simple vision task (like detecting a colored ball or AprilTag). This week, keep the task simple: e.g., the robot looks around (turns in place) until the camera sees a target, then you stop. This sets up the pipeline for more advanced uses where vision could inform locomotion (obstacle avoidance, path planning). Milestone: Camera data is accessible in ROS 2, and you have a basic vision-in-the-loop demo (even if just teleop: you can drive the robot via a gamepad using camera view).

  • Week 16 – Autonomous Control Mode: Combine your progress to enable a simple autonomous behavior. For example, implement a “go to goal”: place a colored object and have the robot walk towards it. This involves tying vision to locomotion – e.g., a ROS 2 node processes camera frames (perhaps using your YOLO knowledge to detect the object), computes a direction, and sends a velocity command to the quadruped. You may use ROS 2 Navigation stack’s planner for high-level path planning on a map, but since legged locomotion is complex, you can also do a simpler approach: if object is seen, turn towards it and move forward until a certain distance. Ensure your locomotion controller can handle commands for direction and speed (you might implement a rudimentary teleop interface that translates desired forward/turn velocities into gait parameters). Milestone: The robot demonstrates an autonomous task on flat terrain – e.g., it can walk toward a visual target or follow a simple preset route without constant human micromanagement.

Checkpoint (End of Month 4): Your quadruped robot is walking under its own control. It handles basic gaits with sensor feedback and can be controlled via ROS 2 commands. You’ve also integrated a camera sensor, laying groundwork for AI and autonomy. At this point, your skill set spans embedded motor control, real-time feedback loops, ROS 2 middleware, and even some high-level perception – a huge stride toward advanced robotics engineering.

Month 5: Reinforcement Learning for Locomotion (Weeks 17–20)​

  • Week 17 – Simulation Setup for RL: Transition into the learning phase to push the robot’s capabilities. Set up a physics simulation of your quadruped (using Gazebo Ignition, PyBullet, or Isaac Gym). Import your robot’s URDF model into the simulator; simplify if needed (e.g., use a simplified collision model, approximate motor behavior). Verify that the simulated robot can stand and manually walk with the same gait commands as the real robot. Simulation allows safe experimentation with advanced control. Milestone: You have a working simulation environment for the quadruped, and you can teleop the simulated robot in ROS 2, confirming that the model behaves reasonably like the real hardware.

  • Week 18 – RL Problem Formulation: Define the reinforcement learning problem for locomotion. Decide on the state representation (e.g., IMU angles, body orientation, joint angles, joint velocities, foot contact indicators) and the action space (e.g., target joint positions or torques). A common approach is to have the policy output desired joint angles or torque offsets for each motor at each control step . Design a reward function that encourages forward walking while penalizing falls, high tilt, or unstable motions . For example, reward forward velocity and penalize deviation from upright posture. Use an existing RL library (Stable Baselines3 with PPO is a good choice, as Proximal Policy Optimization (PPO) is popular for legged robots ). Set up the training code, connecting it to the simulation (maybe through ROS topics or a direct physics engine API for speed). Milestone: Your RL training environment is ready – you can run episodes in simulation where the quadruped starts, attempts to walk, and gets rewards. You’ve essentially defined “what” the robot should learn (policy maps observations to motor commands) .

  • Week 19 – Train Locomotion Policy: Run training for your RL policy in simulation. This may take many iterations, so use your powerful PC or cloud if available, and consider parallel simulations for efficiency . Monitor training progress: the robot should start off random, but over time learn to move forward without falling. Tweak hyperparameters or reward terms if it gets stuck (for example, add a small reward for moving any leg to encourage exploration). Implement domain randomization during training – randomize factors like friction, motor strength, or sensor noise . This helps the learned policy be robust for the real world (improving sim-to-real transfer). By the end of the week, you might have a policy that can make the simulated robot walk with decent stability. Milestone: A trained RL policy (neural network controller) that enables the simulated quadruped to walk forward (and maybe turn) consistently. You should also document results – e.g., the policy achieves a certain average reward or distance without falling, in simulation.

  • Week 20 – Real-World Deployment Prep: Prepare to deploy the learned policy on the real robot (this is where things get exciting!). Ensure you can run the neural network in ROS 2 – likely on a companion computer (Raspberry Pi, NVIDIA Jetson, or a laptop) because a STM32/ESP32 is not powerful enough for runtime inference of a large network. You might use TensorFlow Lite or ONNX runtime on the companion computer. Connect the policy output to your robot’s ROS control interface: for instance, the policy outputs desired joint angles at 20 Hz, and you have a ROS 2 node sending those to the microcontrollers which execute position control. Plan safety measures: start with lower torques/speeds, have an e-stop ready. Milestone: The RL policy is integrated into the ROS 2 control stack, ready to drive the real robot in testing. All components (policy inference node, micro-ROS motor controllers, etc.) are communicating properly.

Checkpoint (End of Month 5): You have gained experience with deep reinforcement learning for locomotion. In simulation, your robot learned to walk via trial and error – a cutting-edge capability . You’ve set the stage to attempt sim-to-real transfer of this learned behavior onto your actual quadruped.

Month 6: Sim-to-Real Transfer & Advanced Control (Weeks 21–24)​

  • Week 21 – Deploy RL Policy on Robot: Time to see your robot walk under AI control. Run the trained policy on the real quadruped. Initially, keep the robot on safety harness or support to prevent hard falls. It will likely stumble as the dynamics differ from simulation. Observe its behavior: does it move its legs in a coordinated way? If it falls quickly, you may need to refine the policy or increase randomization. You could also try online learning: have the robot attempt to walk and, if safe, let it continue learning on hardware in small bursts (though this is risky and requires careful reward handling). More practically, adjust the policy using slight system identification tweaks – e.g., scale outputs or add a secondary balance controller (PID using IMU) that corrects small errors on top of the policy. Milestone: The quadruped can take a few steps in reality with the RL policy. It might not be perfect, but even a few seconds of autonomous learned walking is a big achievement in sim-to-real reinforcement learning.

  • Week 22 – Iterate and Improve: Likely, you will iterate between simulation and real testing. Analyze failure cases on the real robot: for example, maybe the policy wasn’t exposed to enough friction variation and the feet slip, or it oscillates. Update your simulation environment to include those cases (e.g., add slight delays or sensor noise, or use a higher fidelity physics engine if needed). Train a new policy or fine-tune the existing one with domain randomization more aggressively to bridge the gap . Another approach is Residual Learning: keep a classical controller (from Month 4) and have the RL policy learn a residual correction on top of it – this can ease the learning burden. Continue this sim-to-real refinement cycle. Milestone: A revised policy that significantly improves real-world performance – e.g., the robot can walk across your living room floor reliably for a minute or more without falling. Each iteration reduces the gap between simulated and real behavior.

  • Week 23 – Advanced Locomotion Skills: With a working walking policy, you can push further. For instance, train (or program) the robot to turn and maneuver to follow a path. Extend the observation space to include a target direction or point, so the policy can guide the robot toward it. You could also work on speed control – train the policy to walk at different commanded speeds (include the desired speed as an input). Meanwhile, test the robot on slightly uneven terrain (a foam mat or a small ramp) to see how it adapts. This will highlight the robustness of your controller. You might incorporate Rapid Motor Adaptation (RMA) techniques or other recent research that allow on-the-fly adaptation to terrain by estimating ground parameters – cutting-edge stuff, but worth reading up on if interested . Milestone: The robot demonstrates turning and variable-speed walking, possibly using the learned policy with additional inputs. It can handle mild terrain variations or recover from small pushes, showing a degree of robustness and adaptability.

  • Week 24 – Evaluation and Demo: Consolidate everything you’ve achieved in a final demonstration. For example, set up an obstacle course or a set of tasks: the robot must walk to a location, avoid an obstacle (you can use simple logic or a separate planner for avoidance), and maybe perform a trick like standing up after a fall or climbing a small step (if hardware permits). Use ROS 2 bags to record data during these tests for later analysis of performance (e.g., analyze how stable the roll/pitch were, how often it had to stop to regain balance, etc.). Compare the performance of your RL controller to the earlier hand-crafted gait: is it smoother or more efficient? Often RL can discover gait patterns that are non-intuitive but effective . Document these findings. Milestone: A complete demonstration of your robot dog’s capabilities is recorded – you’ve essentially built and trained a legged robot that can perceive and navigate simple scenarios on its own.

Checkpoint (End of Month 6): You have brought state-of-the-art techniques to fruition: your robot learned to walk through reinforcement learning and operates in the real world. This experience is directly in line with modern legged robotics research, where learning-based controllers are unlocking agility previously seen only in very expensive systems . You’re now truly functioning at the level of a professional embedded/robotics engineer pushing the boundaries of locomotion.

Months 7–9: Mastery and Expansion (Weeks 25–36)​

  • Weeks 25–28 – Deep Dive into Embedded Systems: Use this period to reinforce low-level expertise that underpins advanced robots. Revisit your STM32 motor control firmware and attempt to optimize it. For example, implement Field Oriented Control from scratch (without relying on SimpleFOC) to deepen your understanding of the math (Park/Clarke transforms, PID for Id/Iq currents). Test the custom FOC on one joint and compare torque control performance to the library version. Additionally, explore advanced microcontroller features: use DMA to handle sensor data without CPU, implement CAN bus communications between multiple controllers for coordinating legs (many quadrupeds use one MCU per leg or per joint, networked over CAN for synchronization ). Also experiment with FreeRTOS features like message queues or timers to make your firmware more robust. This deepens your embedded systems mastery, ensuring you can build reliable real-time systems.

  • Weeks 29–32 – Bipedal Robotics (Stretch Goal): Tackle the next challenge: bipedal robots. Repurpose your quadruped by using only two legs (or design a new small biped). Start with getting a biped to stand using feedback control (this is essentially two balancing robots stacked). Implement a balance controller using both feet (shifting weight). Reuse your IMU and foot sensors for detecting when a foot is on the ground. Gradually work on walking – start with side-to-side weight shifting, then stepping one foot forward (perhaps with a boom or support to catch it). This project will test everything you’ve learned: real-time control, feedback loops, and possibly RL (bipedal walking is even harder than quadrupedal). Even if full dynamic walking is not achieved in this short time, the attempt will massively increase your understanding of humanoid balance and control algorithms (inverted pendulum models, zero-moment point, etc.). By the end of Week 32, you might have a biped that can take a step or at least stand and recover from a push for a few seconds. This is excellent preparation for eventually tackling drones again, since balancing a biped has parallels to stabilizing a drone (both are complex dynamic systems).

  • Weeks 33–36 – Final Projects and Transition to Drones: In the final stretch, consolidate your knowledge by undertaking a capstone project. One idea: integrate an arm or manipulator onto your quadruped (or use a 6th motor on one of the legs as a small grabbing arm) and program a manipulation task (like pushing a door or picking up an object). This adds another layer (manipulator kinematics and control) on top of locomotion – reflecting real-world robotics problems where a robot needs to both move and interact with objects. Another idea is to revisit drones, now armed with ROS 2 and advanced control skills: build a drone that uses ROS 2 flight controllers (PX4 has ROS 2 support) and maybe implement an autonomous vision-based landing or navigation system to tie in AI skills. Allocate time to document your projects, polish your code, and perhaps contribute to open-source projects or publish a blog/video about your robot dog’s journey. This will not only solidify what you learned by teaching others, but also showcase your skills to potential employers or collaborators. Milestone (End of Month 9): You have one or two impressive portfolio projects (e.g., a walking robot dog with an arm, or an autonomous drone mission) demonstrating broad mastery. You can confidently call yourself an Embedded & Robotics Engineer with expertise in ROS 2, microcontrollers, motor control, and machine learning for robots.

Conclusion and Next Steps​

By following this 9-month roadmap, dedicating ~3 hours on weekdays and heavy practice on weekends, you’ve progressed from a software developer to a hands-on roboticist. Along the way, you focused on ROS 2 and relevant tools (no time wasted on unrelated simulations), dove deep into STM32 and ESP32 microcontroller programming (timers, RTOS, drivers, etc.), and implemented real-time control for multiple FOC motors with sensor feedback. You built a legged robot from scratch and leveraged modern reinforcement learning to achieve locomotion that would be very difficult to hand-engineer, aligning with cutting-edge developments in the field . Each phase included 1–2 week projects and milestones, ensuring steady progress and a sense of achievement. Going forward, you can extend these foundations to more complex systems (like full humanoid robots or aerial vehicles). The focus on ROS 2 and microcontrollers will serve you well in any advanced robotics project – including future drone development when you circle back to it with your new skill set. By continuously challenging yourself with projects (as we structured with regular checkpoints), you’ve built not only knowledge but also a robust engineering workflow for solving robotics problems. Congratulations on your journey to becoming a professional embedded/robotics engineer, and best of luck building the next robot dog or whatever innovative robot comes next!

Sources:

  • ROS 2 Tutorials – ROS 2 official documentation (Humble)
  • micro-ROS Overview – ROS 2 for Microcontrollers
  • FOC for Torque Control – Brushless motor controller for legged robots
  • Solo 8 Open-Source Quadruped – NYU & MPI torque-controlled robot
  • RL Locomotion Training – Federico Sarrocco, “Quadrupeds Learning to Walk”
  • Robot Learning Applications – Solo 8 press release (NYU)