compact computer enclosure

a project i took on at neuralink was to add a dedicated computer to the assistive robotic arm system. previously, both the robot arm software and neural signal inference would run on the user's macbook. the motivation was to have a dedicated machine running the control stack, to provide a more predictable environment with stricter process control, avoiding latency spikes to ensure a safe, reliable, and consistent user experience.

i owned the project end-to-end over ~3 months: mechanical, electrical, and software.

the project began with requirement definition and packaging architecture. a system-level requirement was that the robot had to be easy to remove, so cabling and user interactions mattered as much as the box itself. i built a few physical mockups to test the user workflow when interacting with the robot arm and mount.

i landed on two discrete boxes: an e-stop box on the back of the wheelchair, and a compute box on the t-slot rails next to the robot mount. the advantage was that the cables which would be unplugged during robot removal live right next to the mount, making the removal process more intuitive while preserving e-stop accessibility. the enclosures had to be universally compatible with various wheelchair models with limited real estate and stay compact to be unobtrusive.

here's another fun concept; integrating the computer with the robot base. it was ultimately too bulky and sealing would have been difficult, so it was dropped in favour of a wheelchair-mounted box.

inside the box, a custom pcb distributes power to the robot and computer. the e-stop and head-actuated user stop sit in series with a relay. either stop kills both the computer and the robot.

from there, i parallel-pathed the mechanical and electrical design, prototyping and testing against the risks that would actually kill the project; thermals, connector alignment, brownout, and e-stop functionality.

the enclosure contains a mini pc (nuc), a custom power-distribution pcb, a mini ethernet switch, and internal wiring with traditional and flex cables into something that mounts on t-slot next to the robot. compactness was critical as our user's wheelchairs have accessories (laptop mounts, ventilator, etc) that make packaging challenging.

the body is machined pc-abs. it needed to be non-conductive for electrical safety (no exposed battery ground to the user for single-fault redundancy), impact-resistant for a cantilevered rail mount, rf-transparent for wireless communication (nice-to-have), and sensible at low volume.

my target water resistance was ip65. we instruct users to not use the robot arm in the rain, but you always have to anticipate the worst-case. panel-mount ethernet and waterproof power/signal connectors are on four faces of the box. lids and seams use soft epdm gaskets i laser cut myself; mounting screws got o-rings so the fastener hole isn't an ingress path.

one of the first risks i flagged was cpu thermals in a sealed, insulative plastic box. a quick worst-case steady-state thermal resistance calc put internal air well over 90°c at nominal cpu power — meaning the die would be past 100°c and severely throttle. two blockers to testing were a) no completed PCB, so i couldn't power the system in a representatively sealed enclosure, and b) computer bring-up was not ready to test real power draw under load. i proactively included a fan header on my board as insurance.

i also mocked up another concept which removed the off-the-shelf nuc fan and heatsink, and directly coupled the cpu to an aluminum enclosure. the exterior would be anodized to handle electrical isolation requirements, with the entire enclosure acting as the heatsink. the downside is that wireless communication becomes more challenging, but it was tolerable since that wasn't a firm requirement.

the computer's power draw was ultimately lower than expected. running a full-stack test showed peak temps during stress testing around 76°c, so i didn't need the fan after all. i still decided to add openings on two sides of the enclosure; each being a circular grid of small holes, with a recess to hold a hydrophobic film attached with VHB tape to maintain ip65. the nuc's built-in fan pulled air through the bottom opening with its natural exhaust pointed towards the side opening. follow-up logging of cpu temp and clock speed confirmed further reduced cpu temps to 65°c and maintained clock speed, even under worse-than-representative stress tests.

to cleanly package the custom board, i modeled a few different orientations of the computer and pcb. i realized that i could disassemble the computer from its off-the-shelf case and mount the pcb on top of the two-board stack. it gave me a clean all-in-one package that was super easy to assemble and made powering the nuc super convenient, with a single usb-c / usb-c flex cable. it kept all the computer connections on one side which helped routing and making the enclosure compact. i also added features for antenna placement and deterministic routing to keep wireless communication consistent.

the enclosure body is a box with three open faces (front, top, back); each gets its own lid and gasket. this layout was required to fit the connectors, but unfortunately it was overconstraint hell; the nuc being attached to the enclosure floor and panel-mount connectors on three sides of the board overconstrained the assembly and stressed solder joints causing creep in the high-temperature environment.

to address this issue, i prioritized connector alignment and allowed the pcb/nuc stack to float. i designed an assembly fixture with explicit datum features to set alignment between the three panel-interfacing connectors, controlling their position and orientation.

the sequence was to insert the three connectors into the board, insert the board face-down, clamp it with two toggle clamps, then solder the connectors. the fixture was printed in rigid 10k resin to handle the high soldering temps while providing high dimensional accuracy.

power comes off the wheelchair's 24v batteries. a custom pcb i designed handles distribution: 24v in, buck down to 12v for the nuc and ethernet switch, and 24v passed through for the robot. the board added a relay to the system; previously, the robot was wired in series with the two buttons, but the nuc pushed the system above their 10a ratings.

there are 6 external cables; 2 carrying data and 4 carrying power. i designed the four custom power cables with wireviz, a wire-harnessing tool, ensuring all cables were keyed with unique connectors to prevent backwards-plugging.

before diving into board design, i built a benchtop prototype with a breadboard and wago connectors. i went step by step; first using a bench supply to confirm the relay triggers, then testing the 12v rail, then connecting the nuc, then the robot, and finally testing the entire stack from the wheelchair batteries.

it mostly worked, except the robot would occasionally brown out on boot. i probed around and found that the robot power cable sat noticeably lower than the bench input. working backwards, i found that my inrush-limiting ntc thermistor, which i included as a pre-emptive measure against inrush current spikes, had substantial resistance at idle current. during robot boot, the ntc never heated enough, so its voltage drop undervolted the robot. my testing showed that the robot needed around 20V to boot reliably, and drew ~1A, so if the supply voltage was ~25V, the robot could boot up. any lower (like with the 24V batteries), and the robot wouldn't boot up. i realized that the esr of my bulk input capacitor kept inrush current below the connector's 25A rating, so i pulled the thermistor and the robot consistently booted up cleanly.

with the architecture proven on the bench, i moved to the first board spin, my first-ever pcb. most of it was translating what already worked: the 24-to-12v buck for the nuc and ethernet switch, the power relay, and the bulk input capacitor. around that i layered the protections and debug indicators i wanted on a real board; a flyback diode across the relay coil, a zener to clamp input transients, decoupling caps near the loads, and a ferrite bead on the switchblox nano supply header to keep switching noise off the rest of the net. i also put debug leds on the rails so that when something failed to come up, i could see what's going wrong at a glance.

i was advised of the risk that input voltage could ring to 2x the supply voltage due to transients. this couldn't really be tested with my prototype since i needed representative r/l/c values. i used falstad to run a simulation before ordering the boards. those results said the system was overdamped due to the capacitor's high esr, so i went ahead and ordered the boards.

after assembling the board, i tested the inrush behaviour by probing the input net and found that it aligned almost identically to the simulation.

installing the board in the full enclosure, mounting everything on the chair, and watching the system boot for the first time was a great feeling.

a secondary consequence of the computer addition was a redesign of the back-mounted e-stop box. the previous box contained all of the power distribution, including the e-stop, in a single box, connected via a screw-terminal block. it was a pain in the ass to build these. as the e-stop box now only contained the e-stop, indicator leds, and connectors, the box could be simplified, shrunk, and made easier to assemble.

as previously mentioned, compactness is king. to make the box as small as possible, i replaced the terminal blocks with wago connectors, which were required to be able to detach the lid, given that the leds were connected. i briefly considered blind-mating connectors but decided that the juice wasn't worth the squeeze, as the box would be marginally smaller.

the lid was gasketed, with ip-rated panel-mount connectors, to match the water resistance of the main computer enclosure.

hardware only matters if the control stack actually comes up. i had help with over-the-air deployment and compiling the control stack to run on ubuntu, but i owned rapid deployment scripts to quickly deploy the binaries to the nuc. from this point on, a cold power-on from the chair batteries brought the machine straight into the control environment. validation on the lab wheelchair covered thermal logging (cpu temp and clock under stress and representative use) and network latency.

one bug i immediately discovered was that the control software would immediately crash as soon as it came up. the sequence is, the robot initializes, first from the base (main controller), then each actuator follows. once the base initializes, it accepts api connections. our software requests the number of actuators reported by the robot, and checks it against the expected number to guard against failures and incorrect configuration. after the base boots but the actuators are still initializing, the robot reports 0 actuators, so our software crashes and causes an unrecoverable fault, since we constantly ping that request. this failure path was confirmed by disconnecting the nuc and robot, powering up each independently, then connecting. the fault was not observed in this case.

this had never happened while running the robot software on the mac, since the timing of robot boot-up was never concurrent with the software boot, and with the nuc, we are not constantly re-trying robot connection. if we cannot connect, the software typically exits rather than faulting the robot, but on the nuc, we constantly retry.

the fix was fairly simple; kinova's api exposes an armstate enum which we can read. one of those states is ARMSTATE_INITIALIZATION (3), which is reported while, you guessed it, the robot is initializing. i added a gate to wait for the robot to exit this state before proceeding with the software boot.

it wasn't a super complicated problem but was an interesting example of how edge cases can appear when the system's operating conditions change.

this was a great end to end project and learning experience in real electronics. if i spun a rev 2, i'd pull the switchblox nano onto the custom board and replace the ethernet passthroughs with board-mount panel-mating ethernets. this would reduce internal cabling, shrink the box, and reduce assembly steps. the architecture was successful, and the next squeeze is further optimizing for higher-volume production as we scale to more users.