ODRI Master Board

Project notes

Start with the selected board and wiring

At reviewed revision 574fe988270aa3da948484ad3fa1f15dbf8162bf, the original hardware/V2/esp32_master_board.sch and hardware/V2/esp32_master_board.brd were retrieved and matched to pinned Git identities. Read them with firmware/main/masterboard_main.c. XML inspection found circuit parts/nets and board elements/signals; this establishes real design source. Counts do not establish that the board is electrically correct, manufacturing-ready or compatible with every driver. Inspect its wiring and ordering/preparation instructions against the selected hardware before procurement. [6] [7] [10] [11]

The firmware source and documented state machine provide a concrete communication/control implementation to inspect. The README's latency and 1 kHz demonstration figures are upstream reports, not results reproduced here. A status LED or a transition to an active state does not prove that a host command reached a motor or that timing constraints were met. [1] [5] [8]

Keep the historical toolchain instructions together

The flashing guide states compatibility with ESP-IDF 3.x. Its route installs tooling from v4.0.1, then explicitly rolls the framework back to commit 8d1a9c0 and updates submodules before using the firmware make workflow. It also describes a separate unmerged compatibility change. Do not interpret the installation stage as evidence that the pinned firmware supports arbitrary modern ESP-IDF releases. [3]

The source instructions cover programmer/power wiring and an irreversible flash-voltage fuse operation for the specified board. The flashing guide states 5–60 V supply and the V2 ordering page states 5–30 V. The wiring guide explains the distinction: 60 V is an absolute maximum, while the connector size calls for a lower 30 V limit without additional insulation. Those source statements are not an electrically validated operating envelope for a new setup. Those details require configuration-specific review; no fuse was burned, programmer connected or power applied here. After matching the environment, the documented commands include make menuconfig, make flash and make monitor. They were not executed in this review. [3] [10] [11]

Select the host transport before running a motion example

The SDK requires a direct Ethernet interface dedicated to the board; the README says it cannot simultaneously serve the local network. The wireless route requires monitor-mode and packet-injection support because this is not ordinary Wi-Fi networking. Those interface prerequisites affect hardware choice and host configuration. No network configuration was changed here. [9]

The C++ example route builds with make and runs the executable with an interface name. The Python binding route uses CMake with BUILD_PYTHON_INTERFACE and requires setting the controlled-slave count. The C++ example issues a sinusoidal trajectory. The Python instructions distinguish a control script from separate listener and communication-analyser scripts; inspect the selected example and connected drivers before execution. This review establishes no successful SDK build, communication session or motor control. [9]

The root notice is BSD-2-Clause, while the ordering/preparation document declares BSD 3-Clause. Preserve those per-source declarations and review their applicability before redistribution; external ESP-IDF components, modules and purchased drivers retain separate rights. No complete current board/system cost, native DRC, firmware build, packet-timing benchmark or powered robot experiment was established. [2] [11]