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

Weekly Reflection #15 I’m trying to stop describing my projects like a shopping list. A robot arm. A camera. ROS 2. A Jetson. That tells someone what I used. It doesn’t tell them what I actually worked on. The part I want to explain better is the decision behind the setup. Why that sensor? Why that approach? What did I decide not to add? It’s something I’m thinking about as I share more of my robotics work. A demo can show the result. I want the caption to add something you couldn’t learn just by watching it. Maybe that’s one design choice, a tradeoff, or a question I still haven’t answered. Not every project needs a long explanation. But I’d rather explain one decision properly than squeeze every technology I’ve touched into a post. When you look at someone’s engineering project, what do you wish they’d explain beyond “here’s what I built”? #Robotics #Engineering #TechnicalCommunication

Industry Insight #15 Before asking how fast a robot moves, I’d ask what it spends its time waiting for. Imagine a robot loading parts into a machine. It might be waiting for the next part, the machine to finish, or space at the next station. If the bottleneck is elsewhere, making the arm faster won’t necessarily get more finished parts out of the line. That’s the part of automation I’d like to see discussed alongside robot specs. Where is the process actually getting held up? Is the robot waiting for work, or waiting for somewhere to put it? Would a shorter cycle help, or just fill the next queue faster? @Siemens’ Plant Simulation interests me for this reason. It models production systems and material flow, so you can examine how the robot fits into the process rather than judging its motion alone. I’d want to compare finished parts leaving the line per hour before and after automation, not just seconds per robot movement. A robot staying busy isn’t the same as a factory getting more done. For anyone working in manufacturing, what’s the biggest source of waiting in a robot cell you’ve worked on? #Robotics #Automation #Manufacturing #Engineering

What the Robot Taught Me #11 I used to think cable management was something you figured out after the robot worked. Turns out, it can be part of whether the robot works at all. A cable can pull on a sensor. Restrict a joint near the end of its range. Get caught during motion. Put stress on a connector every time the robot moves. Or slowly fail after enough repeated cycles. None of these problems sound particularly exciting. But they can make a perfectly good mechanical or software design behave strangely. That changed how I look at robot hardware. Now, when routing a cable, I try to think about the motion too: Where will it bend? What happens at the robot’s extreme positions? Is there enough slack without creating a snag point? Is there proper strain relief? What will this look like after thousands of cycles? It’s one of those details you barely notice when it’s designed well. And definitely notice when it isn’t. #Robotics #Mechatronics #MechanicalDesign #Engineering #WhatTheRobotTaughtMe

Weekly Reflection #14 One thing I like about robotics is that the robot doesn’t care how good your idea sounded in your head. You can spend hours thinking through a design. The CAD looks right, the simulation works, and the code makes sense. Then you build it. Something flexes. A cable gets in the way. The sensor sees something you didn’t expect. The robot moves differently than it did on your screen. Suddenly, you’re dealing with a detail that barely crossed your mind during planning. I used to find that frustrating. Now it’s one of the reasons I enjoy working with physical systems. You can’t explain away a cable catching on a joint. You have to understand what’s happening and change something. There’s something satisfying about that direct feedback. The idea in your head is a starting point. Building it is how you find out what you missed. #Robotics #Engineering #LearningByDoing #WeeklyReflection

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