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.

ay-robots devices

# SERIAL PORTS
#   /dev/ttyACM0   SO-100  (4 servos responding)
#     id 1  ok
#     id 2  ok
#     id 3  ok
#     id 4  ok
#     id 5  no reply
#     id 6  no reply
# CAMERAS
#   0  USB 2.0 Camera   1920x1080

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
   Scan and write the numbers down

   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. 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.

   bash

   ay-robots devices

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. The fix is to assign IDs one servo at a time, with only that servo on the bus, using the configuration tool from the servo vendor. There is no command in this platform’s CLI that writes servo IDs, so do not go looking for one. 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.

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