@Alex-Kushleyev understood,

Thanks again I will give this a try - fingers crossed

@Alex-Kushleyev We're using the "hires_front" camera on the Starling 2 Max. I don't know exactly what type of camera (hardware-wise) is on the drone, nor how to find that information, but this is the current configuration for that camera in the voxl-camera-server.conf file:

{ "type": "imx412", "name": "hires_front", "enabled": true, "camera_id": 1, "fps": 30, "en_preview": false, "preview_width": 640, "preview_height": 480, "en_raw_preview": false, "en_small_video": true, "small_video_width": 1024, "small_video_height": 768, "small_venc_mode": "h265", "small_venc_br_ctrl": "cqp", "small_venc_Qfixed": 30, "small_venc_Qmin": 15, "small_venc_Qmax": 40, "small_venc_nPframes": 9, "small_venc_mbps": 2, "en_large_video": false, "large_video_width": 4056, "large_video_height": 3040, "large_venc_mode": "h265", "large_venc_br_ctrl": "cqp", "large_venc_Qfixed": 38, "large_venc_Qmin": 15, "large_venc_Qmax": 50, "large_venc_nPframes": 29, "large_venc_mbps": 30, "en_snapshot": true, "en_snapshot_width": 4056, "en_snapshot_height": 3040, "exif_focal_length": 3.0999999046325684, "exif_focal_length_in_35mm_format": 17, "exif_fnumber": 1.2400000095367432, "ae_mode": "isp" }

Does that answer your question?

@Eric-Katzfey we were on 1.3.2, flashed 1.3.5 and had success!

@buem799 Yes, you would be able to use Seek. We do not currently support this, it's just some internal stuff we are using for Seek evaluation and development. Here is the contents of our Dockerfile, hopefully this is helpful to you.

FROM arm64v8/ubuntu:focal WORKDIR /home RUN apt-get update RUN DEBIAN_FRONTEND=noninteractive apt-get install -y cmake libopencv-dev libusb-1.0-0-dev RUN DEBIAN_FRONTEND=noninteractive apt-get install -y git RUN DEBIAN_FRONTEND=noninteractive apt-get install -y g++ vim # This will update if there have been any updates to the voxl-dev branch and force a new git clone # ADD https://api.github.com/repos/modalai/libseek-thermal/git/refs/heads/dev version.json RUN git clone https://github.com/modalai/libseek-thermal.git RUN mkdir libseek-thermal/build WORKDIR /home/libseek-thermal/build RUN cmake .. RUN make RUN make install RUN ldconfig WORKDIR /home COPY Seek_Thermal_SDK_4.4.2.20.zip . RUN DEBIAN_FRONTEND=noninteractive apt-get install -y zip RUN unzip Seek_Thermal_SDK_4.4.2.20.zip RUN rm Seek_Thermal_SDK_4.4.2.20.zip RUN DEBIAN_FRONTEND=noninteractive apt-get install -y libsdl2-dev WORKDIR /home/Seek_Thermal_SDK_4.4.2.20/aarch64-linux-gnu RUN DEBIAN_FRONTEND=noninteractive apt-get install -y usbutils RUN DEBIAN_FRONTEND=noninteractive apt-get install -y udev RUN cp lib/libseekcamera.so /usr/local/lib RUN cp -r include/* /usr/local/include RUN mkdir -p /etc/udev RUN cp driver/udev/10-seekthermal.rules /etc/udev/rules.d # RUN udevadm control --reload RUN chmod a+x bin/* WORKDIR /home/Seek_Thermal_SDK_4.4.2.20/aarch64-linux-gnu/examples/build RUN cmake .. RUN make WORKDIR /home COPY libmodal-json*.deb . RUN dpkg -i libmodal-json*.deb RUN rm libmodal-json_*.deb COPY libmodal-pipe*.deb . RUN dpkg -i libmodal-pipe*.deb RUN rm libmodal-pipe*.deb ENV LD_LIBRARY_PATH=/usr/lib64 WORKDIR /usr/local/workspace

@Tamilselvan Correct, for example take a look at our UVC camera server: https://docs.modalai.com/voxl-uvc-server/

Hi @JANG
The only time a power module is damaged is when a power supply is used to power the system and the motors are spun up, creating a voltage spike on the input rail that exceeds 28V, not a battery. So, this overall is very surprising to me.
You are welcome to use any 5V source for FCv2. It does not need much power (maybe 1-2Amps total) so our power module is overkill for a FCv2, but it helps by providing current and voltage readings to to PX4 or you FC SW of choice.

@buem799 Yes, I think that one should work fine. But there's probably a bunch of configuration options for the receiver so you have to make sure that it has been setup properly to do CRSF.

Hi @serviceberry
From a HW viewpoint (I am HW team) that sounds reasonable to use the hub the way you suggest. But I know for a fact from personal experience the Boson's are very dependent on VBUS rise times, and a very fast rising 5V supply may not allow it to enumerate properly. We have had an instance in the past where one particular VBUS port rose really fast, and the Boson did not enumerate until we slowed it down. It's one of those situations that may require testing to check. Our J3 10-pin host port has a nice moderate rise time that allows Boson to enumerate. So, when using a Hub, check the VBUS rise times compared to J3.
I do NOT expect J9 USB-C OTG port to work with Boson.
The Snapdragon SOC is very smart, and when in OTG mode, it will not provide more than 500mA to any device that enumerates as USB2 which I am lead to believe how the Boson enumerates. if the Boson could enumerate as a USB3 device and the drivers were all present in the Kernel for this, the Snapdragon will give it 900mA over VBUS letting it boot but I think this is a non-starter without the Boson being able to do that.
Our Boson kits use USB2 only and we provide 1A support to enable them to work without requiring enumeration to negotiate more current, hence why they work on the J3 ports and other expansion board ports that have more than 500mA: https://docs.modalai.com/expansion-design-guide/#usb-expansion-over-j3--j5

Hi, thanks for your response!

I'm using a ModalAI development drone (Starling2), and to make the VIO less robust and test the auto-reset, I'm only using the tracking_front camera.

I have already set "init_dyn_use" = true and "en_force_init" = true.
However, whether "en_force_init" is set to true or false, the result is always the same: the system resets, but as soon as it restarts, it immediately begins to diverge, causing another reset shortly after, and so on. After a certain number of resets, it sometimes stops resetting and continues to diverge indefinitely.

The only way the reset works without the VIO diverging afterward is if the reset happens while the drone is placed on a stable surface.

This is my config file:

{ "en_auto_reset": true, "auto_reset_max_velocity": 20, "auto_reset_max_v_cov_instant": 0.10000000149011612, "auto_reset_max_v_cov": 0.10000000149011612, "auto_reset_max_v_cov_timeout_s": 0.5, "auto_reset_min_features": 1, "auto_reset_min_feature_timeout_s": 3, "auto_fallback_timeout_s": 3, "auto_fallback_min_v": 0.600000023841858, "en_cont_yaw_checks": false, "fast_yaw_thresh": 5, "fast_yaw_timeout_s": 1.75, "do_fej": true, "imu_avg": true, "use_rk4_integration": true, "cam_to_imu_refinement": true, "cam_intrins_refinement": true, "cam_imu_ts_refinement": true, "max_clone_size": 8, "max_slam_features": 35, "max_slam_in_update": 10, "max_msckf_in_update": 10, "feat_rep_msckf": 4, "feat_rep_slam": 4, "cam_imu_time_offset": 0, "slam_delay": 1, "gravity_mag": 9.80665, "init_window_time": 1, "init_imu_thresh": 1, "imu_sigma_w": 0.00013990944749616306, "imu_sigma_wb": 4.1189724174615527e-07, "imu_sigma_a": 0.0038947538150776763, "imu_sigma_ab": 5.538346201712153e-05, "msckf_chi2_multiplier": 0.65, "slam_chi2_multiplier": 40, "zupt_chi2_multiplier": 1, "msckf_sigma_px": 1, "slam_sigma_px": 1.8, "zupt_sigma_px": 1, "try_zupt": true, "zupt_max_velocity": 0.03, "zupt_only_at_beginning": true, "zupt_noise_multiplier": 1, "zupt_max_disparity": 8, "init_dyn_use": true, "triangulate_1d": false, "refine_features": false, "max_runs": 5, "init_lamda": 0.001, "max_lamda": 10000000000, "min_dx": 1e-06, "min_dcost": 1e-06, "lam_mult": 10, "min_dist": 0.1, "max_dist": 60, "max_baseline": 40, "max_cond_number": 600000, "use_mask": false, "use_stereo": false, "use_baro": false, "num_opencv_threads": 4, "fast_threshold": 10, "histogram_method": 1, "knn_ratio": 0.7, "takeoff_accel_threshold": 0.5, "takeoff_threshold": -0.1, "use_stats": false, "max_allowable_cep": 1, "en_force_init": true, "en_force_ned_2_flu": false, "track_frequency": 30, "publish_frequency": 15, "en_vio_always_on": true, "en_ext_feature_tracker": false, "en_gpu_for_tracking": true, "num_features_to_track": 30 }

Also, I am keeping "en_vio_always_on" = true because i am performing hand testing. But if i set it to false, the VIO never starts (from voxl-inspect-vins I see it is at 0,0,0 and the the portal I do not see any feature on ov_overlay if i move the drone).

Any suggestion? Thanks again!

@Zachary-Lowell-0 Thank you. I just tried using a different SDK version (1.1.2) instead of the one I was originally using (1.1.4) just to see if that would help, but I am still experiencing the same errors. My guess right now is that it is a problem with message definitions within the repository itself.

@Moderator Sorry, I forgot to mention VOXL Mapper by using the TOF Sensor. I found a table that states it will be supportet in the future: https://docs.modalai.com/M0178/?utm_source=chatgpt.com
Do you know when we can expect it ?

@wilkinsaf

A color AR0144 exists, but there is no current integration readily available

@Tamilselvan External flight controllers need to have a standard UART interface and Mavlink interface to use our VOXL SDK. Of course, the VOXL 2 is a development platform so you can change it as needed for many other use cases. In terms of WiFi, that is just an IP based network interface so yes, Mavlink based telemetry and RTSP video streaming both go over it.

@TomP GPS on pins 2 and 3 is mapped to serial port 3 in ArduPilot. The RC port on pins 10 and 11 is mapped to 4. https://github.com/ArduPilot/ardupilot/blob/d977f318c68faf69b8afa9b5c1afe73932a1d946/libraries/AP_HAL_QURT/HAL_QURT_Class.cpp#L50

@paul-ammer If you aren't doing any VIO related flight you can disable voxl-qvio-server and voxl-imu-server. I believe you may still need voxl-vision-hub if you're communicating with a ground control station but not 100% positive on that, voxl-mavlink-server may be enough.