@Jimk_Aero Sorry so hear that you're still having problems. The built-in BEC shouldn't be required for basic use case. Unless you're trying to power some other on-board electronics/avionics with the BEC. All you should need is the "power in" to all 4 esc's from a PDB and then signal and ground from esc's to flight core J7, via the breakout board. Modalai's breakout board was designed for PWM signals only and works well in that regard. Also check to make sure that DSHOT_CONFIG is set to "disable" Here's some notes from our board designer to clarify. The primary design intent was to be used with a distribution board for power It is actually unsafe for these types of pin headers to have exposed voltages on them We wanted to prevent some customers from accidentally installing two BEC generators on these blocks which occur all the time in other hobbyist forums/kits and customers end up damaging their BEC modules. We apologize we did not make it clearer this is just a breakout board and not a BEC distribution block.

Hi Adam, By default we have J5 TELEM as matching PX4 formats, with +3.3V signaling and the +5V power. We do not recommend operating J5 or any of the 3.3V based ports at 5V signaling. There are a few things to note: The default range of the pins in the MCU spec is a max of 3.6V If you want 5V signaling, consider using J1 which is 5V signaling, but note the pinout is a different format by design using a DF13 connector instead of the JST-GH https://docs.modalai.com/flight-core-datasheets-connectors/#j1---voxl-communications-interface-connector Although the MCU claims it is 5V tolerant, there are functional configuration limitations on that tolerance that the PX4 images may include, such as internal pullups. Refer to the STM32F7 series MCU spec for details on their 5V tolerance. It is limited. If you were to run "bare-die code" (not PX4) and meet the MCU limitations, and consequently drive inputs at 5V, keep in mind your outputs are still 3.3V based, so your 5V device you are trying to talk to (if it is a CMOS input) will not register the HIGH voltage and your interface will not work. Hence overall our recommendation is to keep 3.3V specified interfaces at 3.3V. Let us know if you would like any further info. Thanks!

How far away from the cameras is that wall? That disparity image looks pretty good and at least proportionally to each other the obstacle avoidance bins look right (middle and left are about the same, a closer one on the right where it saw those dots of light on the wall). We are aware that the 3d reprojection is often better around the distance that the calibration cards are when the extrinsics are calibrated, and are trying to work out a solution to make the reprojection more reliable at farther distances.

Voxl and it's software build image use ros indigo, not kinetic. You'll either need to install the indigo version of this package or use an ubuntu 18.04 docker image with ros kinetic installed (and use this on voxl). A sample such image for using kinetic on voxl can be found near the bottom of our downlods page (roskinetic-xenial docker image)

No answer from Chad, so I put the problem again here hoping someone can advice me how to advance with this topic. I took a look at the parameters send over, but there is nothing about the rotation of the board. These params are installed on my board, but the results are the same: whenever I use it for indoor, I do the accel & gyro calibration with ROTATION-NONE, but I have a roll failure detected once I try to arm and I got the visio for local position whenever I use it for outdoor, I add a M8N GPS with compass, I can't calibrate de compass because the position indicated on the QGC is different as the position of the drone if ROTATION-NONE is selected. By the modalai doc. is ROTATION-NONE that it should be used. Did I get it correctly, or do I need to select another ROTATION value of the board for calibration? Thanks!

Hi, Thanks for the link, i have been following that tutorial but when i connect my voxl flight to Qgroundcontrol i get my drone is "not ready" . ive set it to HITL mode. It says one of the sensors need calibration but wont allow me to do it - [image: 1645626431714-capture.jpg] [image: 1645626437840-capture1.jpg] [image: 1645626315959-photo_2022-02-23_15-24-17.jpg]

Thanks for the answer, I found another solution as well that worked for me. It is probably more intuitive for experts, but i noticed that in the third party from your git you should also imply git submodule init and git submodule update . After doing that, the old instructions worked semi-properly, and I could reinstall the voxl-portal package with not farther problems. It's just the README files that were not so obvious in explaining so.

Hi Paolo, we do not have the GPIO interface implemented in python. We do have the i2c interface implemented in python and you could use that as a basis for accessing the GPIO interface. Source code here: https://gitlab.com/voxl-public/core-libs/libvoxl_io/-/tree/master/lib/python

Fixed it forgot to turn Fastboot of when installing.

Yeah, all systemd-journal-flush.service is doing is running journalctl --flush which is not doing anything when run manually

@Jae-Park You should ship out the entire drone so that the team can verify that all of the components are functional, fix anything else that you may not have seen, and do a final flight test before sending back.

Hi Vinny, Thank you for such a detailed set of answers! In response to your points: We will just make a super short connector between the daughterboard and J1. I did like the elegance of a single board that snapped on and did everything we wanted but this really won't add much to the footprint. We are running 12v passive power over ethernet so we will make sure that per the docs there is a nice supply of 5v 6a for the j1 port. Yep just making sure, this will be shunted strait into a usb-to-ethernet setup (based on the rtl8153-cg chip), depending on how annoying the GPIO stuff might be we did think about simply putting a tiny powered usb hub onto the daughterboard and breaking out a usb connection in order to do those tasks (a little more effort to implement but more flexibility) Ooof that is a bit of a minefield isn't it? The BLSPs do look to be the best choice if we go with the GPIO idea. In light of this it might not be that bad an idea to go with the USB microhub idea, that way it would not be hard to implement another discreet microcontroller to deal with any realtime/gpio tasks and simply package that up into a nice neat message to pass upstream. We will do a bit of planning and let you know where we got to. Regards, Thomas

I would first test functionality of the voxl-flight in terms of being able to both ADB into the voxl and connect to QGC. If all goes well with that then I'd check the px4 firmware version on the flight core side and no matter what it's at currently I'd go ahead and re-flash with our latest px4 firmware which is obtainable via our downloads. This link should contain all information and relevant links to complete this update of the firmware. https://docs.modalai.com/flight-core-firmware/

Hi Ahmad, U33 on all Voxl and Voxl Flight boards are the same TXS0102YZPR. The "2H" is indicative of that, with other markings as per TI. [image: 1644873062169-7a0eed09-79b9-408b-b5b0-c05ae5458857-image.png] Hope this helps. Let us know if you have any other questions. Thanks! Vinny

@Alex-Gardner I see why you created a separate tool for checking the connected cameras as the code in that tool is implemented in much lower level files on voxl-camera-server. I did quickly put together a flag option that would list cameras if they are setup in /etc/modalai/voxl-camera-server.conf I created a pull request here Let me know if this is useful. If the needed feature requires all cameras to be listed let me know and I can see what I can do. Also, I was trying to find a way to get some form of id off of the cameras, but I see in code that we compare the resolutions and that is how we distinguish a stereo from a tracking. Was trying to find some HAL3 data member that could give more of an "id". I found this ANDROID_REQUEST_ID variable in this documentation, but I could not get it working

Switching tack: I've configured voxl-camera-server to encode H.265 and write to /data/misc/camera: Mem: 1396848K used, 2464472K free, 17096K shrd, 16692K buff, 318292K cached CPU0: 32.2% usr 21.0% sys 0.0% nic 42.8% idle 0.2% io 2.1% irq 1.4% sirq CPU1: 22.3% usr 29.8% sys 0.0% nic 46.5% idle 0.0% io 0.8% irq 0.4% sirq CPU2: 53.7% usr 1.2% sys 0.0% nic 44.5% idle 0.0% io 0.2% irq 0.2% sirq CPU3: 50.6% usr 0.4% sys 0.0% nic 48.7% idle 0.0% io 0.2% irq 0.0% sirq Load average: 5.62 4.10 3.21 3/582 3801 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 3600 1 root S 850m 22.4 0 30.1 /usr/bin/voxl-camera-server 1966 1 root S 665m 17.5 0 19.6 /system/bin/mm-qcamera-daemon 2321 1 root S 3988 0.1 1 0.9 /sbin/leprop-service 2159 1 system S 372m 9.8 1 0.7 /sbin/logd 7 2 root SW 0 0.0 1 0.4 [rcu_preempt] 3445 2 root SW 0 0.0 1 0.3 [kworker/u8:14] And the CPU is in good shape: Name Freq (MHz) Temp (C) Util (%) ----------------------------------- cpu0 480.0 66.3 25.86 cpu1 480.0 65.6 22.50 cpu2 2150.4 70.1 81.82 cpu3 2150.4 66.9 22.68 Total 70.1 38.21 10s avg 38.38 ----------------------------------- GPU 0.0 60.3 0.00 GPU 10s avg 0.00 ----------------------------------- memory temp: 62.1 C memory used: 1376/3770 MB ----------------------------------- Flags CPU freq scaling mode: auto GPU freq scaling mode: auto ----------------------------------- And this is voxl-camera-server encoding H.265, at 3840x2160x30fps, writing to flash. So either voxl-streamer is doing software encoding very poorly, or something about the network stack is VERY broken. I'm inclined to think the former.

Hi @Alex-Gardner, I followed to tune params which you suggested in above, but still am not able get optimal dense pointcloud points. Is there any alternative approach in need to follow or i need combine any other depth sensor along with existing stereo..

@Chad-Sweet Right on. I will take a look at it. See what I can do

@SmittyHalibut I updated my previous response to be more clear.