@Dan-Jennings Honestly, I don't think updating the SDK version will help this issue. But, we highly encourage everyone to be on the latest SDK, regardless, since that's where you'll get the latest fixes and features. And it's how you'll get the best support from us. but in this case I don't think a newer SDK will get you the battery_status. It's probably a hardware issue or a parameter issue. You swapped boards and that didn't help. What about the cable? Those 4 wire cables are notoriously fragile. Can you swap it out and see if that helps? The other item is parameters. You saw that other post about setting BATT_MONITOR to 21 and BATT_I2C_BUS to 1. If you don't see the BATT_I2C_BUS parameter then it must mean that BATT_MONITOR hasn't been set to 21. Make sure it is set to 21, then reboot, then you should see the BATT_I2C_BUS parameter. Then set it to 1, reboot, then you should see correct battery_status.

@DronAlan
Hi there, the configuration & extrinsics files look fine (just switch offboard mode from figure_eight back to trajectory mode. Since you confirmed figure 8 and position mode are working fine and reflect true ground truth in voxl portal, next is to dive a bit deep into the processes:

Just to confirm: are you using a loaded saved map? Orientation can be different in a loaded maps based on how it was saved. Going forward in debugging this I would create the map while flying, then test plan-to-point to ensure it is working properly.

• Before take off, if you ssh onto the drone and run voxl-vision-hub --debug_offboard and rerun the mapping test (point 1m in front of the drone hovering), and you don't need to map the entire room, just get the general area.
• In the ssh session, monitor the output from voxl-vision-hub.
• Take off and fly forward and backward in position mode, with some slight yaw motions to generate a decent map in voxl portal (recall we're generating a map in flight then plan to fly to a point, not using a old-saved map).
• Then switch into trajectory mode. In the ssh session, you should get a Received trajectory has duration message printed.
• Goto voxl-portal and plan-a-point. Then execute go-to-point. In the ssh session you should get a Received insert command. printed out on the terminal. And it will show the drone's forward commands, i..e set points, to your planned point. I expect the commanding: XYZ values to increase in the positive X direction. Please post the output of the ssh session here.

If the drone moves in the backwards direction as you've been seeing but the commanding XYZs are moving forward, we have found our problem (PX4 issue such that I'll need your params file). If the drone moves forward with commanding XYZs are moving forward then it's how your older maps are being saved and we can go from there.

OK @Daehan-Won
Yeah, I'd try to run one first on it's own before the hub to rule that out.
Keep us posted.
Thanks!

@Daehan-Won You would need to add the support to PX4 since you are using the DSP I2C pins and only PX4 can access those while it is running. There is some useful developer documentation here: https://docs.modalai.com/voxl-px4-dev-build-guide/. Also visit the PX4 documentation as well. At a high level you'll need to fork our repo, make a branch off of voxl-dev, add the driver to the default.px4board file for voxl2-slpi, build the image, and add a start command into the startup script voxl-px4-start

Hi @Daehan-Won
So, on the M0062 debug board, you do not need to connect an extra hub. You already have 3 USB ports...
Look at J10, J11, and J12..
https://docs.modalai.com/m0062-datasheet/#connector-callouts
Yes they are different connectors, but is a much easier system for you. We sell both 4 and 10-pin USB cables, and you can easily get Type-A breakouts from Adafruit or Digikey.
Can you try to remove the extra hub and see if you can get your system to work that way?

We cannot validate or debug third party hardware/modules ... we would only be guessing and do not want to lead you down the wrong path. However, I suspect in this case, that Hub is indeed your issue. It is most likely only supporting 500mA modes, and if neither of those two devices are enumerating perfectly, it may only allow 100mA per port before tripping a reset. Depends on how it is configured and designed.
You can use USB TreeView to read all the descriptors of that hub board, and look for the self vs bus powered reporting, and the downstream current allocations. I suspect this is not set for your system.
If you use our connectors, despite in various formats, you should be much better off.

Lastly, just to clarify, are your USB connections unique? Your drawing looks like they are the same USBD+/D- wires connecting to one port of the Hub.

Hi @Jetson-Nano
The connectors between VOXL 2 and M0173 are DF40's. They are rated for 30 cycles:

The uCoax image sensor cables are also from Hirose, and are much more fragile. They are rated for 20 cycles, but to be honest, I break them after 3-5 cycles personally if I am not using a tool. With the use of the proper tool we specify here, you should get to 10-20 cycles.
https://docs.modalai.com/micro-coax-user-guide/

FCv2 uses a bunch of JST GH connectors. On the flip side, I've never broken one of those!
JST sadly does not specify the cycle count. So, any number we provide would be a guess. We use it due to DroneCode compliance intentions. They are pretty robust and never experienced any issues.

Hope this helps.

@minhthinh The params are in our voxl-px4-params repo. For example: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-px4-params/-/blob/master/params/v1.13/Platforms/M500_FCV2.params?ref_type=heads

Hi @austin-c
Sorry I missed this message somehow.
I will email you to kick this off with your team.

Hi @irw
Can you please post High Res and clear photos of both sides of the VOXL 2?

Hi there, just to confirm: does flying manually in position mode work and follows the XYZ position in voxl-portal's VIO page. as well as follows figure 8 mode too? This will confirm the vio pose estimate is correct and more of a issue on mapper.