As far as I know no one has ever tried this. I don't think HITL is supported by ardupilot (was in the past) but there may be some sort of Simulation on Hardware (SoH) that you could try to get running on VOXL2. I'm guessing it wouldn't be easy.

Hi @rowan-dempster Yes, we know we purposely put the SPI3 bus in two locations. It was intentional, but we have since learned not the best approach for all customers, so we have no plans to do that again. The CS_N issue you are seeing is not surprising. That being said, if you keep continuing with the SW configuration (which may not be easily solved and I do not think we've done that internally yet) our only suggestion for options right now are as follows: Use a different SPI bus. J3/J5 have other options. It is a smaller "Ask" to enable SPI11 on J5 than fix SPI3. https://docs.modalai.com/voxl2-qups/ Rework (i.e,: remove) the IMU (does not help if you need that IMU however). We can give you a waiver on the RMA exclusions on these boards should something else arise not related to that rework process. Hope that helps, and sorry if it's not the news you were hoping for.

Yes, I believe the system image v1.8.08 has all the above changes built applied. Easy way to confirm voxl-camera-server -l and check the printed min gain. it should be 100 not 54. if you see 100, then you have the latest com.quite.tuned.default.bin exposure control improvements should also be in there as of v1.8.05 (com.qti.sensor.ar0144.so). this is harder to test, but sdk 1.6.5 should have the latest. To test, cover up the camera to drive the exposure and gain to the max and then uncover and you should observe smooth transition, no jumps in image brightness. it looks like we are not shipping com.qti.sensormodule.ar0144_fsin_3.bin in the system image right now, but like i mentioned earlier we are moving towards putting the camera drivers into the voxl-camera-server repository.. but for now you will need to manually copy that one. Alex

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

MPA to ROS2 can be found here: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros2

@moderator Any reply will be much appreciated.

We are having the same issue on our C28 config.

@mrawding , I am sorry, but it looks like we are not going to be officially supporting Ubuntu2.0 Kernel on VOXL2, as we are working on enabling next gen hardware.. We did start the effort but it is not going to be finished for the general availability for VOXL2. Alex

What commands did you use to start each one? I would try qshell mb12xx start -X -b 4 -a 0x66 and qshell mb12xx start -X -b 4 -a 0x70

Hi @Eric-Katzfey Thank you for your help! I got it to work on J19 through PX4.

@Robbie-McCue Thank you for your feedback I will look into this.

Hi @wilkinsaf Thank you for this post! I had the same issue and was able to solve it using these steps.

@Samuel-Marchetti Perhaps this can help with the odometry? https://forum.modalai.com/topic/3341/odometry-message/3?_=1782862595827

@Raiyan-Alam said in Is there a way to power this Wi-Fi Adapter + Radio using this specific ModalAI UART adapter board?: rfd900x Hi @Raiyan-Alam, My suggestion: keep the Wi-Fi adapter on USB and feed the RFD900X separately. You can pull an extra 5V feed using this power module cable, which splices off a 5V red JST SFHR connector: https://docs.modalai.com/cable-datasheets/#mcbl-00095 Splice from that into the RFD900X's 5V input. For the M0151, don't power the RFD900X off USB but pull it directly from the power module supplying VOXL 2 instead.

@Eric-Katzfey Thank you so much this fixed the issue!

@Engineer123 You can download all the necessary flat build files from our page: [modalai.filecloudonline.com](link url). Go into flat builds folder and download the m0054(154-1) flat build file With regards to actually flashing the flat build, and using modal-qdl repo: Make sure to put the flat build file properly in a correct folder as mentioned by the doc (./qdl/qfil_app/modalai). Make sure the file is unzipped (it should be m0054(154-1)/ all the files, NOT m0054(154-1)/m0054(154-1)/....) Some users have seen a higher qdl success rate when they ran install_dependencies.sh and run.sh with sudo commands. So sudo might work better Confirm that the voxl is in edl mode