Posts made by msberk

@Inhan-Kang Did you ever resolve this issue? We may have a similar one. Ruled out power issues already by running straight off a powerful 5V supply. It does not reboot though, just goes dark and stops responding over ADB or over the network (we are using Doodle).

@Alex-Kushleyev Thanks! This is helpful. Definitely easier to overheat these than the last gen so good to have the specs on it.

@Alex-Kushleyev just learned you cannot set the exposure max to 1200. 1000 and 1500 work. If you set it to 1200 you get a vague IO error

ERROR:   [ERROR] in _sensor_ioctl, ioctl failed: Connection timed out
ERROR:   [ERROR] in voxl_cci_read, Failed ioctl call
ERROR:   Failed CCI read

Just posting this here as an FYI to other wrestling with these new sensors.

@Alex-Kushleyev Thanks so much for your help. If 1200us was the V1 level we may just set it to that and move forward, making something that works at the previous level with minimal surgery to the drone is our shortest path to success at the moment.

@Alex-Kushleyev It seems to be behaving at present. I picked 2000us since it seemed to give similar performance to the previous sensor. I'm going to try installing the "regular" 1.9.4 with the updated ae_msv setting and run that debug/grep again and make sure the setting is being respected. If so I may be ok, and just had something weird happen earlier since it was running on the bench for a while. What do y'all run on the starling 2 for max exposure? 6000 seemed practically unusable unless very actively cooled and we toasted a couple of these seemingly irrecoverably at that setting when we had them in the enclosure like the old sensors.

Edit: running with default 1.9.4 and the correct settings in conf and it seems to respect 2000us limit. Also, to answer your temp question yes going from 6000 to 2000 made a huge difference in qualitative temperatures.

@Alex-Kushleyev It is M0169, we have yet to see M0171 go up for sale on the store or beta store, but would love some since the wire interface is clunky.

@Alex-Kushleyev Ah, right, sorry. 5V going to the power wires of the two ToF sensors.

@Alex-Kushleyev I will get the screenshots in a moment. lme_msv wasn't set and I noticed that power usage wasn't going down and figured there was just a bug in the config-reading code, so I recompiled with the default exposure value in the #DEFINE AE_{HIST,MSV}_DEFAULTS_TOF_LIOW2 overridden to 2000us and a printf inside the code chunk which sets it confirming that 2000 was being sent, so I am confident it was decreased. Good to know that setting lme_msv will get it to respect the exposure_max_us, that was pretty unclear.

Changes:

diff --git a/src/config_defaults.cpp b/src/config_defaults.cpp
index 096ff48..33c5a2e 100644
--- a/src/config_defaults.cpp
+++ b/src/config_defaults.cpp
@@ -223,7 +223,7 @@
     0,   \
     0,  \
     0,   \
-    6000,\
+    2000,\
     0, \
     0.0, \
     0.0, \
(END)

FPS is set to 5.

And here's another where one of the sensors is given a longer range to ping over:

@Alex-Kushleyev We've also been playing with these sensors, and installed aluminum heat spreaders and even decreased exposure_max_us to 2000 and we are burning up the beta sensors regularly (get overheat warnings, and then eventually they stop drawing power and we only get sporadic "flashes" on the depth returns). We've been running at 5V. We're now almost out of sensors, and out of patience. I see you now have them in the Starling 2 - could you advise on how you have it set up there to avoid these overheating failures?

Edit: we don't have a fan or airflow over these, and our design is nominally water resistant which doesn't permit us to put these in an area with flow from the rotors. We have a fan drawing air over the VOXL itself internally but the previous gen ToF had absolutely no issue with being mounted away from air flow and working reliably. I am looking for a solution which permits that. Extended range is useless to me if the sensors die on the ground.

@Moderator Thanks for the update and the datasheet. I have not tried building the code since I don't have a reason to until the module itself becomes available and hopefully the code will be out of beta by then. Is there an updated timeline on when this module and its adapters are likely to hit the store?

@Eric-Katzfey Thanks for the update, we are anxiously awaiting the data and even more the release of the replacement sensor!

@Moderator Following up on this, are there any updates on this sensor? We completed a prototype that relies on the last-gen sensor in the fall and this limbo has hung us up on moving forward, or even making additional prototypes due to lack of availability. We're now a couple weeks into 2024 without updates and I'm getting concerned about the fragility of the Modal AI supply chain unless a good roadmap can be provided.

All,

We are interested in procuring 2 extra M0040 ToF sensors, and are reaching out to the community since they are not currently available new. If you have old, fully functional stock that you would like to sell, please send me a message at apparel_bismuth0v@icloud.com

Thanks

We have developed a custom MPA server to read from our own external serial sensor and output a point cloud stream through MPA. If we start voxl-vision-hub, voxl-inspect-points, or open Voxl Portal to the sensor page first, then it works as expected. However, if we start our custom server first then begin any of those clients, they do not connect.

Unfortunately we can't share the code here but we followed the normal MPA server opening procedure seen in voxl-camera-server and can't find any differences in our setup and run. Have you seen this issue before and have a suggestion as to a direction we could go for debugging?

Thanks

@Moderator Thanks for the clarification, we will not expect a solution to this then.

@modaltb

Hi there, just checking in if there have been any updates to this and whether the USBC port can be used for connecting peripherals. We have multiple USB devices and this would greatly simplify our integration.

Thanks

Was searching around for info on this and found from ~6mos ago: Re: Redundant VIO via AprilTags?

Are there any status updates on this? @Evan-Hertafeld's idea of configuring two simultaneous VIO services is something we've been considering over here, in addition to other redundant feature based localization solutions. Alternately, have you run EKF-SLAM or similar onboard the VOXL or just made maps based on VIO position and voxblox as implied in this article?

Am I correct that the new ESC mini could be used with the original VOXL 2 if the correct wiring harness would be made? The extra camera lanes of the original VOXL 2 are nice for some of our applications, but being able to consolidate the ESC and power module together would be a great SWaP win even with the original VOXL 2.

Thanks

@Eric-Katzfey
Ok, that worked. Thanks!

How would you advise setting it up to run at boot? I found the target script here but it's set up differently than a typical Pixhawk board target.

Note, this is exact issue is referenced here and never answered, but we have also run into it:

While testing we had the voxl2 mounted with an 180 degrees roll. We were able to change the extrinsics file for qvio, and vision-px4, but when calibrating the sensors with QGroundcontrol the system was unable to calibrate, because the px4 could not discern the right orientation it was in. The px4 was configures to have a roll of 180 degrees, and when calibrating the sensors while the drone was standing on the ground, px4 still thought it was upside down, and after trying to calibrate that orientation, it gave an error saying the z readout was in the wrong direction. Is it possible that there is a setting on the voxl2 that needs to be set when the voxl is mounted upside down?