Development and extensions#
This page is intended for developers who modify the lerobot_alohamini software. If you only need to use the robot, start with the Getting started with models.
1. Create a development environment#
Use the project to lock dependencies in the root directory of the software repository:
uv sync --locked --extra test --extra dev
Install only the extras needed for the current job. When it comes to data sets, policies, simulations, or specific hardware, follow the corresponding tutorials to add dependencies. When you need Git LFS test assets:
git lfs install
git lfs pull
2. Find the module to be modified#
path |
Responsibilities |
|---|---|
|
Command entrances for training, evaluation, recording, etc. |
|
Parameters and dataclass configuration |
|
AlohaMini configuration, host and client |
|
Bus, servo configuration and reading and writing |
|
camera interface |
|
Various policies and factory registration |
|
Input and output processing flow |
|
LeRobot data set reading and writing |
|
Arm calibration, teleoperation, acquisition, evaluation |
|
Automated testing and fixtures |
When adding a new piece of hardware, first define fields, units, joint sequences, calibration and connection behaviors, and then implement control; changing observations or action definitions will also affect historical data and models.
3. Read by stretch goals#
target |
Complete tutorial |
|---|---|
Add a new robot, camera or teleoperation device |
|
Custom policy |
|
Understanding processors |
|
Implement new processing steps |
|
Debug data transformation |
|
Extended evaluation environment |
|
Compatible with old data and interfaces |
|
Submit a contribution |
4. Verify changes#
First run the tests related to the modified module, for example:
uv run pytest tests/test_alohamini_sim_bridge.py -svv
Complete test entry and format check:
uv run pytest tests -svv --maxfail=10
pre-commit run --all-files
Hardware testing, GPU testing, and integration testing may require additional equipment, assets, or dependencies. Record the actual execution scope, and skipped tests cannot be counted as passed real machine verification.
5. Improve documentation#
The documentation is written in Markdown and is located in the source/ directory of the documentation warehouse. When modifying, please indicate the applicable model, check the device parameters in the command, and add a navigation entry for the new page.
Build and preview locally before submitting to confirm that images, videos and links are normal. Changes involving hardware operation should be documented with both verification equipment and software versions.
View development topics · Participate in document contribution