Why does the scan find only some of my servos?

The bus is a chain, not a hub

Each servo on these arms has two identical connectors and passes the bus straight through from one to the other. The controller connects to the first servo, the first connects to the second, and so on to the gripper. There is no star wiring and no central board with six sockets. Every servo therefore depends on every connector between it and the controller, and a single bad link cuts off everything downstream of it while leaving everything upstream perfectly healthy.

That is why the count is diagnostic rather than merely alarming. A scan is a sequence of addressed queries; each servo that receives one answers with its ID. The set of IDs that answer maps directly onto the physical order of the arm, so the boundary between answering and silent is the location of the fault.

Two different checks are involved and it is worth keeping them apart. The CLI device list tells you whether the operating system has a serial port for the arm at all. It prints two columns per serial line, the device id and a name, and for an arm that name is always the literal word unknown, because the record behind the line carries no name at all. It does not report servos.

ay-robots devices

# SERIAL PORTS
#   robot_1   unknown
# CAMERAS
#   camera_1  USB 2.0 Camera

The list of responding IDs comes from the motor scan on the Hardware page for your robot in the dashboard. It queries the bus and reports the IDs that replied, so on a six joint arm an answer of 1, 2, 3 and 4 means the boundary sits between servo 4 and servo 5. Write that list down before you touch anything, because it is the one piece of evidence that locates the fault physically.

Reading the pattern

The fourth row is the one worth internalizing. Wiring failures are contiguous by construction: if the signal stops at a connector, everything past it is silent, without exception. A hole in the middle of an otherwise complete sequence is therefore never a cable between two working neighbors, and looking for one wastes an hour. A servo that has failed electrically usually still passes the bus through its second connector, which is exactly why its neighbors keep answering while it does not.

Diagnose it in this order

1. 1
   Confirm the port, then scan the bus

   The CLI device list confirms that a serial port exists. Then run the motor scan on the Hardware page and record which IDs answered, in order. If you only remember "some are missing" you will lose the one piece of information that locates the fault.

   bash

   ay-robots devices

2. 2
   Power cycle once, then rescan

   A servo that latched a fault, or a bus that was scanned while the supply was still coming up, can report short for reasons that clear on a clean start. This costs ten seconds. Do it once, not repeatedly, because repeating it is not diagnosis.

3. 3
   Reseat both ends of the suspect link with the power off

   Take the link identified by the highest responding ID. Unplug both connectors, look at the pins, push them home until they click, and rescan. Half-seated connectors are the single most common cause and they survive weeks of use before failing.

4. 4
   Swap that cable with one you have proven

   Take the cable from a link that is currently working, for example between servos 1 and 2, and put it in the suspect position. If the missing servos come back, you have found it. If the fault moves to where you took the good cable from, you have found it twice.

5. 5
   Shorten the chain to isolate the servo

   Connect the first missing servo directly to the controller with a known-good cable, alone, and run the motor scan again. If it answers on its own, the servo is fine and everything you are chasing is wiring. If it stays silent alone, you have a servo or an ID problem, not a cable.

6. 6
   Check for a duplicated ID

   If the isolated servo answers but the count is still short when it is back in the chain, two servos are probably sharing an address. Put each one alone on the bus in turn and note the ID it reports.

7. 7
   Check the baud rate on anything recently replaced

   A servo configured for a different rate is electrically fine and completely silent at the rate the rest of the bus uses. This is standard on a replacement unit out of the box and on any servo that has been through someone else’s configuration tool.

8. 8
   Only now suspect the servo or the controller

   A servo that stays silent alone, on a proven cable, at the right baud rate, with a unique ID, has earned the diagnosis. Replace it, then recalibrate the arm, because a new servo has a different zero point.

   bash

   ay-robots calibrate

Duplicate IDs, and the joint that moves in sympathy

Every command on the bus is addressed to an ID. If two servos carry the same one, both of them execute every command sent to that address, and both try to answer it. The scan counts one where two exist, and the arm develops an obvious tell: two joints move together whenever you drive either of them. Nothing raises an error, because from the protocol’s point of view nothing unusual happened.

This shows up after a servo is replaced with one that was never renumbered, and after a build where the numbering pass was interrupted. In both cases the servo that needs fixing is still on the factory ID 1, which is the case the platform handles for you: open the Hardware page for your robot in the dashboard, start the motor configuration, and step through the six positions with only the servo you are numbering connected to the board. It scans, reports the servo sitting on ID 1, and writes the ID for that position. There is no command in this platform’s CLI that writes servo IDs, so do not go looking for one. A servo that already carries some other ID, say 3 when you want 5, is the case this does not cover, and that is what the servo vendor’s configuration tool is for. Once the numbering is unique, rescan, then recalibrate, because the software’s idea of which joint is which has just changed.

A servo on the wrong baud rate

Servos and controller must agree on the bus speed. A unit set to a different rate hears a garbled version of every query and answers nothing, which is indistinguishable from a dead servo or a cut cable when all you have is a count. The reason to keep it on the list is that it is free to rule out and expensive to overlook: people replace a perfectly good servo because of it.

The scan only ever runs at the single rate the bus uses, so a servo on a different rate is invisible to it and to the motor configuration in the dashboard. This is the one case that needs the vendor tool, because you have to reach the servo at the rate it is currently listening on before you can move it to the one everything else uses.

What a missing servo does to a dataset

If you record before you have a full count, the joint that never answered contributes a column that never changes. That dataset looks entirely normal in a file listing and trains without complaint, and the resulting policy simply never uses that joint. It is a slow, expensive way to learn this lesson, and it is the reason the scan is worth reading carefully every time you set up rather than only when something is obviously broken. Recording practice is covered on /so-100/data-collection, and the training side of the same mistake shows up on /train/act-on-so-100.

Frequently asked questions