Teaching my robot which legs it has

This week's assignment was to design a microcontroller board in an EDA tool and run the design rule checks. I used it to work on the body board for my final project. It needs to identify the connected legs, communicate with up to eighteen servos on a shared bus, read an IMU and pass information to a laptop.

I also decided to write my own small EDA tool in Python. It was fun, although the design rule check eventually told me that the board isn't ready to mill yet.

Before getting into the design, an important distinction: I haven't made or tested this board yet. The current layout fails the milling clearance check. The voltage margins and timing results below come from calculations and simulations, not measurements on hardware.

Once the board is built, I'll start by checking the divider voltages with a bench supply and multimeter. The more useful test will be with all eight ports connected, six legs drawing current, and the servo bus running at 1 Mbps. I want to compare the port readings with the robot idle and under load. In particular, I need to see whether the bus introduces noise into the ID lines and how much of the calculated 252 mV margin is left.

The idea is to turn a simple electrical measurement into a description the controller can use.

The board won't measure the robot's shape directly. It will identify which encoded leg type is plugged into each port. For my experiment, that should be enough, as long as the resistors match the physical modules.

Each port is read separately through the mux, so the result is a list of eight values rather than a single measurement. Two robots with different encoded leg arrangements should therefore produce different lists.

There are still a few limitations:

• Legs with the same resistor look identical. If I make a longer shin but forget to change its resistor, the board will report the wrong model. I need to keep the resistor assignments and part dimensions in sync.
• It identifies types, not individual modules. Swapping two identical default legs won't change the reading, which is fine for interchangeable parts.
• It doesn't tell me whether a leg works. A resistor will still read correctly if a servo is dead. I'll separately ping the servo IDs to check which actuators respond.
• It doesn't detect damage or changes in geometry. A bent link, worn joint or incorrect orientation won't show up in the voltage. The connector is keyed, so orientation is handled mechanically; the other problems need different checks.

In short, it's a way for the robot to report its modular configuration, not a general-purpose shape sensor.

I calculated the divider voltages with resistor tolerances and the mux's on-resistance included. There are three numbers worth separating (the calculations are in margins.py):

The useful number is the margin to the decision threshold, not the full gap between bands. I put each threshold halfway between the nearest edges of the two worst-case bands:

T_i = ( V_i,max  +  V_i+1,min ) / 2

M_i = min( T_i - V_i,max ,  V_i+1,min - T_i )

guaranteed margin = min over all boundaries of M_i

That gives the following thresholds and margins:

The distances are equal on both sides because I chose the thresholds at the midpoints. I checked this explicitly rather than assuming that half the nominal gap would be the margin. Using round thresholds of 1.4, 2.0 and 2.8 V would lower the minimum margin to 234 mV, about 7% less, so I'll use the calculated values in the firmware.

My first calculation gave 564 mV, but I had treated the gap as the decision margin and left out the mux's on-resistance. With both corrected, the minimum margin is 252 mV. The ADC's nominal step size is 0.806 mV.

I also looked at the RP2040's ADC performance. A third-party characterisation reports around 1 LSB RMS noise, but considerably larger differential and integral nonlinearity (8.9 and 7.85 LSB). Averaging can reduce the random noise; it won't remove systematic conversion errors. The reported effective resolution is about 8.9 bits.

Even allowing roughly 10–12 counts for ADC error, the calculated 313-count margin looks promising. But those ADC figures came from someone else's board. I'll need to measure the four voltage bands on mine, both with the supply quiet and while the servos are drawing current, before trusting the classifier.

A half-seated connector could give an intermediate voltage that happens to look like another leg type. I don't want the robot to interpret that as a real change in configuration.

My proposed firmware will accept a new configuration only after five consecutive, fully valid scans of all eight ports agree. If any reading is too close to a threshold, it resets the count.

I originally considered using both guard bands and hysteresis, but I don't need both for something that is only read at startup or when I explicitly request a rescan. Here's the simpler version:

There are two other practical issues. The connector pins are all the same length, so I can't guarantee which contact mates first; readings during insertion or while the power rail is settling won't be reliable. Hot-plugging also causes inrush current into a leg's capacitors. For this first version, I'll power the robot down before swapping legs. Supporting hot-plugging or self-reconfiguration later would need additional hardware, not just a firmware change.

For now, this is a firmware plan. I haven't implemented it yet.

Reading a resistor tells me the declared leg type at a port. Pinging the servos tells me which servo IDs respond. Both are useful, but because all the ports share one bus, a ping can't tell me which port an individual servo is plugged into.

One basic check is to compare counts. If the board reports three legs, I expect nine servo IDs to respond. Eight or twelve would indicate a problem, and I'd stop the experiment rather than start with a configuration I don't trust. It still wouldn't prove that each responding module is connected to the port I think it is.

To associate individual servo IDs with individual ports, I'd need to switch or gate the bus separately at each port. That would add an analog switch or buffer enable per port and more control lines (or another mux). I'm leaving that for a possible v0.2.

There's also a difference between a servo answering and a joint actually working. The STS3215 reports its position, so a future startup test could command a small motion and see whether the reported angle changes as expected. That might catch certain actuator or transmission faults, but it still wouldn't measure the actual link length.

For the transfer experiments, I'll need to be careful about this. The MJCF generator trusts the resistor table, so whenever I change a physical link length, I also need to update its assigned resistor and model parameters. Otherwise the model and the hardware quietly stop matching.

I could have used a separate pull-up resistor for every port. Instead, I put one on the mux's common output. Only the selected leg is connected to it, so this saves components and, more importantly, avoids routing a 3.3 V line to all eight ports on a single-layer board.

The trade-off is that the mux's on-resistance, roughly 250 Ω, is now in series with the leg resistor. I included that in the voltage calculations:

The smallest nominal difference is 595 mV. With the resistor tolerances and mux resistance included, the worst-case gap is 505 mV and the minimum threshold margin is 252 mV. That looks comfortably above the 10%-of-full-scale separation I originally aimed for between nominal bands. The full calculation is in the margin section.

The Feetech servos use 5 V logic, but the RP2040 uses 3.3 V GPIO and isn't 5 V tolerant. I need to translate the signal in both directions.

Transmit: I chose a 74HCT125 buffer powered from 5 V. The HCT part matters because its input-high threshold is compatible with a 3.3 V signal. A standard HC buffer running at 5 V expects around 3.5 V for a guaranteed high, which would be too close for comfort. One GPIO enables or tri-states the driver so the bus can switch between transmitting and receiving.

Receive: A 3.3 kΩ / 6.8 kΩ resistor divider brings the bus signal back down to a safe voltage. The bus also has a 2.2 kΩ pull-up, so I included the loading from the divider in the calculations and simulated the result below.

With six legs walking, I'm planning for roughly 11 A. That's far too much to put through an ordinary narrow milled trace. I used IPC-2221 to estimate the trace widths needed for 1 oz copper and a 20 °C temperature rise:

The rail is 2.2 mm wide in the layout, about the most I can fit past connectors on a 2.54 mm pitch. By that estimate it can carry around 5 A, not 11 A, so I'll solder 18 AWG wire along the rail to carry the extra current. I'll still need to verify the finished power path under load.

The SS34 Schottky protects only the logic branch against reverse polarity. It isn't rated to handle the full servo current, and a suitable series diode would also dissipate significant heat. For v0.1 I'm using a keyed screw terminal for the 12 V input instead.

The board will be milled on one side of FR1, which means no vias and no second copper layer. If two traces need to cross, I have to use a zero-ohm jumper or a wire link. I wanted to avoid having dozens of those.

The biggest improvement came from rearranging the leg connector pins. Each one goes 12 V, GND, BUS, ID from the board edge inward, and all eight connectors are on the same edge. This lets the shared power and bus lines run together while the individual ID lines head toward the mux. Ground is handled by a copper pour.

For the ID lines, I mapped nearby ports to the higher-numbered mux channels. That let me route all eight lines without crossing one another or the traces coming down from the connectors.

I used ngspice for two questions I didn't want to answer from rough estimates alone.

How long should the ADC wait after changing mux channels? I modelled roughly 250 Ω of mux on-resistance and 22 pF of capacitance at the ADC. The simulation switches from an empty port at 3.3 V to a long-shin port at 1.055 V and measures how quickly the voltage settles to within one ADC LSB.

Does the receive divider still work at 1 Mbps? The 2.2 kΩ pull-up and 10.1 kΩ receive divider load each other. The calculated bus idle level is about 4.2 V, which becomes 2.76 V at the RP2040 input. That's above the 2.0 V high threshold used in my check, with around 760 mV of margin, and below 3.63 V. A low bus level gives about 38 mV at the input.

I made the layout in Python instead of drawing it in a GUI. I've been using parametric scripts for the other assignments, and I wanted to see whether I could do the same for a PCB, including a design rule check that looks at the actual image sent to the mill.

The code is split into two files. fab.py handles footprints, copper shapes, the ground pour, routing, DRC and exporting. bodyboard.py defines the parts and their placement, with the dimensions kept as parameters.

b = Board(110, 86, Rules(mill_d=0.4, min_trace=0.4, min_clear=0.4, edge_clear=0.8))
b.set_pour("GND")

HDR4 = header(["P1", "P2", "P3", "P4"])
for i, x in enumerate(PORT_X):
    place(f"J{i+1}", "leg port", HDR4, x, 76.7,
          dict(P1="+12V", P2="GND", P3="BUS", P4=f"ID{i}"))

For a milled board, I need to know whether the cutter can fit between separate nets and whether the remaining copper features are wide enough to survive. I wrote the check to run on the 1000 dpi raster, which is also what the mill will use.

The tool renders nets separately, calculates the distance from each one to the others, and reports the smallest clearances with their locations. It also checks copper widths and the edge keepout. Here's the current result:

DRC  bodyboard v0.1  110.0x86.0 mm, 30 nets, 283 copper shapes, 51 drills
  smallest gap between different nets : 0.025 mm (need 0.4)  FAIL
  copper inside 0.8 mm edge keepout  : 0 px  PASS
   ! TX / TXEN_N   0.025 mm at (86.9, 19.3)
   ! SCL / SDA     0.102 mm at (47.9, 13.1)
   ! RXD / TXEN_N  0.127 mm at (91.6, 24.6)
   ! BUS / TX      0.330 mm at (88.5, 18.7)
   ! +3V3M / ID4   0.381 mm at (59.4, 51.6)
   ! +3V3 / IDSENSEX 0.381 mm at (63.9, 28.7)
  -> FAIL

The board doesn't pass yet, so I haven't milled it. Six pairs of nets are closer together than the 0.4 mm clearance I set. The worst is TX against the buffer enable, with just 0.025 mm between them. Most of the problems are clustered around the XIAO's UART pins, the bus buffer and the receive divider.

Next I want to open up that corner by about 10 mm, move the divider farther from the buffer, and reroute TX so it doesn't share a narrow lane with the enable signal. Then I'll run the DRC again before trying to mill anything.

Manually routing thirty nets on one layer got tedious, so I wrote an A* maze router on a 0.25 mm grid. It first tries to find paths that respect the milling clearances. If a net can't be routed without crossing another one, it tries again with a penalty for crossings and adds a wire link where needed.

Two bugs took a while to sort out. Fine-pitch pins need short escape traces before the main router takes over, otherwise the path can run too close to a neighbouring pin. I also had a one-pixel offset between the raster and routing grid. At 1000 dpi that's 0.025 mm, which explains why so many early DRC failures had exactly that size.

The current layout has 17 links: two I placed deliberately and fifteen added by the router. The two deliberate ones get the mux's common output and supply past neighbouring channel traces. Seventeen is more than I'd like to solder, especially since many of the additional links are near the same crowded part of the board. Hopefully fixing the component placement will reduce that number as well as the DRC errors.

I'm keeping the 12 V-to-5 V buck converter and IMU as separate modules. A switching regulator needs a more careful layout than I want to attempt on a milled single-layer board, and the IMU package is also awkward to fabricate this way. I'll check the exact modules against the lab inventory before ordering.

The unused 74HCT125 inputs and enables are tied to ground so they don't float.

pip install numpy scipy pillow
sudo apt install ngspice

python3 checks.py            # resistor margins and trace-current calculations
ngspice -b id_sense.cir      # mux settling
ngspice -b bus_rx.cir        # receive divider at 1 Mbps
python3 bodyboard.py         # route, run DRC, export PNGs, netlist and BOM
python3 render.py            # annotated board render

bodyboard.py takes about four minutes on my machine, mainly because the DRC runs a distance transform for each net over a 4331 × 3386 image. It exports traces, outline and drill images at 1000 dpi for mods, as well as a KiCad-format netlist and a BOM. I'd like to import the netlist and check the layout in KiCad too, as a second check on my own tooling.

These are the milling constraints I'm currently using:

Rules(mill_d=0.4,      # 1/64" end mill
      min_trace=0.4,   # minimum copper width
      min_clear=0.4,   # room for the cutter between nets
      edge_clear=0.8,  # copper-to-board-edge clearance
      dpi=1000)

I should have spent more time arranging the components before routing anything. I put them down roughly and tried to make the traces fit afterwards, which is how I ended up squeezing the UART, buffer and divider into the same corner.

I also hadn't appreciated how much connector pin order matters on a single-layer board. Changing the pin assignments removed more crossings than trying to get clever with the routes. That's something I'll plan around from the beginning next time.

The RP2040 ADC figures are from Mark Omo's characterisation at pico-adc.markomo.me, not measurements on this board. The design margins were revised after I realised I had confused the voltage-band gap with the margin to the threshold.

Tools: Python (numpy, scipy and Pillow) for the EDA scripts, and ngspice for the circuit simulations. I used AI assistants while building and debugging the tooling. I also spent an unreasonable amount of time tracking down a one-pixel routing error. I haven't fabricated the board or made its enclosure yet.