Monday Learning #1 One lesson I learned from building robotics systems: Every sensor eventually fails. The goal isn’t to find a perfect sensor. The goal is to design a system that can recognize bad data before making a bad decision. In robotics, reliability often matters more than accuracy. A robot that’s 99% accurate but crashes once per hour is less useful than a robot that’s 95% accurate and works all day. Robotics isn’t just about making systems intelligent. It’s about making them dependable. #Robotics #EmbeddedSystems

Industry Insight #14 Two robots from different vendors meet in a narrow aisle. Who goes first? I’m interested in what happens when a site adds its second robot supplier, not just its second robot. Imagine one fleet moving parts and another making deliveries. Both need the same corridor, doors, or elevator. Each robot might navigate well on its own. That doesn’t mean the fleets have a shared plan for using that space. Who waits? Where can it wait without blocking another job? What happens when both need the elevator? That’s what interests me about @OpenRoboticsOrg’s Open-RMF. It helps coordinate robot fleets and shared infrastructure like doors and elevators. But the fleets still need software adapters to connect them, along with site-specific configuration. Two robots being autonomous doesn’t automatically make them compatible. When looking at a deployment, I’d want to know how much work it takes to add another vendor’s robot. Not just, “Can this robot work here?” But, “Can it work alongside everything already here?” For anyone working with mixed fleets, what has been harder: connecting the systems or coordinating how they share the space? #Robotics #Automation #MobileRobotics #OpenRMF

An empty gripper can clear an obstacle. The block it picks up might not. I’ve worked on block stacking with a Kinova Gen3 Lite, and it’s a useful example of a planning detail that’s easy to overlook. Once the robot picks up a block, the arm and gripper aren’t the only things moving through the workspace. The block needs clearance too. A path that works before the grasp might not work afterward, especially if the object extends beyond the fingers. MoveIt, which @PickNikRobotics contributes to, lets you attach the block’s collision geometry to the gripper in the planning scene. Collision checks can then account for the space the block occupies as the arm moves. Closing the physical gripper alone doesn’t give the planner that information. After placement, the scene needs updating again. The object is back in the environment, not attached to the hand. I like this because it makes a simple pick-and-place sequence more interesting to watch. It’s not just reach, close, move, release. The planner’s model of the workspace has to change along with the task. Getting a good grasp matters. So does remembering what’s now sticking out of the gripper. #Robotics #MoveIt #MotionPlanning #ROS2

What the Robot Taught Me #10 The object doesn’t have to get heavier for a robot’s joints to work harder. Think about holding a book close to your chest, then holding it out at arm’s length. Same book. Different leverage. I’ve used a @KinovaRobotics Gen3 Lite for block stacking, and it’s a useful task for thinking about this. The block weighs the same throughout the move. But its leverage changes with the arm’s posture, so the torque needed at individual joints can change too. That’s why “How much can it lift?” doesn’t tell the whole story. Where is the load’s center of mass? How is the arm positioned? What do the gripper and attached tooling add to the load? Even before considering acceleration, the geometry matters. I like this because it connects something you can feel in your own arm to what’s happening in a robot. When watching a pick-and-place demo, it’s worth looking beyond the object. Watch the posture the arm uses to carry it. The weight is only part of the story. #Robotics #Mechatronics #RobotManipulation #MechanicalEngineering

Weekly Reflection #13 A robot writing my initials isn’t going to change the world. I’m still glad I worked on it. The same goes for getting a robot arm to throw a ball into a cup. I like that someone can watch either video and immediately understand the goal. You don’t need to know ROS 2 or motion planning to ask, “Did the ball go in?” But working on those simple-looking tasks gave me plenty to think about, from the path of the pen to the moment the gripper releases the ball. Between career goals and bigger project ideas, it’s easy to feel like everything I build needs an impressive purpose. I want to keep some room for projects that start with, “I wonder if I can make this work.” They don’t all need to become products. A small experiment can be worth the effort because of what you learn while making it happen. What’s something you built purely because you were curious? #Robotics #Engineering #LearningByDoing

Industry Insight #13 The next robot demo I want to see starts with someone changing the job. Show the robot stacking one box size. Then change the box size and the pallet pattern. How long before it’s ready to run again? Can an operator update a recipe? Does the gripper need adjusting? Does an engineer need to change the program? And what needs checking before production restarts? I’m interested in that transition, not just how fast the arm moves once everything is ready. That’s what caught my attention about @Robotiq_Inc’s palletizing software: letting trained operators create new recipes without calling an integrator. For short production runs, I’d want to see changeover time alongside cycle time. To me, flexibility isn’t just how many jobs a robot can do. It’s how much work it takes to switch between them. What usually takes longest during a changeover: tooling, programming, or validating the new setup? #Robotics #Automation #Manufacturing #Engineering

Give a robot a pen and “just move between these two points” suddenly isn’t enough. I used a @KinovaRobotics Gen3 Lite to write my initials. It’s a nice example of something that can be easy to miss when watching a robot move. The joints can move smoothly while the pen tip traces a curve. Smooth joint motion and a straight line on the board are not the same thing. For a straight stroke, the pen needs to follow a line in physical space. The arm’s joints have to coordinate around that path. That’s where Cartesian path planning comes in. You describe the path the pen should follow, not just where it should finish. The planner then works out the joint motion needed to follow that path. There’s a catch, though. The path still has to be reachable and respect the robot’s limits. Asking for a straight line doesn’t make every line possible. I like how visible this becomes in a writing task. The pen leaves a record of the entire motion. There’s more to look at than whether the arm reached the endpoint. #Robotics #MotionPlanning #ROS2 #Mechatronics

What the Robot Taught Me #9 A robot can run the right code and still behave unpredictably because of its power system. Working with embedded hardware and actuators has made me appreciate how much happens outside the firmware. A motor starts. Current demand jumps. The supply voltage dips. Switching noise can reach sensitive circuits through shared power and ground connections. Suddenly, you have what looks like a software problem. The controller resets. A sensor reading spikes. Communication becomes unreliable. The code may be doing exactly what it should. The electrical conditions it depends on may have changed. That is why I try not to look at firmware alone when debugging. I also ask: Does the voltage dip when the motor starts? Are motor currents sharing a return path with sensitive electronics? Could switching noise be reaching the sensors? Is the power supply adequate for the load, not just the idle system? This is also why I find the embedded and motor-control work from @ST_World interesting. Reliable robot behavior depends on much more than the code running on the controller. Software never runs in isolation. Sometimes the next debugging step is measuring the power rail, not rewriting the firmware. #Robotics #EmbeddedSystems #Mechatronics #Electronics #WhatTheRobotTaughtMe

One challenge I’d stress-test in both Optimus and Cybercab: recognising when the next action is no longer safe. For Optimus, imagine a load shifting during a handoff while its view of the grip is blocked. One approach worth testing is cross-checking vision with force and motion feedback, then adjusting the grip or placing the load down safely. For Cybercab, imagine glare or a dirty camera reducing visibility near a crossing. Monitoring camera quality should inform speed and planning, with a fallback suited to the surrounding traffic if safe driving cannot continue. I’d test both by deliberately introducing sensor degradation, delays and unexpected movement in simulation and controlled environments. Measure detection time, safe recovery and unnecessary interventions. A confidence score alone would not prove the system is safe. These are general engineering scenarios, not claims about Tesla’s current safeguards. The benchmark that interests me is how reliably physical AI handles the moment reality stops matching its plan. @elonmusk @aelluswamy @larsmoravy

Writing robot code is one thing. Figuring out why the real robot failed is another. I'd love to see GPT-6 Astra tested on sensor logs, timing traces and failed grasps, with fixes verified on hardware. @sama, helping engineers understand why a robot failed would be a robotics demo I'd really want to see.

Weekly Reflection #12 The more robotics I learn, the less often I say, “This should be easy.” A sensor sounds simple until noise shows up. A motor sounds simple until the load changes. A grasp sounds simple until the object moves. Navigation sounds simple until the robot is unsure where it is. And integration sounds simple until everything works individually but not together. I used to see unexpected complexity as a sign that something had gone wrong. Now I see it differently. The physical world has a way of exposing assumptions that looked perfectly reasonable on paper. That is probably one of my favorite things about robotics. It keeps you humble. Every project teaches you something about the robot. And usually something about the assumptions you brought into the problem. #Robotics #Engineering #Mechatronics #PhysicalAI #WeeklyReflection

Industry Insight #12 I think robotics is entering a phase where the hardest problems are less about individual components and more about coordination. We already have: Better perception. Better planning. Better actuators. Better foundation models. Better simulation. But real robots still fail when those pieces do not work together at the right time. A perception model can be accurate and still be too slow. A planner can find a valid path that the hardware cannot execute cleanly. A controller can be stable while the sensing pipeline feeds it outdated information. The next big gains in robotics may not come from making every component dramatically better. They may come from making the entire system better at handling timing, uncertainty, constraints, and failure. That is why I think systems engineering is becoming one of the most important skills in robotics. The smartest component does not make the smartest robot. The system still has to work as one. #Robotics #PhysicalAI #SystemsEngineering #Autonomy #IndustryInsight

A good sensor in the wrong place can still give you bad data. That sounds obvious, but it is easy to underestimate. When I started working more with sensors on robotic systems, I focused heavily on: Which sensor should I use? What is its accuracy? What is the sampling rate? But placement can matter just as much. Mount an IMU too close to a vibration source and the signal changes. Place a force sensor where the load path is different from what you assumed and the reading becomes misleading. Move a camera slightly and suddenly your field of view, occlusion, and calibration all change. The sensor might be working perfectly. The system around it determines whether the data is actually useful. That changed how I think about sensing. I do not only ask: “Is this the right sensor?” I also ask: “Is this the right place to measure from?” It is one reason I find the sensing work from companies like @BoschGlobal interesting. Sensor performance is not just about the datasheet. It is about how that sensor behaves once it becomes part of a physical system. In robotics, measurement starts before the data ever reaches the software. #Robotics #Sensors #EmbeddedSystems #Mechatronics #SystemsEngineering

What the Robot Taught Me #8 Making a robot more rigid does not always make it better. That took me a while to appreciate. In mechanical design, stiffness often feels like the obvious goal: Less deflection. More precise motion. Better position control. But once a robot starts interacting with the physical world, some compliance can actually help. Objects are not always exactly where the model predicts. Surfaces are not perfectly aligned. Humans move. Impacts happen. A system with no ability to accommodate those differences can turn a small positioning error into a large contact force. That changed how I think about robot design. Sometimes the question is not: “How do I eliminate every bit of movement?” It is: “Where should the system be precise, and where should it be allowed to adapt?” Good robotic design is not always about maximizing stiffness everywhere. It is about being rigid where precision matters and compliant where the real world demands it. #Robotics #Mechatronics #MechanicalEngineering #PhysicalAI #WhatTheRobotTaughtMe

A car with no steering wheel or pedals raises one question: what happens when confidence drops? Cybercab makes autonomy visible, but remote guidance, fault handling, and fallback behavior may be the harder problems at fleet scale. Curious how Tesla is solving this, @elonmusk.

Weekly Reflection #11 The more robotics I work on, the more I realize that engineering judgment is often about knowing what not to optimize. It is easy to chase: More accuracy. More sensors. More features. More complex models. But every improvement comes with a cost. More computation. More latency. More failure modes. More things to maintain. Sometimes the better system is not the one with the highest possible performance. It is the one that is simple enough to understand, reliable enough to trust, and capable enough to solve the actual problem. That is something I am trying to get better at: Not asking, “How much more can I add?” But, “What does this system actually need?” #Robotics #Engineering #SystemsEngineering #PhysicalAI #WeeklyReflection

Industry Insight #11 I think one of the biggest shifts in robotics is this: The question is moving from “Can the robot do the task?” to “Can the robot still do the task when something changes?” A different object. A slightly different position. A new lighting condition. A person entering the workspace. A tool that is not exactly where it was yesterday. That is where real-world robotics gets difficult. A system that works only under one exact set of conditions can still look impressive. But a system that can recognize change, adapt, recover, and continue safely is far more valuable. That is why I think perception, adaptation, recovery, and system-level reasoning are becoming just as important as raw task performance. The next leap in robotics will not just come from robots doing more. It will come from robots handling more of the unexpected. #Robotics #PhysicalAI #Autonomy #Engineering #IndustryInsight

A robot can execute the exact trajectory you commanded and still miss the object. Sometimes the problem is not planning. It is calibration. While working with robotic manipulation, I started noticing how small errors could propagate through the entire task: A camera frame is slightly off. The robot base pose is not exactly where the software assumes. The gripper TCP has a small offset. The object position is a few millimeters wrong. Individually, none of these errors look serious. Together, they can turn a correct plan into a failed grasp. That changed how I think about calibration. It is not just something you do once before running the robot. It is part of the robot’s performance. In robotics, a few millimeters in the model can become the difference between a successful grasp and a failed one. #Robotics #ROS2 #RobotManipulation #Calibration #SystemsEngineering

What the Robot Taught Me #7 Getting every component to work does not mean you have a working robot. I learned this while bringing sensing, software, and hardware together on robotics projects. The camera works. The sensors publish data. The planner generates a trajectory. The controller responds. Test each one separately and everything looks fine. Then you connect them. Suddenly, timestamps do not align. One process expects data faster than another can provide it. A sensor drops a message. The robot reacts to information that is already outdated. Nothing is necessarily “broken.” The system just does not agree with itself yet. That changed how I think about integration. I stopped asking only: Does each component work? And started asking: Do they work together at the right time? Can I trace information from sensing to action? What happens when one part slows down or fails? Building robots has taught me that integration is not what happens after everything works. Integration is where you find out whether the robot actually works. #Robotics #ROS2 #SystemsEngineering #EmbeddedSystems #WhatTheRobotTaughtMe

Weekly Reflection #10 One thing I’ve been thinking about lately is how easy it is to confuse activity with progress. You can spend hours changing code. Run dozens of tests. Tune parameters. Collect more data. And still not move any closer to understanding the real problem. What has helped me more is slowing down enough to ask: What am I actually trying to prove? What changed between the last good run and this one? What result would tell me I’m looking in the wrong place? That shift has made me more intentional with how I test and debug. Not every extra experiment creates progress. Sometimes the best next step is simply the one that gives you the clearest answer. I’m learning that good engineering is not about doing more work. It is about getting better information from the work you do. #Robotics #Engineering #ProblemSolving #Testing #WeeklyReflection

Industry Insight #10 One thing I’m realizing is that robotics progress is not just about making robots more capable. It is also about making the engineering behind them easier to understand, reproduce, and trust. A robot can complete an impressive task. But for that capability to matter beyond a demo, engineers still need to answer: Why did it work? What conditions did it depend on? What happens when something changes? Can the behavior be repeated? Can another engineer understand and reproduce the result? That is why I think technical documentation, testing, observability, and open engineering discussions matter so much as robotics moves into the real world. Seeing @KinovaRobotics engage with and repost engineering work from the community this week made that feel especially real to me. The robot doing the task is only part of the story. Understanding why it worked is what helps the field move forward. #Robotics #PhysicalAI #Engineering #RobotManipulation #IndustryInsight