@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

@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

@Jacob-Camarillo No other devices are plugged into the display, and the display is set to the correct HDMI input for the VRX. The USB-C cable is also fully connected to the VRX. When powered up, there are no lights on the VRX at all. It is evidently not working. What are the next steps to initiate an RMA?

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

@Vinny Powering the drive externally didn't change anything, seems like it's a data rate issue.

I am having super weird IO problems with the ssd, like sometimes the partition doesn't show up when running 'lsblk' so I can't mount it. Data rate tests using dd are not consistent at all, and sometimes mid write the drive will become read only and dd will hang infinitely, following which I have to reformat the drive. I had the same partition issues trying a microsd card in the ethernet hub addon microsd slot - the sdcard showed up as mmcblk0 with no partitions available to mount.

I've had much more consistent performance using a microsd + reader over usb3. This post was helpful for setting some standards: https://forum.modalai.com/topic/3855/question-about-the-usb3-uart-add-on-versus-the-voxl-2-ethernet-and-usb-hub-add-on/2. With my setup (UHS-1 microssd + reader) I'm getting about 50MBps write to ext4 and ~75MBps write to exFAT formatted microsd card.

However, those tests with dd seem to be really unreliable and not representative of the rate I'll get using voxl-logger. I'm guessing I need a benchmark data rate of much higher than what we actually need (93MBps) in order to consistently write frames.

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

@psafi said in GPIO missing in /sys/class/gpio:

@Alex-Kushleyev Thank you!
I understand these ports are intended for RC input and QUP7 is connected directly to the DSP. I am considering these ports to connect a SiK radio (data format can be raw or mavlink). I want to make information coming through the radio available to ROS and PX4 at the same time. Can I use this port at all for application running on linux or is this only available to voxl-px4?

I am already using the External UART (J10) for another MAVLink device (optical flow sensor board) which is currently configured and working with PX4 (I don't need to intercept that one on the linux side). Would it be possible to connect my serial radio to J10 and switch my optical flow to J19 (and configure PX4 to read MAVLink from J19-10,11)?

@Zachary-Lowell-0 yes, i copied that directly from the terminal after running this command voxl-inspect-detections -a tag_detections.

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

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

@Alex-Kushleyev Thanks

Hi @tom,

Unfortunately, I don’t have a QGC file with the parameters. Do you know where the original parameters come from when the Starling 2 drone is shipped? Are they the ones from the voxl-px4-params repository?

Thank you in advance!