Hi @wouter the reason this is happening is recently docker depricated their api v1 version and are only using v2 api calls now. Meaning the original voxl is not able to pull down pre made docker images. The solution around this is to build the docker image on a parent computer, tar it up via docker save, then push that to the voxl and run a docker load -i on the tar file.

You can follow similar to what we do in voxl-docker-mavsdk:

https://gitlab.com/voxl-public/voxl-docker-images/voxl-docker-mavsdk/-/blob/main/Dockerfile?ref_type=heads

Please verify the PC data in rviz2. What you see in rviz2 should look exactly alike to what is shown in voxal portal for tof_pc. Note that the point step size is 12. See this guide for more info on pointcloud data message data

Point cloud data will look very different from image data, since the data field is constructed very different from BGR image formats.

I have replicated these results in a starling2 as well, with voxl-mpa-to-ros2 dev branch:rospc_.png

Note that you may need to spin up a static transform to see the pointcloud data in ROS:

ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 map world

@jonathankampia Yes, it would require modifying the "tones" in whichever esc param file you're using. For example for starling 2 it is defined here: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/D0014_starling_1504_3000kv_ms_props/D0014_starling_1504_3000kv_ms_props.xml?ref_type=heads#L90

@wetherbeej ,

VOXL2 does not have ability to un-invert the SBUS signal, so you cannot plug in a standard SBUS receiver directly into VOXL2. However, we offer VOXL2_IO board, which supports standard SBUS input and will send the SBUS data to PX4 using standard UART.

https://docs.modalai.com/voxl2-io-user-guide/

If you don't want to add another board and if you find a receiver that is capable of outputting "inverted SBUS", which is actually using standard UART levels, you may be able to use the PX4 standard sbus driver. However the PX4 sbus driver is not currently built for VOXL2 because it is requires some support of UART port, which VOXL2 does not support (specifically inverted signal level and maybe some other options).

Long story short, if you want a solution that will just work, it is better to use our VOXL2 IO board, but if you absolutely do not want to add another board to the drone, then you will need a rx with inverted SBUS + modify PX4 sbus rc driver to work on VOXL2.

Alex

Hi @Jeremy-Frederick
Can you please provide some pictures?
It almost sounds as if you have a faulty RJ45 jack, but these are tested in factory before shipping.
If you can get some close ups of the non-working RJ45 and the LAN7500 chip, that may help.

And, can you clarify that you have Qty-2 M0062's and one works, yet one doesn't? Did the faulty one ever work for you? Was the faulty one in any type of handling mishap (like an accidental drop/fall)?
The RJ45 has integrated magnetics to save space (which is why it is so tall), but that makes them more vulnerable to shock failure than typical RJ45's.

One thing I do know that may also occur is the jack can be installed slightly tilted, making it hard to seat the RJ45 cable in firmly. There is an odd feature on the connector that sometimes allows it to seat at an off-angle, slightly pointing down making the cable slightly interfere with the PCB (but still ok to insert, since as I mentioned, we tested at the factory). Also, the metal along the sides of the RJ5 may also be stiff, preventing a smooth insertion, so sometimes just inserting the RJ45 cable a few times making sure you get that nice tactile "click" may be what is needed to ensure the contacts are engaged and kinda "breaking in" the stiff connector.

@Alex-Kushleyev I never uploaded any parameters, just used both escs out of the box. maybe that caused the issue?

@Moderator I am aware. I've been using this drone for research purposes and I always make sure to follow safety guidelines. Thanks, I'll follow these instructions.

@Zachary-Lowell-0
Additionally, when I push the left stick on the controller up or down, it stays in that position after I release it, instead of returning to the center. Is this by design? It behaves differently from the right stick, which returns to the center automatically.

@Rowan-Dempster I think it is safest to just not use data that reads 0,0,0 as the sensor cannot measure that close anyways

@Alex-Kushleyev Yup, editing kona-perf_defconfig looks to have worked, thanks!

@itsnav , based on your test, it does appear that the camera itself is not functioning. The camera detection and configuration happens via i2c bus but the image data is being sent via the high speed MIPI bus, so that is why you could have a case where the camera is detected and appears to be running but there is no actual data. It is possible that one of 10 (!) high speed connections is not working (one clock, 4 lanes -- all differential, so x2 number of connections).

You should probably RMA this camera unit.

I am also curious what dmesg -w will output while you are running the camera server with the non-working camera and trying to inspect the stream. dmesg will output any major issues from the Kernel driver that may relate to the camera not working.

Alex

@swickliff I am using Ubuntu 20.04 on both the VM and Linux PC

@craigphoenix , I think the SDK install is failing somewhere in the middle (but goes unnoticed) and the ESC update and wifi issue is a result of that. We have not see this behavior before, so it is best to send the board back for inspection.

Thanks!

Alex

@LR Better to get a FrSky transmitter than to try to rework the drone.

@itsnav Can I get some help here, team?

@Jetson-Nano Thanks for all the help, I really appreciate it.

I was able to replicate your issue and also confirmed that the issue goes away if I move the AR0144 camera from the M0084 cable (connected to J7L) to J6L using M0076 interposer.

I believe the issue is related to potentially insufficient decoupling capacitance in the IMX214 camera, so running it on the same flex with another camera causes noisy pixels.

I hope you can work around the issue by moving the AR0144 camera to another port.

Sorry about that!

Alex