@stevedan No, we have not encountered that. But can you open this up in a new thread so that it has an appropriate title? Thanks!

@Jetson-Nano YES!!! So happy to hear that.

@Matt-Turi Ok nice i've send an email to you

@wilkinsaf No, took out usb0 entry and it still didnt set the correct ip

@Alex-Kushleyev I have checked inference_helper and modify to handle RGB format successfully. [image: 1719806154374-screenshot-2024-07-01-113145.png]

@Eric-Katzfey okay - too bad. Is it still on the to-do list or no longer in the plans?

@Djalma-Ribeiro You can create a systemd service file and enable it to run on boot and have it execute the OpenVPN connection command. Here is an example on how we have used it in the past on a VOXL: [Unit] After=voxl-time-sync.service Requires=voxl-time-sync.service [Service] Type=forking ExecStartPre=/bin/sleep 2 ExecStart=/usr/sbin/openvpn --script-security 2 --daemon --config /etc/openvpn/KEY_FILE [Install] WantedBy=default.target Won't be exactly the same as above but that's the general idea.

@Darshit-Desai , i would say the best way to confirm storage order would be to print out the memory location of the vector’s 0th, 1st and 2nd element after you put it into eigen structure. You should be able to get the pointer using & operator and print out the pointer using printf(“%p”, ptr). If the 3 pointer values are separated by 4 or 8 (single or double precision), then storage order is optimal

Hi @dlee Can you please double check SW2. From that photo you posted, it seems as if it may stay be in the "ON" position, which would keep it in "EDL" mode and show up as "QUSB_BULK..." instead of an ADB debug device. Please be sure to follow this step carefully when performing QDL updates: https://docs.modalai.com/voxl2-qdl/ [image: 1676437032805-e7393327-f780-48b8-8b20-4c18a36639ff-image.png] We do not have many HW failures on Voxl2 in the field from routine use, so to have one so soon is surprising. However, if you are confident you are following all instructions and still wish to RMA it, we'll test it again to check for all basic functionality and debug the root cause of the failure, if any, and prompt you for further actions. Thanks!

@John-Nomikos-0 Thank you. OK, here is the big difference that is most likely the reason for your behavior. In your new params you used kp, ki, max_kpe, max_kpi terms set to zero, but old params have nonzero: <param name="kp" value="130"/> <!-- RPM controller proportional gain --> <param name="ki" value="30"/> <!-- RPM controller proportional gain --> <param name="max_kpe" value="300"/> <!-- maximum proportional erorr term (max is 999) --> <param name="max_kie" value="100"/> <!-- maximum integral error term (max is 999) --> <param name="max_rpm_delta" value="1200"/> <!-- cap for maximum rpm error used in RPM controller --> Considering that you have not calibrated the ESC for your motor and propeller (meaning that the feed-forward term in the RPM controller is wrong), if you also disable the feedback terms of the RPM controller (kp, ki) then the behavior of the ESC will be completely off from what is desired. Even with incorrect feed forward term (pwm_vs_rpm_curve terms), if feedback terms are enabled, they can compensate, to some degree, but with the feedback terms set to zero, there is no hope for the ESC to turn the motor at the desired speed. You can keep using the old firmware and params if that works for you, but if you wanted to switch to latest ESC firmware and params, then i suggest trying to use the same non-zero RPM controller params. Alex

Hey @Eric-Katzfey I was able to solve it. I was able to shift the drone to offboard-mode, the drone doesn't drift away. In voxl-vision-hub, I have the set the parameter to figure_eight. I'm getting the stream to VOXL2 from Flight Core v2. I had to run it on 2 different ports. mavlink stream -r 30 -s ODOMETRY -d /dev/ttyS4 mavlink stream -r 30 -s ODOMETRY -d /dev/ttyS6 But I'm getting the #331 odometry message when using only ttyS6 port. [image: 1732544018893-screenshot-from-2024-11-25-18-52-49.png] Now the drone is able to figure_eight loop without loosing height estimates.

@cguzikowski , Sorry for the delay. Regarding the new HW not working, since you have two identical setups, i would recommend swapping components to identify what exactly is not working. This is the most efficient way to diagnose it. From the logs you provided, the ov64b camera is detected and initialized, it seems, but no frames come in, which could be a cabling or interposer issue. I will get back to you with an update on the lens shading tomorrow. Alex

@Anton-Gereles If you have a specific question that we can help you with please open a new forum post and we'd be more that happy to help get you going.

@Aaky What format is that logs file? Is it an archive?

I will close this ticket and make a new ones. This conversations is too long, sorry for that Thanks for help so far !

Hi @Rowan-Dempster , We just merged the changes to dev : https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/merge_requests/39. A new build of the libmodal-pipe library will be added after tonight's nightly build here : http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/ . Any SDK releases after this will include this support. Alex

Hi @stevet Late to reply, and thanks so much for your instruction! It's great news for M1 developers like me I will have a try if it works well, and let you know then.

@tom Here is the output of these commands: [image: 1689356694914-3e07e160-442a-40be-ae73-57ba29ae9950-image.png] [image: 1689356818948-f8d2007c-d9d2-460c-9ae0-67104798f960-image.png] [image: 1689356880764-6e99702d-9fca-48bf-b69a-ee649933411d-image.png] [image: 1689356919104-0a85071d-b6eb-46b4-bf3e-3ab3d99a5674-image.png]

@modaltb Thank you for the update

@Jetson-Nano , I am sorry, I don't have this hardware set up right now, so I can't actually test what you are trying to do. I will check with the team regarding who can test it. Alex