Muhammad Ahmed

Robotics Engineer | ROS 2, Embedded Systems & Physical AI | Sharing real projects, failures, and lessons from building robots

[Muhammad Ahmed @ShaikhRobotics]

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

[Muhammad Ahmed @ShaikhRobotics]

@hackaday The original DOS software still working while the interface becomes unobtainable says a lot about hardware longevity. Recreating that bridge preserves a whole diagnostic workflow without replacing the ECU.

[Muhammad Ahmed @ShaikhRobotics]

@Hacksterio @autodesku @JeremySCook Running the LEDs separately from the Teensy-controlled motion and audio gives the display a useful fallback if one part fails. That is the kind of practical detail worth documenting alongside the finished build.

[Muhammad Ahmed @ShaikhRobotics]

@PetoiCamp @arduino @Hacksterio @IEEESpectrum Programmable senses make this a good place to teach behavior priorities. A gesture, a sound and a tracked object can all ask for attention at once. Deciding what the robot should ignore is part of the learning too.

[Muhammad Ahmed @ShaikhRobotics]

@NVIDIARobotics A useful next step would be repeatable failure replay: same policy, same scene, one changed condition. That could make these reconstructed spaces valuable for debugging robot behavior as well as training it.

[Muhammad Ahmed @ShaikhRobotics]

@Ken_Goldberg Including ordinary production samples alongside the known failures is a thoughtful choice. Fixing awkward mailers matters, but catching regressions on the packages that already work is what makes an update deployable.

[Muhammad Ahmed @ShaikhRobotics]

@lukas_m_ziegler A connection that holds without power is a practical win here. Once the boats assemble, the battery can go toward propulsion and sensing instead of continuously maintaining the structure.

[Muhammad Ahmed @ShaikhRobotics]

@jianglong_ye A dropped pen is cheap feedback; a misplaced hammer strike isn't. Moving this dexterity from simulation onto hardware will make force limits and safe exploration just as important as the task objective.

[Muhammad Ahmed @ShaikhRobotics]

@Arthur_K_J That first wiggle is doing useful measurement work before the robot commits to the task. For a rope that could tangle on a bad attempt, spending one action to learn the dynamics makes a lot of sense.

[Muhammad Ahmed @ShaikhRobotics]

@bardienus One to three tracks can leave several motions plausible, especially with hidden joints or stiffness. Preserving that uncertainty seems important if a robot is going to choose its next action from the prediction.

[Muhammad Ahmed @ShaikhRobotics]

@adcock_brett Taking the same policy into 30 unfamiliar homes is a serious test. Doorways, floor surfaces and furniture clearances can all change together. The recovery attempts would be just as valuable to see as the successful tasks.

[Muhammad Ahmed @ShaikhRobotics]

@Hacksterio Eight channels is the part that caught my eye. Capturing related signals in the same acquisition beats stitching a timing story together from separate captures, especially when the fault is intermittent.

[Muhammad Ahmed @ShaikhRobotics]

@MarioChan2002 The physical-commonsense gap is the takeaway for me. Describing a scene correctly and predicting what happens when you push or load an object are different skills. It's useful to see that limitation alongside the successful tasks.

[Muhammad Ahmed @ShaikhRobotics]

@lukas_m_ziegler Keeping the existing fingers and position controller makes this especially neat. Those uneven finger lengths are the real challenge: the hand has to support itself and still leave useful fingers free to do the task.

[Muhammad Ahmed @ShaikhRobotics]

@pham_blnh Action chunks feel like a tradeoff between committing to a coherent motion and staying responsive. I'd be interested in shorter chunks around contact and longer ones during free-space motion, where interruptions may matter less.

[Muhammad Ahmed @ShaikhRobotics]

@Lingjun_Mao The improvement across attempts is the interesting part here. I'd love to see what carries over when the cake or air fryer position changes, versus what was learned specifically for this setup.

[Muhammad Ahmed @ShaikhRobotics]

@chris_j_paxton Failed replications deserve a place next to the successful demos. Sharing the prompts, camera setup and failed attempts would make it much easier to tell which parts of a result another builder can actually reproduce.

[Muhammad Ahmed @ShaikhRobotics]

@YuXiang_IRVL This distinction gets lost in a lot of demos. Asking a model for joint actions and asking it to call a motion planner are very different tests. Showing that boundary makes the results much easier to interpret.

[Muhammad Ahmed @ShaikhRobotics]

@Adamjhung Predicting geometry and motion before spending capacity on appearance feels like a sensible bet for control. The small, scratch-trained model result makes the representation choice especially interesting.

[Muhammad Ahmed @ShaikhRobotics]

@NVIDIARobotics The on/off comparison on the same Jetson is the useful bit here. For a robot, I'd pair tokens/s with time to first useful action and sustained power draw. A faster model only helps if the rest of the control loop can keep up.

[Muhammad Ahmed @ShaikhRobotics]

@ax_pey @innate_bot Being able to start in a simulator and then bring your own robot makes this much easier to try. I'd especially value a clear path from a taught skill to testing how it behaves when the real setup changes.