# Fixed pose via /run/mpa/vvhub_fixed_pose_input in addion to Open Vins

Source: https://forum.modalai.com/topic/5009/fixed-pose-via-run-mpa-vvhub_fixed_pose_input-in-addion-to-open-vins
Category: VOXL SDK and Software (https://forum.modalai.com/category/47/voxl-sdk-and-software)
Tags: mpa
Posted: 2026-01-26 08:20:46 UTC by jacob yaacubov
Replies: 1 · Views: 1599

## jacob yaacubov · 2026-01-26 08:20:46 UTC

Hi guys, 

We were using SDK 1.1.3, where we used the **QVIO+ our pos fix (Only Z axis)** to fly, so in addition to QVIO also used our own nav stack. Our fixed position was sent via a pipe to the modalai VISION-HUB 
we sent the fix pose 
to the

 ```/run/mpa/vvhub_fixed_pose_input```

it wokred well we flew hundreds of times with this setup were we publish to the fix pose pipe, fix the position of the drone and remove accumulated drift by the QVIO 

in the vision-hub .conf we have: 
 set the  **fixed_frame_filter_len: 1** -  cause we usually fix the position once in few seconds using tags. 
set the **en_transform_mavlink_pos_setpoints_from_fixed_frame: true** 

But now, after using the new DK 1.4.0 and using OPEN VINS + our fix  it still works but occasionally our drone crashes we investigated and seems this fix might be responsible (we doubled check  THE VALUES they were good )

1. does the Open vins works well  when we also publish  to the /run/mpa/vvhub_fixed_pose_input?
2. any major changes to VISION-HUB that could make its buffer full or something  or race with conflicting positions between the fixed pipe and local pipe from open vins that can cause it maybe take an old fix of ours ? 
We had this warning which might be related to crash   
Thanks!

```
Jan 07 17:29:36 BALD voxl-open-vins-server[17387]: INFO: MAYBE ON GROUND, POSITION LOCK? -- INVOKE ESTOP! (This is just a warning) 0.000000 0.000000 -15.208726
Jan 07 17:29:36 BALD voxl-open-vins-server[17387]: INFO: MAYBE ON GROUND, POSITION LOCK? -- INVOKE ESTOP! (This is just a warning) 0.000000 0.000000 -15.208766
Jan 07 17:29:36 BALD voxl-open-vins-server[17387]: INFO: MAYBE ON GROUND, POSITION LOCK? -- INVOKE ESTOP! (This is just a warning) 0.000000 0.000000 -15.208140
Jan 07 17:29:36 BALD voxl-open-vins-server[17387]: INFO: MAYBE ON GROUND, POSITION LOCK? -- INVOKE ESTOP! (This is just a warning) 0.000000 0.000000 -15.206414
Jan 07 17:29:36 BALD voxl-open-vins-server[17387]: INFO: MAYBE ON GROUND, POSITION LOCK? -- INVOKE ESTOP! (This is just a warning) 0.000000 0.000000 -15.202729
Jan 07 17:29:36 BALD voxl-open-vins-server[17387]: INFO: MAYBE ON GROUND, POSITION LOCK? -- INVOKE ESTOP! (This is just a warning) 0.000000 0.000000 -15.197531
```

## Reply by Cliff Wong (ModalAI staff) · 2026-01-26 19:27:12 UTC

Hi there, I would highly recommend upgrading to the latest SDK 1.6.2.

Q1: For voxl-vision-hub, openvins is just another [abstracted] VIO client, using the same MPA interface as QVIO. Thus, should work the same as QVIO.
Q2: There are no outstanding buffer conflicts between the 2 inputs in that SDK version. Though best to update to 1.6.2 as there have been numerous MPA improvements.

Q3: ```MAYBE ON GROUND, POSITION LOCK?``` is reporting that the barometer is reporting <1m and OVINS > 1m (-1 in NED space). It appears OVINS had a blow up, has recovered with a new origin in the local frame. Your output says it must have reseted in the ai/flying and hence the new local origin is above your landing point (fixed frame). Depending how you have PX4's EKF setup could lead to issues like the landing detector not working, or position error when running missions, hence why it's reported as a warning. Your output says it's at 0,0,-15 indicating OVINS restarted at ~15m up, but the PX4 baro says it's at 0. If outdoors, I recommend setting ```EKF2_HGT_REF = baro```, if indoors, you'll need to reconcile a origin offset if VIO resets midair (qvio would require this as well) if using vio data directly waypoint manager (i.e. offboard waypoint mode or custom nav code)

Going forward if staying with 1.4.x, 
1. edit ```/etc/modalai/voxl-open-vins-server.conf``` and change:
```"en_vio_always_on":	true,```
2. ssh into the drone and run ```voxl-vision-hub --debug_fixed_frame --debug_tag_cam --debug_odometry``` to compare values and see if there is a error in calculation possibly causing vision-hub to restart.
3. move the drone around by hand, point it at a tag as needed and monitor the output from vision-hub. Should tell you where a possible conflict arises.