feat(fleet): preserve operator VESC integration before final driver merge
This commit is contained in:
DCCONSTRUCTIONS
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,176 @@
|
||||
# VESC Tool as the onboard engine
|
||||
|
||||
Owner decision, 2026-09-23: Mission Core supplies the local and remote product
|
||||
interface; upstream VESC Tool supplies firmware compatibility, configuration
|
||||
schemas/codecs and motor calibration. Do not continue a separate Python
|
||||
implementation of Tool algorithms. Node 0.8.29-1's separate Hall/speed experiment
|
||||
was built but withheld before installation. Installed hardware remains on
|
||||
0.8.28-1. Calibration and sustained-rotation acceptance are still outstanding.
|
||||
|
||||
## Upstream boundary
|
||||
|
||||
Use the stable [Tool 7.00 source](https://github.com/vedderb/vesc_tool/tree/01d5f10901116c311e3fb84d5a1541f663d3ce20)
|
||||
unchanged. This is a Qt application, not an existing HTTP service or a documented
|
||||
standalone SDK. A small C++ process adapter is necessary; it calls the actual
|
||||
`VescInterface`, `Commands`, `ConfigParams` and `Utility` implementations. It
|
||||
must not replace them with translations of their algorithms. Keep upstream
|
||||
license and corresponding source/build provenance with the combined payload.
|
||||
|
||||
Mission Core owns device identity/position, exclusive access, operation and
|
||||
configuration history, session authority, local/paired transport and UI composed
|
||||
from Design Guideline components. Device parameter definitions, groups, labels,
|
||||
units, limits and enum options come from native `ConfigParams`; they must not
|
||||
be copied into a second permanent hand-maintained schema.
|
||||
|
||||
Updates change a pinned upstream source plus its matching resources and rerun
|
||||
compatibility/replay acceptance. Neither a Tool update nor connecting to a board
|
||||
automatically authorizes firmware flashing or replacing controller settings.
|
||||
|
||||
## Verified native execution
|
||||
|
||||
`plugins/vesc/native/offline_main.cpp` links the existing unmodified Tool object
|
||||
files, substituting only the application entry point. It has no admitted serial,
|
||||
TCP, Bluetooth or powered-operation entry point and does not start an event loop.
|
||||
The versioned `packaging/build_native_probe.py` / `native_probe.py` artifact
|
||||
compiles under an unprivileged 3 GiB user scope; it neither installs dependencies
|
||||
nor touches running services. Separate private Qt settings prevent inheriting an
|
||||
operator's saved connection.
|
||||
|
||||
The adapter replays archived identity through native firmware negotiation,
|
||||
checks archive hash/command/length against the native firmware schema, passes
|
||||
the original configuration packets to `Commands::processPacket`, and exports
|
||||
the resulting native parameter groups and XML. Native serialization must
|
||||
reproduce the original binary configuration exactly. Unsupported firmware,
|
||||
corrupt hashes, wrong signatures and truncated payloads must fail closed.
|
||||
|
||||
An offline `Commands::detectAllFoc` serialization probe also demonstrates the
|
||||
real compatibility behavior: Tool automatically halves a 100 W example to
|
||||
50 W on the wire for FW 5.02. No bytes are delivered to hardware. This correction
|
||||
comes from `VescInterface::fwVersionReceived` and `Commands::detectAllFoc`;
|
||||
implementing only the documented-looking command packet would miss it.
|
||||
|
||||
Tool's own XML writer rounds floating point text (`QString::number` default
|
||||
precision). XML is suitable for native import/export but is not a byte-exact
|
||||
archive. Preserve the original binary snapshots alongside native XML. Native
|
||||
`ConfigParams::checkDifference` supplies the comparison tolerance; do not call
|
||||
XML conversion a lossless binary backup.
|
||||
|
||||
This proves engine reuse and offline compatibility, not a shipped hardware
|
||||
backend. Production dependency closure, installer integration, USB ownership
|
||||
handoff, operation API and physical calibration remain separate acceptance work.
|
||||
|
||||
## Canonical calibration for this 1×1 rover
|
||||
|
||||
The [upstream motor wizard](https://vesc-project.com/node/180) distinguishes
|
||||
motor setup from the [input wizard](https://vesc-project.com/node/181).
|
||||
The current desktop implementation is
|
||||
[`DetectAllFocDialog::runDetect`](https://github.com/vedderb/vesc_tool/blob/01d5f10901116c311e3fb84d5a1541f663d3ce20/widgets/detectallfocdialog.cpp),
|
||||
calling the actual
|
||||
[`Utility::detectAllFoc`](https://github.com/vedderb/vesc_tool/blob/01d5f10901116c311e3fb84d5a1541f663d3ce20/utility.cpp).
|
||||
|
||||
1. Confirm each controller's own identity, take motor and application backups,
|
||||
inspect faults and retain existing battery protections. The problematic motor
|
||||
is LEFT; RIGHT works normally from RC. Do not copy right-side Hall calibration
|
||||
to the left or use software-induced right-side stops as a hardware diagnosis.
|
||||
2. Determine actual connection topology. Two motors, or a Mission Core 1×1
|
||||
layout, do not imply CAN master/slave. There are two USB connections and two
|
||||
receiver inputs (CH3 presumed left, CH2 right). Previous native CAN discovery
|
||||
returned no peers. Calibrate each directly connected device separately until
|
||||
another topology is evidenced; do not enable CAN forwarding merely because
|
||||
the rover has two motors.
|
||||
3. Choose the appropriate native motor procedure. The full auto-FOC wizard
|
||||
prepares parameters, temporarily adjusts battery cutoffs, detects R/L, flux
|
||||
and sensors, writes resulting settings, restores cutoffs and checks direction.
|
||||
It is not equivalent to invoking a Hall command or only starting a motor.
|
||||
Its `maxPowerLoss` is motor heating allowance, not rated shaft power; a
|
||||
remembered 500 W nameplate is not an instruction to pass 500 W here.
|
||||
4. For diagnosis without changing battery settings, use upstream's individual
|
||||
`measureRLBlocking`, `measureLinkageOpenloopBlocking` and
|
||||
`measureHallFocBlocking` procedures. The necessary current/start parameters
|
||||
and actual effects must be explicit. Use upstream calculation/application
|
||||
functions when measurements are accepted; never silently transplant a new
|
||||
Hall table or overwrite unmeasured settings.
|
||||
5. Inspect the resulting sensor mode and measurement status. Firmware 5.02
|
||||
autodetection can report success with a sensorless fallback when Hall/encoder
|
||||
detection fails. That is not proof that the broken Hall pin was repaired or
|
||||
that loaded low-speed startup is acceptable. Firmware Hall measurement locks
|
||||
ordinary motor controls during the cycle; do not promise an RC or USB stop
|
||||
that the firmware cannot perform.
|
||||
6. Read back and archive the applied result, then coordinate a visible direction
|
||||
and startup test. Assign the physical position in the existing Mission Core
|
||||
profile only from observation. Finish motor setup before changing receiver
|
||||
endpoints, neutral, deadband or direction. The receiver remains connected.
|
||||
7. Verify sustained rotation using native motor control with current limits and
|
||||
a speed setpoint. Requested duration means measured rotation after settling;
|
||||
startup, stalled motion and an early guard stop do not count as completed
|
||||
time. A torque/current command alone cannot promise 30 seconds of rotation.
|
||||
|
||||
The full auto wizard includes configuration writes beyond measurements. In
|
||||
particular, blindly executing its battery stage from stale configuration metadata
|
||||
is unsuitable here: saved battery metadata says 3S / 6 Ah while observed input is
|
||||
about 50 V. Existing cutoffs are approximately 44.2 / 39 V. Retaining these
|
||||
settings for motor diagnosis is distinct from validating their suitability.
|
||||
|
||||
Battery brand/capacity are not prerequisites for motor identification. Chemistry
|
||||
and series count are needed when recalculating voltage protection; pack/BMS
|
||||
charge and discharge ratings are needed when changing battery current limits.
|
||||
Do not block native engine preparation or motor-only diagnosis on unknown Ah.
|
||||
|
||||
## Hardware evidence and uncertainty
|
||||
|
||||
Owner photos show UNITE branding and model family BM1418HQF on one motor; the
|
||||
other marking is worn. Owner recalls approximately 0.5 kW per motor, tentatively.
|
||||
The [manufacturer catalog](https://m.unitemotorco.com/brushless-motor/) lists
|
||||
350/500/650/750 W variants with several voltage options. This confirms the
|
||||
family, not the exact rating of this unit. Do not select a direct-drive hub
|
||||
profile based solely on the saved 46-pole / gear-ratio fields.
|
||||
|
||||
Owner reports a nominal 48 V CATL-cell battery and a verbally ambiguous capacity
|
||||
around 120 Ah. The photo shows 13 visible cell bodies, but labels and the complete
|
||||
electrical topology are not visible. Chemistry, exact S/P count and BMS ratings
|
||||
remain unconfirmed. Raw photos, controller identities and native replay outputs
|
||||
stay in private evidence, outside normal Git/Ops.
|
||||
|
||||
## Remaining implementation acceptance
|
||||
|
||||
- Carry the native engine and its qualified runtime dependencies through the
|
||||
existing versioned Node installer; no ad-hoc board package/library repair.
|
||||
- Admit one hardware owner at a time. Existing Python serial descriptors must
|
||||
not compete with VescInterface, and background polling must not interleave
|
||||
another session's calibration commands.
|
||||
- Expose explicit operation requests/results and native parameter metadata on
|
||||
the private onboard boundary; reuse the existing Node and paired Core path.
|
||||
- Keep backups, compatibility checks, timeouts, durable unknown-operation state,
|
||||
readback and observed sensor mode in the receipt. No automatic retry of motion.
|
||||
- Before each powered agent test obtain a fresh observing reply and announce
|
||||
target/parameters. Existing authorization does not establish that the owner is
|
||||
still watching after a build.
|
||||
- Qualify native device reads before calibration, then verify left and right
|
||||
startup/direction and actual sustained rotation separately. Do not mark the
|
||||
rover calibrated from offline tests.
|
||||
|
||||
## Native runtime candidate 0.4.0
|
||||
|
||||
The per-device `native/engine_main.cpp` now implements bounded JSON requests
|
||||
on private inherited pipes. Native VescInterface owns and exclusively locks the
|
||||
actual serial descriptor; the service never opens a competing descriptor.
|
||||
Configuration reads verify upstream serialization against the original bytes.
|
||||
The admitted native methods cover identity/telemetry/configuration/CAN/PPM reads,
|
||||
short app-output leases, current release, bounded current and speed, volatile
|
||||
current scales, native parameter/XML export and upstream blocking Hall detection.
|
||||
No arbitrary packet, firmware flash or general command execution API is exposed.
|
||||
|
||||
`runtime/native_link.py` owns subprocess lifetime and attachment checks. An
|
||||
unmatched/lost response closes the stream; no powered command is retried.
|
||||
Reconnection creates a fresh device session. Pending measurements and current
|
||||
limit restoration remain durable across process failures. During Hall detection
|
||||
only its status, telemetry/PPM reads and release/leases are allowed; none is
|
||||
represented as cancelling firmware's non-interruptible measurement.
|
||||
|
||||
The versioned runtime carries private Qt/offscreen dependencies and source/license
|
||||
provenance. `native_check.py` verifies the installed files and runs the disconnected
|
||||
engine as the service account before USB discovery. Qualification and actual
|
||||
installation/measurement outcomes are recorded in the installation ledger.
|
||||
Full auto-FOC, application of measured calibration, general parameter editing
|
||||
and physical motor acceptance remain outstanding; do not equate this API with
|
||||
complete VESC Tool UI parity.
|
||||
@@ -0,0 +1,72 @@
|
||||
# Калибровка VESC через Mission Core
|
||||
|
||||
Проверено на Node 0.8.35-1 / VESC plugin 0.6.3, VESC Tool 7.00 и прошивке
|
||||
контроллеров 5.02. Это описание доступного процесса; журнал конкретных
|
||||
испытаний находится в `17_VESC_INSTALLATION_LEDGER.md`.
|
||||
|
||||
## Действия оператора
|
||||
|
||||
Открыть «Аппараты», нужный аппарат, устройства его бортового компьютера,
|
||||
нужный VESC и «Настройка VESC». В блоке «Калибровка мотора» проверить выбранный
|
||||
контроллер, параметр допустимых потерь, подтвердить наблюдение и нажать
|
||||
«Откалибровать мотор». Дождаться результата записи, проверки конфигурации
|
||||
и снятия тока. Для второго контроллера открыть его карточку и выполнить
|
||||
отдельную калибровку. Профиль 1×1 сам по себе не запускает групповую калибровку.
|
||||
|
||||
Моторы должны свободно вращаться, пульт — быть выключен. В прошивке 5.02
|
||||
нативное измерение нельзя прервать обычной кнопкой остановки или пультом;
|
||||
оператор должен иметь возможность отключить силовое питание.
|
||||
|
||||
Перед процедурой сохраняются конфигурации подключённых контроллеров.
|
||||
Мастер измеряет электрические параметры выбранного мотора, определяет
|
||||
датчики, рассчитывает настройки FOC и записывает результат. Mission Core
|
||||
проверяет прочитанную обратно конфигурацию и сохраняет версии до/после.
|
||||
Настройки другого мотора, аккумулятора и приёмника защищены от незапрошенного
|
||||
изменения. Полная процедура повторно не нужна перед обычным запуском мотора.
|
||||
|
||||
## Что означает 50 Вт
|
||||
|
||||
«Допустимые потери в моторе» — входной параметр штатного мастера VESC Tool.
|
||||
Он задаёт расчётные резистивные потери на нагрев при предельном токе. По нему
|
||||
и измеренному сопротивлению мастер выбирает токи измерения и рассчитывает
|
||||
сохраняемый предел тока мотора. Это не напряжение аккумулятора, не полезная
|
||||
механическая мощность и не паспортная мощность мотора. Увеличение значения
|
||||
может увеличить ток и нагрев; вводить сюда номинальные 500 Вт автоматически
|
||||
неправильно. Параметр не заменяет измерение температуры и тепловую проверку.
|
||||
|
||||
В принятой калибровке двух моторов при 50 Вт мастер установил примерно
|
||||
34,21 и 34,41 А. Это результат конкретных измерений, а не универсальный
|
||||
допустимый ток всех моторов. Поправку совместимости с прошивкой 5.02
|
||||
выполняет сам VESC Tool. Она не воспроизводится отдельной формулой Mission Core.
|
||||
|
||||
Источник: [объяснение автора VESC](https://www.vesc-project.com/node/1029),
|
||||
[влияние параметра на токи измерения](https://vesc-project.com/node/1640),
|
||||
`Commands::detectAllFoc` и `Utility::detectAllFoc` в закреплённом исходнике Tool.
|
||||
|
||||
## Датчики Холла и отдельное измерение
|
||||
|
||||
Датчики сообщают контроллеру положение ротора. При автоопределении FOC мастер
|
||||
уже проверяет датчики и может выбрать работу без них. Успешная калибровка в
|
||||
режиме без датчиков не доказывает исправность проводки Холлов.
|
||||
|
||||
Кнопка «Измерить датчики Холла» выполняет отдельную диагностику выбранного
|
||||
мотора: штатный цикл при 5 А с медленными смещениями получает таблицу
|
||||
состояний. Она не применяется автоматически, рабочая конфигурация сохраняется.
|
||||
Это проверка для поиска неисправности, а не обязательный второй этап каждой
|
||||
калибровки. Неполная таблица требует различать проблемы датчиков/соединений
|
||||
и недостаточное движение при измерении. Номер физического сломанного контакта
|
||||
не определяется по таблице без проверки распиновки и проводки.
|
||||
|
||||
## Назначение и проверка вращения
|
||||
|
||||
Назначение «левый/правый» связывает постоянный UUID VESC с местом мотора на
|
||||
аппарате. Оно нужно для адресного и общего управления, но не влияет на
|
||||
измеряемое сопротивление или параметр потерь. После смены USB-порта назначение
|
||||
сохраняется. Общий список назначений сейчас отображается в каждой карточке
|
||||
VESC; это обзор профиля аппарата, а не перечень моторов внутри одного VESC.
|
||||
|
||||
«Проверка вращения» запускается отдельно от калибровки. Скорость задаётся
|
||||
в ERPM, ток задаёт верхний предел, длительность считается после разгона
|
||||
и удержания скорости. Выбор всех моторов профиля запускает совместную
|
||||
проверку; для 1×1 это два мотора. Успешная проверка на вывешенном приводе
|
||||
не заменяет проверку под нагрузкой или надёжности связи.
|
||||
Reference in New Issue
Block a user