@Eric-Katzfey I did the systemctl stop and started service again. I guess rebooting the board earlier did not have the same effect. The compass calibration in Q is working now (no more "no mag found" error) which I guess it means the mag is working now and our gps is working too.

here is the output of voxl-p4 -d by the way:

INFO [qshell] Send cmd: 'lis3mdl start -R 10 -X -b 1' INFO [muorb] [uORB] Marking DeviceNode(qshell_req) as advertised in process_remote_topic INFO [muorb] [qshell] qshell gotten: lis3mdl start -R 10 -X -b 1 INFO [muorb] [qshell] arg0 = 'lis3mdl' INFO [muorb] [qshell] arg1 = 'start' INFO [muorb] [qshell] arg2 = '-R' INFO [muorb] [qshell] arg3 = '10' INFO [muorb] [qshell] arg4 = '-X' INFO [muorb] [qshell] arg5 = '-b' INFO [muorb] [qshell] arg6 = '1' INFO [muorb] [drivers__device] *** I2C Device ID 0x51e09 335369 INFO [muorb] [drivers__device] Set up I2C bus mutex for bus 1 INFO [muorb] lis3mdl #0 on I2C bus 1 INFO [muorb] (external) INFO [muorb] address 0x1E INFO [muorb] rotation 10 INFO [muorb] INFO [muorb] [qshell] Ok executing command: lis3mdl start -R 10 -X -b 1

@Matthew-Wellner , thanks for the update!

Out of curiosity, does the properly configured Boson work with original hardware + the CCI workaround in the kernel? It would be helpful for us to have that information for debugging.

Please send back the non-working adapters when you get a chance.

Thank you!

Alex

@Muqing-Cao said in Integrating lidar sensor:

About using another state estimation source, can you suggest me how to do that? Say we can get lidar-based position estimate in ROS message, can we disable the onboard VIO and feed our position estimate to the onboard flight controller through MAVROS or something else? Please advise.

Please help advise on this question, thanks

@psafi In this case we don't use voxl-mavlink-server directly because we are essentially setting up a "mavlink device" straight into px4.

@andrevs01 But, the configuration of what Mavlink broadcasts can be different than what it actually broadcasts. It will only broadcast something that it is configured to broadcast if it is receiving data from the required topic(s) internally.

The three are all different makes/models

@tom Thank you so much. It is working now with your suggestion. I think the README file of voxl-tflite-server need to be updated.

@Moderator Even I am facing the same issue. Did everything as per the instructions on the official website. But unable to calibrate the stereo front. I was able to calibrate stereo back though. I have attached the error along for your reference.

@tom Gotcha, I did not realize that and in the version of QGC I was using the motor spin tool was not working. I updated QGC and was able to get them working correctly, thanks for the help.

@george-kollamkulam , i am assuming the drone is already set up with the correct camera config (you can also re-do it using voxl-configure-cameras and select 27. If your drone was incorrectly set up in C28 configuration, you would see the same error.

One way to check this before re-running voxl-configure-cameras is to list contents of /usr/lib/camera and see which sensormodule files are in there. For C27, you should see three AR0144 sensormodules (for slots 0, 2, 6), one IMX412 sensormodule for slot 1 and another one for the TOF in slot 3. From debug info when running voxl-camera-server -l, the three types of cameras have different sensor ID, as follows:

AR0144: 0x0356
IMX412: 0x0577
TOF : 0x2975

Assuming that step above will result in the same issue (AR0144 camera (sensor ID 0x0356) not detected in camera slot 2), then i think you need to inspect the M0173 board and specifically the connection of the camera in port J5 of M0173. Make sure the ucoax cable is plugged in properly, similarly like others. Unfortunately that will require some disassembly.

You could also double check first the ucoax connection at the camera itself if that is easier to access. If you have a spare AR0144 camera, you could try to disconnect the camera cable from the non-functioning camera and connect the spare AR0144 to see if the camera is the issue or the cable (or downstream connections).

Hopefully it is just a software mis-configuration, but please inspect the cables as suggested.

Alex

@Eric-Katzfey I am using VOXL 2 to Flight Core v2 to VOXL FPV ESC, will this change affect any performance of the flight or any other abilities.

Hi @jonathankampia
Can you please post some pics of your setups?
I cannot tell exactly how you are using J3, and which version of VOXL 2 Mini do you have? M0104 or the new rounded corner M0204 with fixed SS lines?

Do you have a spec of the SSD you are trying to use? What other 5V peripherals are you using. We could be pulling too much current, since V2 Mini only has 900mA TOTAL 5V support so other 5V peripherals will eat into that budget.

Thanks!
Vinny

@Eric-Katzfey never mind about the cable, I found them on Amazon...

@tomverstappen , I am glad you got this resolved. The "unknown board" message you were receiving was due to the older release of voxl-esc package, which did not recognize (and did not have firmware for) the M0129-6 ESC, which is the 6S-compatible version of the M0129 ESC.

I hope this clarifies that issue.

Alex

@hula Would very much appreciate that, however, I don't see a way to send a DM to another use. Feel free to DM me if I'm missing something or point me in the right direction here on this topic!

Very much appreciate any help!

@ashwin I'm not really understanding the issue. Mavlink has no limitation to send packets to a localhost address. On VOXL 2 we configure voxl-px4 to send to localhost but that is because voxl-mavlink-server is the application that actually sends the data to the GCS. At the GCS you will see each connection with a unique IP address.

In fact, I think the whole voxl-mavlink-server scheme to set the system time from the SYSTEM_TIME mavlink message is fundamentally flawed for the case when PX4 is run on SLPI. The SYSTEM_TIME message emitted from voxl-px4 uses the system clock of the apps processor as it's time basis. So essentially, it either

never changes the system clock if the offset between SLPI monotonic clock and apps monotonic clock is less than ten seconds continually sets the clock to either the future or the past by the offset of the monotonic clocks in the case where the offset is greater than 10 seconds

It seems like this system should really be based on GNSS clock time instead of the SYSTEM_TIME message for this setup.

Hi @TomP
Looking pretty grim...
That specific signal is all buried at least 3-7 layers deep directly from that pad and it hits other BGA devices right in the pad.... no exposed traces, no exposed pins at all...
You'll have to find a different UART port or some other plan B.... sorry.

@Eric-Katzfey thank you for reverting back, it was very helpful, i was able to get multiple streams.

Hi @Alex-Kushleyev ! Thank you very much for responding. Here is a diagram of how we use the cameras. Almost everything comes from the factory. I made some optimizations, such as ensuring that our mission manager does not consume or open a video consumption channel, but only consumes data, which has improved things, but I have not been able to significantly improve consumption and temperature issues. Sometimes the open vins reaches over 100% consumption and dies in the process (state -1), which is extremely risky for autonomous operation. I also noticed that it has a certain delay, which can lead to erroneous coordinates or erratic movements. I saw that you recommend a fan. Which one would you recommend? Do you sell them?
I look forward to your comments and possible help, thank you very much.

diagrama.png