When to use it
Reasonable
Reproducing a bug on request, testing a fix that affects you, or evaluating a feature on a bench setup.
Not reasonable
Production hardware, anything carrying a person or payload, or a build you cannot easily recover.
Before you flash
1
Save your working configuration
XML → Save Motor Configuration and XML → Save App Configuration. Experimental builds are the most likely to reset or reinterpret parameters.
2
Record the stable version you are on
You need to know exactly what to go back to — the firmware version and the matching VESC Tool version.
3
Download the rollback binary first
Get the stable build on disk before you flash the experimental one, not while troubleshooting a board that no longer behaves.
4
Reduce your limits
Lower current and temperature limits below your normal working values for the first run. If fault handling has regressed, conservative limits are what catches it.
Running an experimental build
The flashing procedure is identical to a normal update — see firmware upgrades. The difference is entirely in what you do afterwards.1
Bench test first, unloaded
Motor unloaded and free to spin. Propellers, gears, belts, and wheels off.
2
Watch Realtime Data throughout
Current, duty cycle, temperature, and the Fault field. Do not look away during the first run-up.
3
Exercise the failure paths deliberately
Confirm voltage cutoffs, temperature cutoffs, and loss-of-signal behaviour still work. These are exactly what an experimental build might break, and exactly what you will not notice under normal operation.
4
Only then apply load
And increase it gradually, not in one step.
Rolling back
1
Flash the stable binary
Same procedure as any update. Do not cut power mid-write.
2
Restore your saved configuration
XML → Load Motor Configuration, then write to the controller. Do not assume parameters carried across the version change intact.
3
Re-verify
Check limits and run the motor up gently before returning to normal use.
If a board will not connect after an experimental build, work through the connection checks in the quickstart before concluding the firmware is at fault — DC power and cable problems look identical to a bad flash.
Reporting problems
Experimental builds exist to collect exactly this information. A useful report includes:- The experimental build identifier and the VESC Tool version you used
- The stable version you came from
- Motor and controller configuration — attach the saved XML
- What you observed, and what you expected instead
- Any fault codes from the Fault field
- Whether it reproduces after a power cycle, and whether it reproduces on a stable build
Report an issue
github.com/IntrusiveRobotics/Delta/issues
Contact Intrusive Robotics
Available builds
No experimental builds are currently listed here.When one is published, this section should record its identifier, what it changes, the VESC Tool version it pairs with, known issues, and the stable build to roll back to.
Related
Firmware upgrades
The standard update procedure and version pairing.
Motor tuning and parameters
Re-verifying limits after a firmware change.