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

@Gary-Holmgren ,

The esc driver in px4 receives data from a “mixer” module. There are different mixers for different vehicle types. It is possible that the mixer for your UGV vehicle type is not compiled for or not running on voxl2.

Px4 support of these vehicle types is supposedly experimental, so additional investigation may be required on your end :). We have not tried the ground vehicle mixer.

Alex

@Jetson-Nano Can you please start a new thread for this new topic?

I found the QGC
EKF2_AID_MASK parameter settings above (configuring to 280: Vision position fusion, vision yaw fusion, vision velocity fusion) to allow the seeker to enter position and off-board modes.

Prior to configuring, QGC was receiving VIO but was still unable to enter position mode as referenced here

To make the forum search engine happy: seeker position mode rejected

@Eric-Katzfey
I bought the Logitech C270 and tried testing it with some Gstreamer commands.
So far I have been able to use it on my Linux PC with these commands.

Connected to PC and viewing video;

gst-launch-1.0 -v v4l2src ! video/x-raw,format=YUY2 ! videoconvert ! autovideosink

Connected to PC and recording to PC;

gst-launch-1.0 v4l2src device=/dev/video0 ! image/jpeg,width=640,height=480,framerate=30/1 ! jpegdec ! x264enc ! qtmux ! filesink location=C270.mp4 -e

However, when I connect the C270 to the Seeker I cannot get any of these to work.
I have tried different video devices 0-3 and I have also substituted the autovideosink with fakesink but these changes are still not working.

Could you please show me a Gstreamer example for this Logitech C270 camera that works on the Seeker?
I would like to either stream, record, or stream+record (possibly using tee) the video using gst-launch-1.0.
Thank you

OK, then I think I understand what happened. The 12V Fan was cooling the MCUs, but since the temperature measurement is done inside the MCU itself, the temperature of Mosfets is not known.

In general it is always better to put air flow on the Mosfets, not MCU, because Mosfets produce heat.

I think this explains the behavior when MCU was reading about 90C but ESC started behaving strangely -- the Mosfets were likely much hotter and got de-soldered..

Alex

@Aaky , the mixer should never output a value lower than mixer min (while armed).

@modaltb

Hi.
I try a test on voxl-mini with your advice applied.
voxl-mini sdk version is 1.0.0
My program and spi device operates is normal.
Thanks for your advice.

I tested AR0144 with M0036 flex in the configuration shown in picture below and it works. I also have the IMX412 camera attached with its own flex. The dual flex configuration is not ideal for plugging into M0135 due to flexes pointing towards each other after being connected to M0135, but for testing purposes it is OK.

If you have AR0144 camera connected in the same way with the flex cable and the camera is not detected, then it seems like the flex cable is the issue.

IMG_3942.jpg

@AndriiHlyvko,

I just ran into the same issue while testing Boson (in my case I was testing the 16-bit Boson streaming mode). The libuvc issue caused a crash, since i did not use a fixed version of libuvc. However, what actually caused the buffer overflow was the fact that Boson was reporting smaller buffer requirements for RAW16 during query (it was reporting width * height * 1.5 , just like for YUV, but actual frame size was width * height * 2, so uvc pipeline allocated smaller buffer and overflow happened with the full frame came in.

Was this the same issue with your Boson tests or did you experience something else?

Thanks!

Alex

@Shivam-Sehgal , does it look like the board is rebooting after 10 seconds of running with cameras enabled? also, what if you ssh into the board, does the SSH connection stay alive when the cameras are connecting?

Also, how are you powering the drone for this test - battery or power supply?

Alex

@Eric-Katzfey Thank you for reverting back, I am able to get the turtle mode working now, The error was due to the safety parameters, once i changed it to the FPV setup, it was working.

Once again thank you for the support. It was really helpful.

Hi @gauravshukla914 ,

Thanks for the help with this. We've released a new beta version of the voxl-hal3-tof-cam-ros that supports auto detection of ToF and defaults the persist.camera.modalai.tof setting properly.

It will be in out next voxl-suite release, but is available from our dev channel here if you are interested in using this link

The updated readme is here.

Thanks!

Hi @Riley-Dove ,

Want to try to do a screen share tomorrow AM? I'll send an email to what's registered on this account.

Some of the errors looked like config file parsing, but the first one was truncated a bit.

If the device is in the failed currently, and you don't mind, you can throw the output of systemctl status voxl-vision-px4 -l here in preps.

Thanks, we'll figure out what's going on!

Do you have a GPS/Mag plugged in? If not please try plugging in a GPS/Mag and set the PX4 parameter SYS_HAS_MAG to 1. There is a PX4 bug that prevents VIO-only operation if a magnetometer is missing, even if the magnetometer is not in use.

We've been trying to get the bugfix approved and merged into PX4 master for over a year now but it seems to be a lost cause. For now our own branch of PX4 has the bugfix along with some custom tools for our ESCs. If your system starts working again with the magnetometer then we know somehow a standard PX4 image got onto your flight core instead of one of our own.

Regards,
James

@rogerli or @McMason Were either of you successful in getting the VOXL2 to connect to the NV Trip2? Working the same issue on my end.

@Eric-Katzfey In my case I am receiving data as @Alex-Kushleyev explains with

stty -F /dev/ttyHS2 115200 cat /dev/ttyHS2

e1b7860f-60b8-4441-a7f9-c4147a44b66c-image.png

and in the script in /usr/bin/voxl-px4-start I see that section @Eric-Katzfey
6bd3d8f4-b89b-4fa6-ad40-5c58260d333b-image.png

but when it comes to running voxl-px4 it autodetects with different bauds to the GPS. Is it necessary to change it somewhere else?
e7941c5d-6d4b-4a0c-b5ab-a9e4130ef09b-image.png

I have no problems with the MAG. It detects it perfectly.
I have the RX and TX of the GPS connected exclusively to the J9 of the 5G, and the rest, to the J19.

I also have the RX and TX of the IO Board connected to the RX and TX of the J19.
I have also tried disconnecting the IO Board and leaving only the GPS on the J9.

SOLVED: I change in the file voxl-px4-start from M0052 to M0054. Thanks!!!

@Chase-Riley Definitely would recommend being on 1.1.2 at this point.