HI @oiler251 , we will work on a more detailed step by step guide for debugging VIO. Meanwhile, you may found the below unofficial guide useful.

VOXL 2 / OpenVINS Drift Troubleshooting Guide

Applies to: Starling 2 / Starling 2 Max and other VOXL 2 vehicles running voxl-open-vins-server with PX4

How to use this guide

The steps are ordered by cost × likelihood: the first few take minutes and catch the problems that cause most "my drone drifts" reports. Each step has a pass/fail check. Don't skip ahead. If a step fails, fix it and restart from Step 1, because a fix upstream often changes what you see downstream.

The pipeline you're debugging, end to end:

tracking cams + imu_apps ──► voxl-open-vins-server ──► voxl-vision-hub ──► PX4 EKF2 ──► position controller
     (Steps 4, 7, 8)              (Steps 3, 5, 9)          (Step 6)          (Steps 1, 6)      (Step 0, 8)

The core diagnostic split, straight from ModalAI's docs: if voxl-inspect-vins shows valid, moving position data, VIO is working, and no amount of camera recalibration will help; the problem is on the PX4 side. Use that rule constantly.

Quick triage table

Step 0 — Confirm which flight mode the drift happens in (2 min)

Why first: this single question resolves a large share of reports. Manual mode will drift because it has no position control.

Do:

• Note the mode on the RC mode switch and in QGC at the moment of drift.
• Manual / Stabilized / Altitude: horizontal drift is expected. Altitude mode holds height only.
• Only Position (and Offboard) mode uses VIO to hold X/Y.

Pass: the drift is happening in Position mode. → Continue.
Fail: the drift is in Manual/Altitude. → The fix is to get Position mode working; go to Step 1.

Note for the #5505 case: the user also re-ran QGC's sensor calibration hoping to fix drift. That calibrates PX4's flight IMU, which helps attitude, but it does not touch imu_apps, the IMU OpenVINS uses (see Step 7). It also cannot make Manual mode hold position.

Step 1 — Is PX4 configured for indoor VIO? (5–10 min, highest-yield check)

Why: a ModalAI moderator stated that the Starling 2 Max is marketed as an outdoor drone and ships with "outdoor GPS" PX4 parameters, so its default Position mode tries to use GPS. Indoors with no GPS fix, PX4 then rejects Position mode or flies on a bad estimate. Another Starling 2 Max user's drift was resolved by loading indoor_vio_missing_gps.params.

Do:

1. Plug in the battery, wait ~30 s for voxl-vision-hub to start, connect QGC.
2. Flip the mode switch Manual → Position with the props off or disarmed. Listen for QGC's announcement:
   • "position" → PX4 accepts the VIO.
   • "position mode rejected, altitude flight mode" → PX4 isn't getting or isn't fusing VIO.
3. Load the version-matched indoor VIO parameter file from voxl-px4-params (for PX4 v1.14: params/v1.14/EKF2_helpers/indoor_vio.params, or indoor_vio_missing_gps.params if no GPS is attached). In QGC: Parameters → Tools → Load from file, then reboot.
4. Spot-check these parameters afterward:

EKF2_AID_MASK no longer exists on PX4 1.14; ignore older guides that reference it.

Pass: QGC accepts Position mode on the bench.
Fail: continue to Steps 2–3 to find out why VIO isn't reaching EKF2.

Watch for: params from the wrong PX4 version cause subtle breakage. Also, a connected GPS/mag unit fighting VIO can corrupt local position. For a quick experiment, ModalAI suggests disconnecting it.

Step 2 — Are the right services running, and only one VIO engine? (2 min)

Do:

voxl-version
voxl-inspect-services

Pass criteria:

• voxl-camera-server, voxl-open-vins-server, voxl-vision-hub, voxl-px4 are Enabled + Running.
• voxl-qvio-server is Disabled / Not Running. Only one VIO engine should run at a time.
• /etc/modalai/voxl-vision-hub.conf has:

  "vio_pipe":           "ov",
  "secondary_vio_pipe": "",
  

  Vehicles set up on older SDKs may still have "vio_pipe": "qvio" with OpenVINS as the fallback.
• All packages come from one SDK release. Mixed package versions break the pipeline. Prefer flashing a complete SDK over upgrading single packages.

Fix if needed:

voxl-configure-qvio disable
systemctl stop voxl-qvio-server
systemctl enable voxl-open-vins-server
systemctl restart voxl-open-vins-server voxl-vision-hub

Nuclear option: voxl-configure-mpa resets every service config to the SKU defaults.

Step 3 — Is VIO healthy on the ground before arming? (2 min)

Do:

voxl-inspect-vins

Read three fields:

• State: FAIL (0), INIT (1), or OKAY (2). Must be OKAY.
• Quality: higher is better; -1 = failed. OpenVINS applies hysteresis, so it shouldn't flicker.
• Error codes: a hex bitfield decoded by the tool. Mostly meaningful when the state is FAIL. The full table is on the Pipe Interface page.

Pass: OKAY, stable quality, position near zero and not wandering while the vehicle sits still.
Fail: stuck in INIT → Step 9's "won't initialize from rest" list. Wandering while stationary → Steps 4 and 7.

Operational rule: ModalAI recommends that if you need VIO from takeoff, you initialize statically on the ground, confirm OKAY, and only then take off. Make "wait for OKAY" part of the preflight.

Step 4 — Look at the camera images (5 min)

Why: VIO depends on visible features plus low-noise IMU data. Bad imagery is the most common physical cause of drift indoors.

Do: open voxl-portal in a browser (drone's IP) and view each tracking camera and the VIO tab.

Checklist:

• Lens covers removed, lenses clean (plastic lens; microfiber only)
• In focus: for OV7251 fisheye, everything beyond ~15 cm should be sharp (test with high-contrast objects at 15 cm and 1 m)
• Enough light; no glare or hot spots
• Texture at both near and far range. A plain lab floor under the down camera, blank walls, or a boundary net filling the view all starve the tracker. Far-only features give orientation but poor position.
• Nothing intruding into the view (legs, tether, payloads, wiring)
• Cameras detected:
  voxl-camera-server -l

Also check camera-server health. A Starling 2 Max user on SDK 1.6.3 / OpenVINS 0.6.0 saw massive drift from feature loss. Running voxl-camera-server in the foreground showed repeated Received "Result"/"Buffer" error from camera: tracking_down and dropping frame after re-init. ModalAI's fix was updating OpenVINS to the GitLab master branch (or the synced-timestamp branch for epoch-synced AR0144 tracking cams). To look for this:

systemctl stop voxl-camera-server
voxl-camera-server        # watch for repeated per-frame errors, then Ctrl-C
systemctl start voxl-camera-server

Fix: add texture (tape patterns, posters, mats on the floor), improve lighting, or move the takeoff spot. ModalAI's guidance is to fix the scene rather than tune the estimator.

For the 20' × 30' netted demo area: a uniform floor plus a net perimeter is a weak VIO environment. Put high-contrast texture on the floor under the takeoff point and along the walls the front camera will see.

Step 5 — Hand-held test (5 min, props off)

This is the definitive "is VIO itself healthy?" test. Repeat it after any VIO config change.

1. Props off, VIO running, VIO tab open in voxl-portal.
2. Slowly lift and move the vehicle about half a meter. Features should stay locked on the same physical points. Features that pop in and out or slide off their targets usually mean wrong camera-to-IMU extrinsics.
3. Walk it around the room and return it to the exact start position and heading. Reported drift should be a few percent of distance traveled, with very small yaw drift.
4. While moving, sanity-check axes in voxl-inspect-vins. Forward should give +X; up should give −Z (FRD/NED).

Pass: drift is a few percent and features are locked → VIO is fine. Go to Step 6.
Fail: large drift or sliding features → Step 7 (calibration/extrinsics). If calibration checks out → Step 9 logging.

Step 6 — Verify the pose that actually reaches PX4 (5 min)

Why: VIO can be perfect while the estimate PX4 flies on is wrong, because extrinsics or EKF2 fusion sit in between. A coordinate mismatch makes PX4 take off and then quickly run away out of control.

Do:

1. Pose after extrinsics are applied (should match PX4's local position):

   voxl-inspect-pose vvhub_body_wrt_local
   

   Good VIO but wrong pose here → extrinsics problem. Check with voxl-inspect-extrinsics and see Configure Extrinsics.
2. In QGC → Analyze → MAVLink Inspector:
   • ODOMETRY: X/Y non-zero and moving correctly in NED as you carry the drone (forward = +X North-ish in local frame, right = +Y, up = −Z).
   • LOCAL_POSITION_NED: Z updating but X/Y stuck at zero = EKF2 config problem, not VIO. Go back to Step 1.
3. Check camera selection: voxl-inspect-vio-cams (config in /etc/modalai/vio_cams.conf).

Pass: VIO pose, vision-hub pose, and PX4 local position all agree and move in the right directions.

Step 7 — Calibration (15–60 min)

Only do this if Steps 3–6 point at estimation quality. Recalibrating isn't free, and it doesn't help when VIO is already good (see the decision rule at the top).

7a. VIO IMU (imu_apps), not the PX4 IMU

• The VIO IMU is the apps-processor IMU (imu_apps), not the one PX4 flies on. QGC sensor calibration does not calibrate it.
• Recalibrate with voxl-calibrate-imu (or from voxl-portal), then confirm gravity reads ≈ 9.81 m/s²:

  voxl-inspect-imu imu_apps
  

• A wrong gravity magnitude or bad biases give a static init that looks fine on the bench and falls apart once airborne.
• Try removing the IMU temperature-calibration file from /data/modalai/. It's optional and can hurt if captured poorly. Back it up first.

7b. Camera intrinsics

• Files: /data/modalai/opencv_<pipe>_intrinsics.yml.
• Resolution in the cal file must match the camera's current streaming resolution. A 640×480 cal is invalid at 1280×800.
• Check the stored reprojection_error. The ModalAI calibrator accepts ≤ 0.75 px (pinhole) / ≤ 0.60 px (fisheye); recalibrate if you're near the limit.
• Tracking cameras are factory-calibrated. If you've lost the factory cal, ModalAI keeps production backups; ask on the forum with the board's serial number.

7c. Extrinsics

• /etc/modalai/extrinsics.conf defines camera/IMU geometry. ModalAI ships these from CAD, so they're accurate but not per-unit calibrated. They only need changing if cameras were moved or the airframe was modified.

️ Documentation discrepancy (calibration threshold): ModalAI's calibrator accepts up to 0.75 px (pinhole) / 0.60 px (fisheye). Upstream OpenVINS says a good calibration has reprojection error under about 0.2–0.5 px. A cal that "passes" ModalAI's gate can still be mediocre by OpenVINS's standard. If you're chasing residual drift, treat anything above ~0.5 px as a recalibration candidate.

Step 8 — Mechanical & flight-dynamics confounders (10 min)

These make a good estimate look like drift, or degrade it in flight only.

• Vibration: degrades VIO significantly. Check with:

  voxl-inspect-vibration
  

  and the PX4 log. Fix damping, balance props, and replace damaged props before touching software.
• Tether / test fixture: the #5505 user is flying tethered to a fixture. A taut tether pulls the vehicle, so the position controller fights it, which can look like "jumping up and down" and drift. It may also intrude into a camera view. Validate VIO with a slack tether, or untethered at low altitude in a netted area.
• Height "bouncing": check which height source EKF2 uses in the indoor param file you loaded and confirm it actually applied. In a small enclosed room, prop wash and ground effect disturb a barometer.
• Airframe changes: added payloads, lights, or prop guards affect both vibration and camera view.

Step 9 — Initialization & in-flight resets

VIO won't initialize from rest (stuck in INIT)

ModalAI's ordered list:

1. Recalibrate IMU; confirm ≈ 9.81 m/s² (Step 7a).
2. Camera calibration resolution matches current stream (Step 7b).
3. Lighting/texture at the takeoff spot. Static init doesn't need features, but the filter needs them immediately after.
4. Static vs dynamic init: static needs the vehicle stationary and level-ish. Dynamic needs ~2 s of motion with parallax, which a vehicle sitting still never provides.
5. Vibration / airframe intrusions.
6. Record a log (Step 10).

Sudden jump or lurch mid-flight

That's likely an auto-reset. The health monitor (30 Hz) resets on estimator-health codes (corrupt covariance, sustained low quality, feature starvation, velocity-uncertainty breaches). Transport warnings such as dropped frames do not trigger resets. A dynamic re-init can produce a jump discontinuity in the estimate, which PX4 will chase.

• Watch voxl-inspect-vins during a hover for state changes and error codes.
• If the use case can't tolerate jumps, ModalAI's advice is not to rely on dynamic init or warm resets. Initialize statically on the ground instead.
• Relevant knobs: en_auto_reset, auto_reset_max_velocity, auto_reset_max_v_cov_timeout_s, auto_reset_min_features, auto_reset_min_feature_timeout_s in /etc/modalai/voxl-open-vins-server.conf; init_dyn_use in estimator_config.yaml. The shipped values are sensible, so change one group at a time and validate with replays.

️ Documentation discrepancy (initialization defaults and where init_dyn_use lives):

• The Flying with VIO page says Open-VINS "initializes dynamically at any attitude."
• A 2025 forum reply from ModalAI staff (SDK 1.4.1) says the default config does not use dynamic initialization, and puts init_dyn_use in voxl-open-vins-server.conf.
• The current Initialization & Resets page puts init_dyn_use in estimator_config.yaml (under the yaml_folder, default /usr/share/modalai/voxl-open-vins/VoxlConfig/starling2) and presents static vs dynamic as an application choice.

Behavior has changed across SDK versions. Check init_dyn_use in both files on the actual vehicle rather than trusting any one page, and match it to the SDK reported by voxl-version.

Step 10 — Capture data and escalate

If you got here without a fix, collect a complete package before posting to the forum. It turns a multi-day back-and-forth into one reply.

voxl-version > voxl-version.txt
voxl-inspect-services > services.txt
cp /etc/modalai/voxl-open-vins-server.conf /etc/modalai/vio_cams.conf /etc/modalai/extrinsics.conf .
voxl-logger -b -v ov            # record VIO around a failing hover/takeoff

PX4 flight log (.ulg

adb shell ls /data/px4/log
adb pull /data/px4/log/<session>/<log>.ulg .
# or: QGC → Analyze → Log Download

Upload the .ulg to https://logs.px4.io. The VIO log can be replayed offline with voxl-benchmark-vio.

Include: flight mode at time of drift, the hand-held test result, and screenshots of the voxl-portal VIO tab and the QGC ODOMETRY / LOCAL_POSITION_NED inspector.

Appendix A — Likely path for forum thread #5505

Based only on what the user posted. Not confirmed.

1. Flew in Manual mode → drift is expected (Step 0).
2. Indoor GPS-denied lab on a Starling 2 Max → very likely still on the factory outdoor/GPS params; load the indoor VIO params (Step 1). This is the single most likely fix.
3. Recalibrated sensors in QGC → doesn't affect imu_apps; if VIO is bad, use voxl-calibrate-imu (Step 7a).
4. Tethered to a fixture, "jumping up and down" → tether loading and/or height source; test with slack tether (Step 8).
5. Demo in a netted 20'×30' room → add floor/wall texture and wait for OKAY before arming (Steps 3–4).

Appendix B — Command cheat sheet

Sources

• ModalAI — Flying with VIO (triage ladder, hand-held test, X/Y-zero rule, IMU and calibration checks, PX4 params)
• ModalAI — voxl-open-vins-server
• ModalAI — Initialization & Resets
• ModalAI — Pipe Interface / error codes
• ModalAI — voxl-px4-params
• OpenVINS — Sensor Calibration
• Forum — #5505 Starling Max 2 arming/drift
• Forum — Starling 2 Max drifting off (manual mode)
• Forum — Position Mode Unavailable (outdoor GPS params)
• Forum — OpenVINS drift from camera-server errors
• Forum — Problems resetting voxl-open-vins-server
• Forum — voxl-open-vins-server config (SDK 1.4.1)

When you lower your throttle stick on the RC and look at the RC tab in QGC, does the throttle slider actually decrease or is it mapped to pitch? If you are assuming that throttle is the left stick (up down), that is Mode 2. Mode 1 would put throttle on the right joystick, so that seems like your issue.

Please refer to the standard PX4 calibration procedure for the RC. For example, more details here https://docs.px4.io/main/en/config/radio . You may also just need to clear your RC parameters from PX4.

You can also try to clear your calibration since it's normally not required : https://docs.qgroundcontrol.com/v4.4.3/en/qgc-user-guide/setup_view/radio.html

"
TIP

You can clear all parameter/tuning channel mappings by selecting menu Tools > Clear RC to Param at the top right of the Parameters screen.
"

@sjt277 , I am sorry this happened to you. In order to help evaluate the issue, can you please post photos of both sides of the M0138 ESC board (high resolution, please, you could share a link if the forum does not accept it).

Also please point out in the picture which component is getting hot. Also, since you are using a power supply, it should provide the current draw when you attempt to power on the ESC. Please let us know the voltage and current reading on the power supply and whether it is changing.

Did the ESC work at first (spinning motors) and then stopped working at some point?

Please note that testing ESCs using a power supply often lead to permanent damage due to regenerative spikes when the motor is braking (causing over-voltage). https://docs.modalai.com/voxl-escs/faq/#unboxing-and-testing-new-standalone-esc

Alex

Hello @enric-cervera-mateu ,

Good news: you don't need to install any special ModalAI firmware on the iFlight Commando 8. ModalAI does not provide transmitter firmware — the Commando 8 ships pre-loaded with EdgeTX and a built-in ELRS module, which is exactly what you need to control a VOXL 2 Starling.

Here is what you actually need to do:

1. Make sure you have the right frequency variant

The Starling V2 ships with a 915 MHz BetaFPV ELRS receiver. You must use a Commando 8 with a matching band:

• If your drone has the 915 MHz receiver → get the iFlight Commando 8 ELRS 868/915 MHz V2
• If your drone has a 2.4 GHz receiver → get the iFlight Commando 8 ELRS 2.4 GHz V2

Mixing bands (e.g., 2.4 GHz TX with 915 MHz RX) will prevent binding entirely.

2. Match ELRS firmware versions

The ELRS firmware version on the transmitter module and the receiver must share the same major version (e.g., both on 3.x). Mixing 3.x and 2.x is not supported.

• Check the TX firmware version in EdgeTX: go to SYS → Hardware → TX Module or the ELRS Lua script.
• Check the receiver firmware version via the voxl-elrs tool on the drone (see Step 4).
• If versions don't match, update both using the ExpressLRS Configurator for the TX module, and voxl-elrs for the receiver.

3. Bind the transmitter to the receiver

Two methods work with ELRS:

Method A — Binding phrase (recommended):
Both the TX module and receiver must be flashed with the same binding phrase. If the original controller used a binding phrase, you'll need to reflash the receiver on the drone with a new phrase that matches what you set on the Commando 8.

Method B — Button bind:

1. Power on the drone. Within 30 seconds, press and hold the bind button on the ELRS receiver.
2. On the Commando 8, start binding from the ELRS Lua script (Tools menu in EdgeTX).
3. The receiver LED will change when binding succeeds.
4. Power-cycle the drone after binding. (Skipping this step causes "Detected 0 radio channels" errors.)

4. Configure the VOXL 2 software

SSH into the VOXL 2 and edit the PX4 configuration file:

vi /etc/modalai/voxl-px4.conf

Set the RC protocol to CRSF:

RC=CRSF_RAW

Then restart the PX4 service:

systemctl restart voxl-px4

5. Verify RC input

After binding and restarting, verify channels are publishing:

px4-listener input_rc

If no channels appear, check:

• Power-cycle was done after binding
• journalctl -b -u voxl-px4 for driver errors
• Physical wiring on connector J19 (receiver TX → RC_UART_RX, receiver RX → RC_UART_TX, 5V, GND)

Wiring reference (J19 on VOXL 2)

For the full wiring diagram and RC configuration reference, see the official docs:

• RC Configs: https://docs.modalai.com/voxl2-rc-configs/
• voxl-elrs tool: https://docs.modalai.com/voxl-elrs/

If you continue to have binding issues (particularly if the receiver is still bound to the original lost controller), you may need to reflash the receiver to clear the old binding phrase. The voxl-elrs tool can help with this for BetaFPV receivers.

Sources

• https://docs.modalai.com/voxl2-rc-configs/ — VOXL 2 RC controller configuration, wiring, supported protocols
• https://forum.modalai.com/topic/3066/elrs — ModalAI forum thread on ELRS setup with VOXL 2 Starling
• https://forum.modalai.com/post/17958 — Forum post on switching Starling 2 from Ghost Atto to ELRS
• https://shop.iflight.com/Commando8-Radio-Transmitter-ELRS-V2-Pro2092 — iFlight Commando 8 ELRS V2 product page
• https://github.com/ExpressLRS/ExpressLRS — ExpressLRS project (for Configurator tool)

Hi @oiler251 , please follow these steps to diagnose the issue. It looks like Step 1 is ok, but double check it anyway.

Step 1: Check the RC protocol setting

SSH or ADB into the drone and check /etc/modalai/voxl-px4.conf:

cat /etc/modalai/voxl-px4.conf

Look for the RC setting. It must match your controller's protocol. For Ghost/GHST receivers (the Starling Max 2's default), it should read:

RC=GHST

If it shows SPEKTRUM, SBUS, or anything else, change it to GHST (or whatever protocol your controller uses), then reboot:

reboot

This exact issue caused arming failures for other Starling Max 2 users after running ESC or RC calibration — see this thread and this one for confirmed resolutions.

Step 2: Re-check RC calibration (switch channels)

If the protocol is correct, the calibration itself may have missed the switch channels. When you re-run RC calibration in QGroundControl, make sure you move all switches (kill switch, mode switch, and any others) through their full range when prompted. Channels 5–8 need to be swept or the calibration will leave them in a bad state.

Step 3: Check the specific arming failure reason in QGC

Connect to QGroundControl and attempt to arm. QGC will display a specific pre-arm failure message (e.g., "RC not calibrated", "Throttle too high", "Kill switch engaged"). That message will tell you exactly what PX4 is blocking on.

Common blockers:

• Throttle not at zero — left stick must be fully down before arming
• Kill switch active — ensure it's in the "disarmed" (off) position
• RC not calibrated — re-run calibration as above

Regarding the original drift issue:

Drift after takeoff is usually caused by an IMU or accelerometer calibration issue, or by flying in a mode that requires GPS/VIO when neither is available (or not configured). Once you get arming working, if drift persists, share the output of voxl-inspect-services and a flight log — that will help diagnose whether it's a sensor calibration or an estimation/navigation issue.

How to retrieve PX4 logs (for when you need them):

Option 1 — ADB over USB:

adb shell ls /data/px4/log          # list sessions
adb pull /data/px4/log/sess001/log001.ulg .

Option 2 — SCP over WiFi (replace IP with your drone's IP):

scp -r root@192.168.x.x:/data/px4/log ./px4_logs

Option 3 — QGroundControl:
Go to Analyze → Log Download while connected over WiFi.

Then upload the .ulg file to https://logs.px4.io for analysis.

Please try Step 1 first and report what the RC setting shows — that's resolved this exact symptom in at least two prior cases.

Sources

• Starling 2 Max Not Arming (forum post/19806) — RC protocol set to SPEKTRUM instead of GHST; confirmed fix
• Drone not flying manually with ORQA FPV.Ctrl controller (forum post/19647) — same RC protocol fix confirmed by ModalAI staff
• Arming Issues with Controller (forum post/3641) — controller switches visible in QGC but arm gesture not working
• Starling 2 Max does not roll and pitch in position mode — related flight behavior thread
• Downloading PX4 ulog files (forum post/7053) — log retrieval methods
• VOXL PX4 docs — official VOXL 2 PX4 documentation

Hi @PQL,

This is most likely due to the updated version of camera server and vio applications, as performance enhances may have impact on the cpu / gpu usage. We can help double check this. A few suggestions:

• if you are able, can you please use voxl-inspect-cpu to measure the top CPU consumers for both drones and post here. This way we can check if something looks abnormal. Both drones should be in the same state (on bench, everything running.. or whatever environment you want to test in).
• you can downgrade your new drone to earlier SDK and see if the CPU usage / temps reduce to original value

Alex

The pinout is not specified in the M0155 docs, but it is identical on the camera side and is listed here, for example : https://docs.modalai.com/M0186/#module-connector-pinout-for-j1-s-h26-hr-ds-412

@patkirkmartin , so sorry for the delay. We are ready to proceed with sharing the source code for M0065 board and I just wanted to double check that you are still interested. Please let me know and we will get this going right away.

If you use our APM, it will provide power for VOXL2 and the APM also includes voltage and total current sensing and has PX4 support for that. The information is delivered to px4 via I2C.

If ModalAI ESCs are used, such as M0129 (mini esc) or M0138 (larger / racing ESC), they both provide power for VOXL and measure voltage and total current and provide this information to PX4 via telemetry via UART.

Alex

Hello @ישראל-בן-שלמה ,

Please see some options below and the recommendations at the end.

• For reliable VIO, we recommend dual tracking cameras. The tracking cameras are very light, so the extra 3 grams will give you lots of safety margin
• AR0144 is probably the best option since this is what we use. 2.2g with 80mm coax cable
  • OV7251 camera (M0014) is probably the smallest (it is lower resolution also 640x480 vs 1280x800 for AR0144). ov7251 is EOL but it looks like we have some in stock. the weight of M0014 module is 0.5g (with the flex cable). However, to connect it to VOXL2 / mini, you would need an interposer like M0076 (0.6g) ( or M0135 (1.0g)
• IMX214 (M0025 module, https://docs.modalai.com/M0025/ ) may be the lightest 4K camera we have (0.7g with flex cable), but it is very old and sensor + lens quality is very far from our newer (and heavier) IMX412- and IMX664-based camera modules.
• Flir Boson 320 is a bit heavy too. The one i have with lens is about 23g. Most of the weight is the lens, i think.
  • for connecting Boson to a Voxl2 Mini, you should use M0194 ( https://www.modalai.com/products/m0194 )
• Boson → M0201 → coax → M0194 → VOXL 2 Mini J6 or J7?
• you can plug in another camera into M0194, such as AR0144 (coax version) or the IMX412 (coax version)

The best option in terms of support (no EOL components) and hardware quality, would probably be:

• VOXL2 Mini (11g)
• M0195 (5.0g) -- see C43 configuration : https://docs.modalai.com/M0195/
• Boson + M0201 + coax -> plugs directly into M0195. weight of M0201 + 80mm coax is 1.7g + 0.7g = 2.4g. Need to add weight of Boson!
• one or two AR0144 (M0166) -- 2.2g with 80mm cable (each)
• hires camera (IMX412) M0161 : 8.5g with 800mm coax cable

Minimal Config

• VOXL2 Mini (11g)
• M0194 plugged into J7 (1.4g) + 80mm coax (0.7g) + M0201 (1.7g) + weight of Boson
  • M0166 AR0144 (2.2g with 80mm coax) plugged into M0194
• M0076 (0.6g) plugged into VOXL2 mini J6
  • M0025 IMX214 camera (0.7g) plugged into M0076
    ** note that this is mixing the coax and non-coax cameras, but i think this should work. we would need to give this a quick test to make sure.

Alex

hi @nostrain ,

Thank you for providing an important detail regarding unloaded motor. I am going to test that condition with a similar motor.

I am a bit hesitant to ask you to go back to the older firmware since we have had a number of improvements since the original firmware, so we will try to figure out how to make this work.

In general, the ESC with unloaded motor should not be doing this, even while running in RPM control mode (which has been tuned for optimal response with a propeller). Ideally, the unloaded performance should not fail (while would behave differently from loaded motor).

Meanwhile, i am not sure how much value it is to do RPM step response tests with unloaded motor, because RPM controller assumes a loaded motor and the RPM controller is using the tuning parameters you provided. However, the motor behavior is extremely different without the propeller. To test realistic conditions, we typically run robustness tests like this with propeller on.

One more request, are you able to repeat the same test with the original firmware (that currently works) and set the demag_timing ESC parameter to 0. This was a feature originally put in for testing to help with low kv motors, but we later decided that this feature was not complete / robust enough to cover general use cases and it was removed. I am curious if it is helping in this case.

Alex

Hi @jbiscan21 ,

The main issue was that the max_rpm_delta was set to zero. Even with PI gains (and max errors) set to zero, you could have had it working with non-zero max_rpm_delta. Let me explain.

max_rpm_delta term is used to cap the target rpm relative to the current rpm. This is done to prevent very aggressive motor behavior, especially if motor is spinning very slowly because it is tangled in grass, etc, allowing unlimited max_rpm_delta could cause motor to burn out or de-sync.

The RPM controller has a feed-forward term and feedback terms.

• feedback terms are Proportional and Integral with corresponding gains and error terms (k * e).
• feed-forward term comes from the calibration : for desired RPM, the calibration tells the ESC what PWM (duty cycle) to apply
• there is also battery voltage compensation, so that even if voltage is changing, the feed-forward curve will still be accurate.

The rpm error is computed like so : rpm_error = rpm_desired - rpm_current, which standard. But then it is capped with the max_rpm_delta, so if that is equal to zero, then rpm_error will be zero. One subtle detail is that the rpm_error is also used to look up the desired rpm feed_forward : rpm_for_feed_forward_term = rpm_current + rpm_error (roughly speaking), so having the max_rpm_delta set to zero, caused the motor to be always stuck at minimum rpm.

So you could still have zero P and I terms and the motor would use a feed forward term with voltage compensation and it would provide a nice and soft response (similar to traditional ESC). Adding P and I will make the response better than a traditional ESC.

In fact when using a new motor + prop, you should start off with P and I gains zero, just use a feed forward term to test at first and then you can increase the ESC's responsiveness by giving it more max_rpm_delta and also P and I terms. However, that is more advanced tuning should be done using voxl-esc tools first in order ensure ESC response stability (we could discuss that in another thread).

To answer your earlier questions:

• You could use pwm (power) control, but i have never used it with PX4. Perhaps @eric-katzfey can comment about that
• the ESC calibration for modalai ESCs calibrates the feed-forward term (as described above), and has to be done with a propeller. Yes, in flight, the air dynamics will change due to many factors such as air pressure, temperature, air speed, etc, etc, but the job of RPM controller is to keep a desired rpm. A higher level controller could potentially estimate the thrust vs rpm is changing due to air temperature or pressure difference from the calibrated response (outside of the scope of ESC's rpm controller).

Alex

@dan-jennings , I would be happy to help you with the Hadron Issues on newer SDKs. There were no changes to the Hadron (Boson + OV64B) functionaliy recently.

Please make a new post for this issue and provide the following details:

• which SDK is working and which SDK(s) are not working for Hadron
• detailed description of the issue, any useful info from camera server or dmesg?
• how is Hadron connected to VOXL2? which interposers and which VOXL2 camera port (J6, J7, or J8)
• please provide voxl-camera-server.conf that you are using
• please provide a list of sensormodule.bin and *so files in /usr/lib/camera

Thank you

Alex

@jbiscan21 , can you also share the esc params that you uploaded to the ESC after ESC calibration ? I am assuming you went through this procedure : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md

From the log I see that all 4 motors spun up but the rpm is capped at about 2200 rpm, which may mean you ESC tuning params are incorrect.

Also note that after arming, your drone immediately commands about 10000 rpm, which is not great, because that would be a sudden jump.. you may want to check your flight mode to avoid this.

Yes, I believe the system image v1.8.08 has all the above changes built applied. Easy way to confirm

• voxl-camera-server -l and check the printed min gain. it should be 100 not 54. if you see 100, then you have the latest com.quite.tuned.default.bin
• exposure control improvements should also be in there as of v1.8.05 (com.qti.sensor.ar0144.so). this is harder to test, but sdk 1.6.5 should have the latest. To test, cover up the camera to drive the exposure and gain to the max and then uncover and you should observe smooth transition, no jumps in image brightness.

it looks like we are not shipping com.qti.sensormodule.ar0144_fsin_3.bin in the system image right now, but like i mentioned earlier we are moving towards putting the camera drivers into the voxl-camera-server repository.. but for now you will need to manually copy that one.

Alex

example of voxl-px4 driver output when running voxl-px4 -d:

...
Starting VOXL ESC driver
INFO  [qshell] Send cmd: 'voxl_esc start'
INFO  [muorb] [uORB] Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [muorb] [qshell] qshell gotten: voxl_esc start
INFO  [muorb] [qshell]   arg0 = 'voxl_esc'
INFO  [muorb] [qshell]   arg1 = 'start'
INFO  [uORB] Advertising remote topic actuator_outputs
INFO  [muorb] [voxl_esc] Starting VOXL ESC driver
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_CONFIG: 1
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_MODE: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_BAUD: 2000000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_FUNC1: 102
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_FUNC2: 103
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_FUNC3: 101
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_FUNC4: 104
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_SDIR1: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_SDIR2: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_SDIR3: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_SDIR4: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_PWR_MIN: 0.050000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_RPM_MIN: 2000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_RPM_MAX: 12000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_PERC: 90
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_DEAD: 20
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_EXPO: 35
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_MINF: 0.150000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_COSP: 0.990000
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_VLOG: 1
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_PUB_BST: 1
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_WARN: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_T_OVER: 0
INFO  [muorb] [voxl_esc] Params: GPIO_CTL_CH: 0
INFO  [muorb] [voxl_esc] Params: VOXL_ESC_CMD: 0
INFO  [muorb] [qshell] Ok executing command: voxl_esc start
INFO  [muorb] [voxl_esc] Opening UART ESC device 2, baud rate 2000000
INFO  [muorb] [voxl_esc] Successfully opened UART ESC device
INFO  [muorb] [voxl_esc] Detecting ESCs...
INFO  [muorb] [voxl_esc] 	ESC ID     : 0
INFO  [muorb] [voxl_esc] 	Board Type : 40: ModalAi 4-in-1 ESC (M0129-3)
INFO  [muorb] [voxl_esc] 	Unique ID  : 0x2039333557555313000F0036
INFO  [muorb] [voxl_esc] 	Firmware   : version   39, hash 9c6233d6
INFO  [muorb] [voxl_esc] 	Bootloader : version  184, hash 10bf24c8
INFO  [muorb] [voxl_esc] 	Reply time : 735us
INFO  [muorb] [voxl_esc] VOXL_ESC:
INFO  [muorb] [voxl_esc] 	ESC ID     : 1
INFO  [muorb] [voxl_esc] 	Board Type : 40: ModalAi 4-in-1 ESC (M0129-3)
INFO  [muorb] [voxl_esc] 	Unique ID  : 0x2039333557555313000F0032
INFO  [muorb] [voxl_esc] 	Firmware   : version   39, hash 9c6233d6
INFO  [muorb] [voxl_esc] 	Bootloader : version  184, hash 10bf24c8
INFO  [muorb] [voxl_esc] 	Reply time : 721us
INFO  [muorb] [voxl_esc] VOXL_ESC:
INFO  [muorb] [voxl_esc] 	ESC ID     : 2
INFO  [muorb] [voxl_esc] 	Board Type : 40: ModalAi 4-in-1 ESC (M0129-3)
INFO  [muorb] [voxl_esc] 	Unique ID  : 0x2039333557555313000F0034
INFO  [muorb] [voxl_esc] 	Firmware   : version   39, hash 9c6233d6
INFO  [muorb] [voxl_esc] 	Bootloader : version  184, hash 10bf24c8
INFO  [muorb] [voxl_esc] 	Reply time : 104us
INFO  [muorb] [voxl_esc] VOXL_ESC:
INFO  [muorb] [voxl_esc] 	ESC ID     : 3
INFO  [muorb] [voxl_esc] 	Board Type : 40: ModalAi 4-in-1 ESC (M0129-3)
INFO  [muorb] [voxl_esc] 	Unique ID  : 0x2039333557555313000F0038
INFO  [muorb] [voxl_esc] 	Firmware   : version   39, hash 9c6233d6
INFO  [muorb] [voxl_esc] 	Bootloader : version  184, hash 10bf24c8
INFO  [muorb] [voxl_esc] 	Reply time : 727us
INFO  [muorb] [voxl_esc] VOXL_ESC:
INFO  [muorb] [voxl_esc] Use extended rpm packet : 1
INFO  [muorb] [voxl_esc] All ESCs successfully detected
...

@jbiscan21 , have you tried the actuator test feature in QGC? make sure to remove propellers for safety.

Also, as px4 starts up, the voxl-esc px4 driver will detect the ESCs and print some information, similar to what the CLI tool does without PX4. You can run voxl-px4 in foreground and check. voxl-px4 -d

Alex

Hi @srydell , you should use hobby / fpv quadcopters to get started with learning how to fly quadcopters. Most of them are flown very similarly to Starling 2 Max and you should at least master the angle + thrust control mode (roll, pitch, yaw angle an thrust as the 4 controls / sticks). More advanced (acro) mode would require controlling angular rates + thrust, which is for expert flyers and is not needed. Position mode (x,y,z position and yaw) is the easiest but would require some kind of positioning system (gps or VIO, etc), but that is the easiest to learn, since if you just let go of the control sticks, the vehicle will remain in place.

Learning to fly in angle + thrust mode is most useful and it will also let you better understand the vehicle's flight dynamics.

We do not have suggested options for what to buy for flight practice, but you should probably buy something that uses BetaFlight as the flight controller (very popular on fpv drones), but avoid aggressive racing drones -- it is better to start with something that is designed for smooth flight and filming rather than racing.

Alex

Hi @dinesh-varun-kandiyappan ,

Please see follow up responses

1. If your IMX412 camera fails fisheye calibration, this is probably because the lens is not actually a fisheye. Please see the following post regarding a recent lens change : https://forum.modalai.com/topic/5321/imx412-m12-lens-difference

• the new lens is rectilinear, so you should use the non-fisheye (plumb bob) model

The branch that saves the TOF calibration to a file is this one : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/tree/save-tof-v2-lens-cal . Sorry, we have not mainlined it yet. i will see if we can do that in the near future. see relevant post : https://forum.modalai.com/topic/5054/where-to-find-the-tof-and-hires-sensors-calibration

3. You may consider replacing your lens on IMX412 from the narrow one you have to a wider lens. We have the wide ones in stock and can get you a custom order if needed. Then you will see more features. The fisheye lens is about 30 degrees wider (horizontal FOV) than the non-fisheye.

4. VIO Features - maybe worth starting a separate post because it could be a long discussion and we could focus on that. Maybe make a new post with more details and we can get more folks on our team involved to look into it.

5.0 . PX4 params for Starling 2.. it looks like you may be correct.. double checking..

7.0 . We are testing Open Vins with rolling shutter cameras, let's discuss in another thread (see above).

8.0 . I don't think we have substantial updates to voxl-tflite-server.. will check.. and yes, qrb5165 is getting relatively old, so support for newer models can be difficult to get.

9.0 . If you are going to load up the cpu / gpu substantially, then a fan / heat spreader is needed. In general this is true for many mobile SoCs - they are powerful and efficient, but cannot sustain running at high utilization for long -- even phones can overheat and employ thermal throttling. My suggestion is to build up features / components one at a time and check your cpu / gpu utilization and thermal. Sometimes inefficient implementation of one component can overheat the whole system. also important to keep track of what resolution images you are using and make sure that you are not sending uncompressed images across regular (non-ION) pipes between processes..

10. before putting the second VOXL2 on the drone, you should proof everything on the bench. Starling 2 could certainly fit an extra VOXL2 mini. We don't have any official dates for VOXL3 yet, so it's best to focus on VOXL2. I will see if there is any info about VOXL3 we could share right now in terms of supporting newer inference models.

11. Can you please clarify what you mean by control policy? At what level are you training the control model (inputs and outputs?).

Hi @markmst ,
please see the following changelog for the AR0144 camera driver and the default tuning file. You can reference the system image versions here : https://docs.modalai.com/sdk-1.6-release-notes/

v1.8.06, v1.8.08, v1.8.09

• fix the min gain in default tuning file from 54 to 100. Even if you specify min gain of 54 in voxl-camera-server config, it will get corrected to 100 (so, no issue). this change is going to be in com.qti.tuned.default.bin

v1.8.05

• improve AR0144 exposure control to make it smoother (compensate with digital gain for the fact that AR0144 analog gain steps are not linear. This change actually lives in the com.qti.sensor.ar0144.so file.
• fix an issue where the max value (saturated pixel value) would be a function of the analog gain (would vary between 224 and 255)

By the way, it looks like we are going to move towards maintaining the camera drivers in the camera server repo so that we can update them much quicker and not require the system image update.

Can you tell me which AR0144 drivers you have been using? (where they came from). I can commit the latest to the camera server repo for convenience.

Alex