@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.

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/
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.

Screenshot from 2024-11-25 18-52-49.png

Now the drone is able to figure_eight loop without loosing height estimates.

@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 @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:
3e07e160-442a-40be-ae73-57ba29ae9950-image.png

f8d2007c-d9d2-460c-9ae0-67104798f960-image.png

6e99702d-9fca-48bf-b69a-ee649933411d-image.png
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

@Matthew-Wellner , I am glad you got it working! When you used M0076 single camera interposer connected to VOXL2 J7, actually you were connecting to the "lower" camera slot, so that would be J7L, meaning slot ID 2, not 3. That is why your camera was not detected in that case.

Regarding your M0084 not working, it could be a hardware issue in the flex cable or it's connectors. In order to figure this out, some more testing would be needed. Also, typically we suggest avoiding daisy chaining flex cables, so M0076 / M0135 allows you to do just that. It is possible that a combination of M0084 and another extension cable create sufficient signal distortion of the MIPI lines to cause CRC errors.

Alex

@Chad-Sweet Hey, I updated my voxl to the newest system image and after doing so my docker is using docker-start.service while before it was using docker-daemon.service.

Not sure why this has changed, but I have updated the above instructions and wanted to let you know so you could change this in the documentation.

Is there a reason why this would have changed after flashing a new system image onto the device? Both times I configured my docker by using voxl-configure-docker-support.sh

@tom Thank you so much!
I was having the exact same problem with @marian.
I could connect to the voxl via ssh but could not via adb shell.
But could solve it after removing the /etc/udev/rules.d/51-android.rules.
Try to remove the file, who are facing the same problem with me.

I encountered this problem a while ago and its just a matter of a usb device on your virtual machine

7e018bc6-8636-428f-b624-327316eb00a7-image.png

You can also download adb for windows to verify that the drone is detected by the computer. If it's not detected by your computer at all (on host OS), then it won't be detected by your VM.