Robotics
Robotics: From Machines to Autonomous Systems
A self-paced general robotics course that builds from physical mechanisms and electrical power through embedded control, sensing, feedback, mobile motion, localization, manipulation, autonomous behavior, perception, distributed robot systems, human control, reliability, and a final autonomous-systems architecture defense. FRC is treated as a separate applied competition ecosystem; ROS 2 is treated as a later distributed-robotics specialization.
Unit 015 entries
- overviewUnit 1: Robots as SystemsA robot can look like one object while actually being several systems negotiating with one another. Before worrying about code or parts, learn to trace sensing, decision, actuation, power, and human authority as…→
- Lesson 1When Does a Machine Become a Robot?A blender has a motor. A garage door opener has a controller. A thermostat has a sensor. None of those facts, by themselves, make a system a robot.→
- Lesson 2The Sense-Decide-Act LoopA robot that moves once is easy. A robot that keeps behaving correctly while the world changes is harder.→
- Lesson 3Safe Work Is Part of the ArchitectureSafety is often taught as a list taped to a wall. In robotics, that is not enough.→
- reflectionUnit 1 Evidence CheckPut your system map beside your response.→
Unit 025 entries
- overviewUnit 2: Motion and MechanismsA motor shaft spinning is not yet useful robot motion. Mechanisms convert that rotation into translation, lifting, gripping, steering, or another constrained motion.→
- Lesson 1Motion Starts with ConstraintsRobots move because parts are allowed to move in some directions and prevented from moving in others.→
- Lesson 2Gears, Belts, Chains, and WheelsA motor shaft is useful only if its motion reaches the part that needs to move.→
- Lesson 3Choose the Mechanism from the TaskA common beginner mistake is starting with a part:→
- reflectionUnit 2 Evidence CheckUse the mechanism sketch as the evidence.→
Unit 035 entries
- overviewUnit 3: Force, Torque, Speed, and GearingA motor can spin beautifully on the bench and still fail the moment the robot asks it to move a real load.→
- Lesson 1Torque Is Not SpeedA motor can spin extremely fast and still be a terrible choice for moving a heavy robot mechanism.→
- Lesson 2Gear Ratios Are Design DecisionsA gear ratio is not just something you calculate after picking gears. It determines how the motor and mechanism share speed and torque.→
- Lesson 3Predict Before You BuildHardware tests are valuable. Blind hardware tests are expensive.→
- reflectionUnit 3 Evidence CheckReturn to your gearing calculation.→
Unit 045 entries
- overviewUnit 4: Structure, Materials, and StabilityRobots fail in boring ways. A bracket flexes. A bearing is misaligned. A fastener loosens. The center of mass moves farther than expected. Suddenly the "software problem" is a structure problem.→
- Lesson 1Why Robot Frames FlexA robot frame is not merely a place to attach components. It carries loads and preserves alignment between mechanisms that assume their geometry stays put.→
- Lesson 2Fasteners, Bearings, and AlignmentA shaft can be perfectly machined and still bind if its bearings are mounted out of line.→
- Lesson 3Mass, Center of Mass, and StabilityWhere mass is located can matter as much as how much mass the robot has.→
- reflectionUnit 4 Evidence CheckTrace one load path on your structural review from applied force to support.→
Unit 055 entries
- overviewUnit 5: Electrical Power and ActuationA robot often has an energy path and an information path crossing the same components.→
- Lesson 1Follow the PowerWhen a robot stops moving, people often look at the code first.→
- Lesson 2DC Motors and Motor DriversA controller pin cannot usually power a robot motor directly. Motors demand more current and create electrical behavior that logic electronics are not designed to handle.→
- Lesson 3Electrical Failure Without GuessingElectrical systems punish random troubleshooting because one loose connection can create several unrelated-looking symptoms.→
- reflectionUnit 5 Evidence CheckChoose one electrical symptom from your fault-isolation table.→
Unit 065 entries
- overviewUnit 6: Controllers and Embedded LogicThe controller is where physical signals become program values and program decisions become electrical commands.→
- Lesson 1The Controller in the MiddleA robot controller sits between physical evidence and physical action.→
- Lesson 2Digital, Analog, and PWM Are Different IdeasRobotics wiring diagrams often mix several signal types on the same page. If you treat them all as "data wires," debugging becomes harder than it needs to be.→
- Lesson 3State Machines Beat Spaghetti LogicRobot code becomes difficult when behavior is described only as a growing collection of conditions.→
- reflectionUnit 6 Evidence CheckUse your I/O map and state-machine trace.→
Unit 075 entries
- overviewUnit 7: Programming Robot BehaviorA line such as motor = 0.5 looks simple. It hides units, limits, ownership, timing, and an assumption about what the actuator will do.→
- Lesson 1From Command to Motion"Drive forward" sounds like one instruction. A robot sees a chain of smaller decisions.→
- Lesson 2Timing, Loops, and Nonblocking CodeA robot cannot freeze the rest of its brain every time one mechanism waits.→
- Lesson 3Program a Behavior You Can ExplainA robotics program is not finished when the robot moves. It is finished enough to test when you can explain why each important output changed.→
- reflectionUnit 7 Evidence CheckRun your behavior specification against three cases: one normal value, one boundary value, and one invalid or stale input.→
Unit 085 entries
- overviewUnit 8: Sensors and MeasurementA sensor produces evidence. It does not produce truth.→
- Lesson 1A Sensor Does Not Know the TruthA sensor measures a physical quantity through some mechanism. It does not produce reality itself.→
- Lesson 2Calibration, Noise, and SamplingA sensor value can be repeatable and still be wrong.→
- Lesson 3Build a Measurement ChainRobots rarely use a raw sensor number directly. The number moves through conversions and decisions.→
- reflectionUnit 8 Evidence CheckLook at the ugliest part of your sensor evidence, not the cleanest.→
Unit 095 entries
- overviewUnit 9: Feedback and PID ControlOpen-loop commands assume the same command will produce sufficiently similar behavior each time. Load, battery state, friction, and disturbances make that assumption fragile.→
- Lesson 1Why Open Loop MissesTell two identical motors to run at the same command and the robot may still curve.→
- Lesson 2P, I, and D Without the MagicPID control is often introduced as three mysterious constants people tune until the robot stops shaking.→
- Lesson 3Tune with EvidenceChanging three gains randomly is not tuning. It is gambling with decimal numbers.→
- reflectionUnit 9 Evidence CheckChoose two control trials from your tuning record.→
Unit 105 entries
- overviewUnit 10: Mobile Robot MotionTwo wheels can produce straight motion, arcs, and rotation. The geometry is simple enough to model and rich enough to fail in interesting ways.→
- Lesson 1How Two Wheels Make a Robot TurnA differential-drive robot can move forward, backward, and turn using only two independently driven sides.→
- Lesson 2Wheel Speed to Robot MotionNow connect wheel measurements to chassis motion.→
- Lesson 3Drive a Path on Paper or in SimulationA path is a sequence of poses, not just a list of motor commands.→
- reflectionUnit 10 Evidence CheckCompare predicted and observed or simulated path checkpoints.→
Unit 115 entries
- overviewUnit 11: Localization, Odometry, and FramesA robot rarely receives its exact pose from one perfect sensor. It estimates pose from evidence that has timing, uncertainty, and coordinate frames.→
- Lesson 1Position Is an EstimateA robot usually does not possess a magical variable called true_position.→
- Lesson 2Odometry and DriftOdometry estimates robot motion by accumulating local movement.→
- Lesson 3Coordinate Frames and Sensor FusionWhen several sensors estimate the same system, they rarely agree perfectly.→
- reflectionUnit 11 Evidence CheckDraw or reuse your frame diagram.→
Unit 125 entries
- overviewUnit 12: Manipulators and End EffectorsA mobile base moves the robot through the world. A manipulator changes how the robot physically interacts with the world.→
- Lesson 1A Gripper Is a Force ProblemA gripper is not successful because it closes around an object. It is successful when it can acquire, retain, and release the object under the expected conditions.→
- Lesson 2Arms, Levers, and Degrees of FreedomAn arm creates reach by moving links around joints. Every added joint creates more capability and more control complexity.→
- Lesson 3Select an End Effector from EvidenceRobotics videos make complicated grippers look automatically better.→
- reflectionUnit 12 Evidence CheckYour end-effector matrix made a choice. Now attack it.→
Unit 135 entries
- overviewUnit 13: Autonomous Behavior and PlanningAutonomy is a structured chain of estimation, decision, control, monitoring, and recovery.→
- Lesson 1Autonomy Is Structured Decision-MakingAutonomy does not begin when a robot uses artificial intelligence.→
- Lesson 2Reactive Behavior vs Planned BehaviorA robot can respond directly to what it senses, or it can reason about a sequence of future actions.→
- Lesson 3Design an Autonomous MissionA good autonomous mission has more than a success path.→
- reflectionUnit 13 Evidence CheckTake one transition in your autonomous mission graph and write the evidence that permits it.→
Unit 145 entries
- overviewUnit 14: Computer Vision and PerceptionA camera gives the robot measurements arranged as pixels. Everything after that is interpretation.→
- Lesson 1Pixels Are MeasurementsA camera does not see "a box."→
- Lesson 2Detection Is Not UnderstandingA perception model can output a label and confidence score without understanding the object the way a person does.→
- Lesson 3Test Perception at Its BoundariesA perception demo in perfect lighting tells you almost nothing about robustness.→
- reflectionUnit 14 Evidence CheckSelect the perception trial that most clearly exposes an operating boundary.→
Unit 155 entries
- overviewUnit 15: Robot Communication and Distributed SystemsAs vision, navigation, control, logging, and operator tools separate onto different processors, the interfaces become part of the robot.→
- Lesson 1Robots Are Distributed ComputersA modern robot may contain several processors.→
- Lesson 2Messages, Buses, Latency, and FailureCommunication is part of robot behavior.→
- Lesson 3From One Controller to ROS 2ROS 2 is not the definition of robotics. It is one framework for organizing distributed robot software.→
- reflectionUnit 15 Evidence CheckChoose the highest-consequence interface in your communication architecture.→
Unit 165 entries
- overviewUnit 16: Human Control, Safety, and EthicsA robot is never only hardware and software. Someone defines what it may do, who can interrupt it, what information it may retain, and what happens when automation is uncertain.→
- Lesson 1Who Is Allowed to Make the Decision?Robotics is not only about whether a machine can make a decision.→
- Lesson 2Stops, Overrides, and InterfacesA stop system is not a decorative red button.→
- Lesson 3Ethics Shows Up in RequirementsEthics in robotics is not a final slide about "using technology responsibly."→
- reflectionUnit 16 Evidence CheckUse your authority map to answer one uncomfortable scenario: automation and the human operator disagree.→
Unit 175 entries
- overviewUnit 17: Integration, Reliability, and DebuggingRobotics integration is where mechanical, electrical, sensing, software, communication, and human-interface assumptions collide.→
- Lesson 1Debug the Layer, Not the SymptomA robot drifts left.→
- Lesson 2Reliability, Fault Trees, and FMEAA system can work once and still be unreliable.→
- Lesson 3Recovery Is a FeatureRobots fail in the middle of missions.→
- reflectionUnit 17 Evidence CheckStart with one failure symptom from your dossier.→
Unit 185 entries
- overviewUnit 18: Autonomous Systems Design ReviewThe final Unit is not a last-minute build sprint. It is where you prove that the system you designed can be explained, tested, limited, and recovered.→
- Lesson 1Turn a Mission into RequirementsThe capstone begins with a mission, not a robot shape.→
- Lesson 2Build the ArchitectureNow design the system that satisfies the requirements.→
- Lesson 3Prove the Robot Before You Trust ItA design review is not a sales pitch.→
- reflectionUnit 18 Evidence CheckThis is the final defense, not a summary paragraph.→
