ModalAI Forum

Alex Kushleyev

Please take a look at the ESC firmware changelog:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/firmware/FIRMWARE_CHANGELOG.md

support for the M0138 FPV ESC has been added in firmware V39 RC10, which is likely what you received (i assume the ESC is reasonably old, since we are now shipping with latest firmware)
please note that only starting version V39.15, the ESC firmware sends back the exact version in format Vxy.ab -- so 39.00 could mean 39.10-39.15
also note that the firmware hash that you have (e4f576a0) is not listed in our firmware changelog, but it is essentially the V39 RC10 release (39.10).

We will look into the changes. To help with this, are you able to share the approximate motor specs? (motor kv and what supply voltage you are using)? We can try to replicate.

Are you able to test the firmware from this release and tell me how it behaves? https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/tree/366d652e3680bb769d87dfca94f76b226481a6db/voxl-esc-tools/firmware . Initially we had a few releases that were not documented in the changelog (v0_39_RC10_a7f0bccb)

Thank you

Alex

Vinny

Hi @dakota_ltu Under an NDA we could consider the ESC. However, even under NDA, we cannot share the VOXL 2 Schematics unless the recipient is also a Qualcomm licensee with their own NDA with Qualcomm.
If that is still a path with value to you, please use this form: https://www.modalai.com/pages/contact-us

Alex Kushleyev

@sebastianp , sorry for the delay. There a lots of questions, let me start with what I can answer right away and will go from there.

Hires Video

Resolution:

Starling 2 Max comes with dual IMX412 cameras (front, down-facing). IMX412 maximum resolution is 4056x3040, which is larger than 4K. 8K is not supported on Starling Max. In general, we do have support for one 8K camera (OV64B), which has maximum resolution of 9248x6944 and that resolution is supported only at 10FPS. The only way to get that camera right now is part of a Flir Hadron combo (Boson + Color camera), which is probably not what you are looking for. So the best bet for Starling 2 Max is to use the provided IMX412 camera.
you can see some details regarding operating modes of IMX412 camera here : https://docs.modalai.com/camera-video/low-latency-video-streaming/#imx412-operating-modes

Data Pipeline:

our camera server application (voxl-camera-server) can publish processed YUV images via shared ION buffers (zero copy) and the user application can receive those buffers for processing without any cpu overhead for doing inter process communication to send the image data.
you can also publish raw Bayer data (the exact data that comes from the camera) if that's what you mean by "raw"

Optics:

no optical zoom is supported on any of our cameras, only digital

Onboard AI Compute and Performance

I will need to check with colleagues and follow up.

Flight Range, Autonomy & Control

Starling 2 Max used PX4 as flight controller, so all the standard flight modes are supported

Answers to additional questions

Camera and Zoom integration: yes, raw and yuv frames can be shared with customer's C/C++ applications via shared buffers (or regular buffers via named pipes, which will have a lot of overhead for duplicating the data). No optical zoom is supported. Examples are available upon request
We provide voxl-cross docker image which can be used to build the projects for VOXL2. Majority of ModalAI packages that run on VOXL2 are built using this cross-complier environment and can serve as examples how to build your own applications (you can find most packages here : https://gitlab.com/voxl-public/voxl-sdk)
you can mount more hardware on Starling 2 Max, see the following thread regarding flight time : https://forum.modalai.com/topic/3732/starling-2-max-payload-capacity-and-flight-time-impact

Frequency selection

when you configure your starling 2 max (https://www.modalai.com/products/starling-2-max) , you can select several options and the SKU will change accordingly. The page also has explanation for the different SKU options, so it sounds like you will need:
MRB-D0012-4-V4-C28-M11-T9-K2
C28 : dual tracking and dual hi-res cameras
M11-T9 : Microhard and Microhard pMDDL2450 and Ghost Atto (2.4Ghz)
it seems that this would be a custom SKU that you would need to request a quote for : https://www.modalai.com/pages/contact-us

Ground Controller:

If the drone ships with an RC transmitter, it should be already bound to the receiver.
the controller and receive depends on the selection, see above regarding SKU and the shop page for more description
note that the RC controller has no ability to display video, so there is no out-of-the-box ability to stream video without additional setup, such as external computer, display / goggles, etc.

I hope that answered a lot of your questions, please let us know additional questions or need clarification regarding anything else.

Alex

Eric Katzfey

The Commando 8 user manual is available online

Eric Katzfey

Did you do a short press followed by a long press?

zauberflote1

Hello there,

@RoyAzriel said:

2d Lidar 50gram above the gps bridge
2 x light ilumination (front, down - we are flying and dark tunnels next to tracking cameras)
props guards the are seen by the tracking camera
we have added tof camera, moving from C28 to C29 ( currently its not working or wired in sw), we have changed the extrinsix.conf file in /etc/modalai accordingly.
all of those changes did not effect our filght and we had good flight with good vio during the flight

If the platform we are discussing has this added elements, it is a custom frame.

@RoyAzriel said:

we are exploting a tunnel for the first time.we use the poshold durung junction turns to hold in place during turbolance. my answer would be we can live with resets assuming we can accumulate the positions for mapping between the resets.

Yes, so that is a mapping/loop closure software responsibility, not VIO.

@RoyAzriel said:

how do we make sure what you are saying is right and we are passing estimates to px4 ?

Check your voxl-vision-hub.conf, if en_vio is set to true, it passes to PX4 as external vision estimates. Also rectified by:

@RoyAzriel said:

HGT_REF=3 //VIO
EKF2_EV_QMIN=16
EKF2_EV_CTRL=15

For now, our PX4 flavour doesn't handle VIO resets gracefully always. We currently have overcome this issue by using VFC. Hence, the reason I suggested that you should try to repeat the same maneuver under VFC position. If you have any questions on how to enable VFC, please feel free to ask.

@RoyAzriel said:

what should I expect ?

Likely more robust performance under resets at the potential cost of manually hover thrust, PID/PD tuning.

PS: I wanted to try reproducing your setup here with non-modded Starling2 Max, but I am unable to match your setup without logs

Eric Katzfey

What if you disconnect Mission Planner before trying the voxl-ardupilot restart?

Eric Katzfey

Can you try upgrading to the latest VOXL SDK to see if that helps?

Eric Katzfey

I do not have a Windows computer handy so cannot really try Mission Planner. I tried to recreate this with QGroundControl but don't see it. Can you try with QGroundControl just to see what happens? Does it look like the 'systemctl restart voxl-ardupilot' is working reliably?

zauberflote1

@RoyAzriel Hello there,

This goes back a bit to my first question, but let's break it down systematically:

Do you need VIO estimates to be always continuos or reset jumps are okay?
If you need VIO during takeoff and your application is not robust to SFM resets (potential jump discontinuity), I recommend never using dynamic init and warm reset

Back to what you reported

"still sometimes it fails to converge. Can you recomend what is the best sequence one should do to get convergence in high precentage after power cycle ?"

Convergence for a initialization would usually refer to a dynamic initialization (nonlinear optimization), as the static initialization does not involve optimization. That being said, some static inits can be bad as soon as the platform is in the air: noisy ZUPT updates, bad IMU calibration and sigma/random-walk values. This is natural under custom frame mods, perhaps a full IMU intrinsics recalibration could help.

Nevertheless, it seems that you're running VIO by passing estimates to PX4, instead of using VFC Position (Local Controller with VIO estimates that send just setpoints to PX4). I am personally curious if the issues you're having are related to the PX4 integration with VIO estimates or if it's truly pure VIO estimates.

Experimental Attempt

Please try:

voxl-configure-vision-hub factory_enable_vfc_starling

In the voxl-vision-hub.conf, make sure you verify your hover thrust value and the offboard_mode key is set to vfc
Make sure you change your Position flight mode switch to offboard in PX4
Set a Kill switch in PX4 -- this is an experimental attempt, and you might have to tune the PID/PD values in vfc.conf

If you have logs to share, please feel free to send them.

Q: What is your EV_q (quality minimum) in PX4? Also what your HGT ref?

PS: We are bringing up better VIO debug tools for users, so stay tuned for updates as well.

All the best, ZBFT (Joao Leonardo Silva Cotta)

ModalAI Forum

ModalAI Team

Posts

Experimental Attempt

Member List