@aashry Follow this link: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros. Catkin_ws -> src -> msg and you will find AiDetection.msg, which you can use to build a ros custom message package (ROS has a tutorial on it I believe). You can do that in whatever workspace you are working in in your docker container. Once that is built and you source devel/setup.bash, you should be able to echo the topic and if you want to subscribe to it in a node you will need to import the message header similarly to any other message type

@jonathankampia Update: running the voxl2_io driver command modified to px4-qshell voxl2_io start -p 7 worked! The voxl-px4-start script correctly noted that all qshell commands needed to be prefixed this way, but for some reason starting the driver from there wasn't working. I just added the line manually to the extra commands section of the voxl-px4.conf file and it works now. Weird, though.

As for the second IO board we have, I am still confused why I can't update the firmware. Maybe the board is just bricked.

@Alex-Kushleyev Hi, thanks for the reply, will try that tomorrow. As for the ESCs failing, we were using these motors (1155kV version) with GF8040-3 (8 inch triblade) props on a 6S setup. I don't have pictures of the two ESCs that broke, but they were the 6S version of the voxl esc here. They each had a sticker on them labeling them as 6S, and the packaging also said so.

It's also worth knowing that they failed in super low current settings. We never got the drone off the ground with the first ESC, a short somehow formed between two of the leads for one of the motors while we were testing them (we did motor testing with both voxl-esc spin and the motor slider tab in QGC). The second ESC just exploded the instant I moved one of the motor sliders in QGC. We heard a pop and a mosfet literally flew off, so I'm guessing there was a short inside it. Neither of those situations should be drawing much current...

There's really no way to mess up V+ and V-, and afaik there's no way to really 'mess up' the motor wires, but I kept them in order anyway. So, I highly doubt / hope it wasnt a wire mistake on my part.

My setup is nearly identical to the "VOXL 2 IO S.BUS input and PWM Output" case found here: https://docs.modalai.com/voxl2-io-user-guide/. The io board seems to work as intended, as I can communicate with the S.BUS receiver, and voxl-2-io upgrade_firmware says the firmware on the board is already up-to-date. I've edited the voxl-px4.conf file to change the receiver type to M0065_sbus and the ESC to VOXL_IO_PWM_ESC (or whatever the parameter is, it's correct there). I can also spin the motors through voxl-2-io spin. However, my ESC isn't connecting to the voxl 2 on bootup (I don't hear the final upbeat tones) and I can't spin the motors through the actuators tab on QGC, even though I believe it to be configured correctly.

By doing voxl-px4 -d | grep VOXL2_IO, and looking at the port numbers that voxl-2-io upgrade_firmware uses, it seems the problem is that it's trying to launch the driver and connect to port 2, when it should be trying to connect to port 7. However, when I run the command "voxl2_io start -p 7" in qshell, which should theoretically start the driver manually on port 7, it still won't connect.
We have one extra io board to test with at the minute, but I can't even update the firmware on that one, and when I run the 'spin' command it just spins one motor forever. Pretty sure both the io boards are bricked somehow.

The reason I am trying to use an external 4-in-1 esc is because the a mosfet(s) on the first VOXL esc we tried burnt out during initial motor testing and shorted, and the second VOXL esc exploded about 2 seconds into spinning up the motors for the first time. The drone is 6s, which they are rated for, and were 100% wired correctly, I had multiple people check and did continuity tests on all terminals.

Any advice on both of these matters would be appreciated.

Is there a way to change / mess with the song that plays when you power on the voxl esc?

Hi,

We are trying to hook up an mRo u-Blox ZED-F9 RTK L1/L2 GPS, which doesn't have a compass, alongside an external magnetometer with a QMC5883L chip. I read in another thread that chip is directly supported. Should we just be able to wire in the SCL and SDA pins from the mag, and PX4 should automatically recognize it? Or are there external drivers we need to add to the build? We tried it with an adafruit magnetometer + accelerometer unit and it wasn't recognized, but I'm not sure which chip it had or whether there were drivers for it (probably not).

Thanks

@Eric-Katzfey The EKF2_EV_CTRL param is set to 15 bits (all enabled). We don't have any cameras on the drone at the moment, though. Could that be introducing issues in the EKF2 and causing it to reset? I'll try disabling all vision stuff and see if it works different.

@Eric-Katzfey Yeah I realized that it wasn't really a proper debug tool. However, the problem still stands that the local NED position estimate is getting reset fairly often, seemingly for no reason, which is a huge problem for autonomy. Looking at the raw GPS data with our RTK system it seems to be extremely accurate, only fluctuating a few centimeters. I don't know if the local position thing is a voxl service problem or a PX4 firmware issue; we reflashed the board with SDK 1.3.3 (or whatever the latest one was as of 8/21/24) and the modalai px4 1.14 branch. Still same issue, no idea what's going on

@jonathankampia

EDIT: After retesting with the old non-RTK gps module (has mag) we are still getting the same issue. Local NED position is not being properly updated, and voxl-inspect-pose --local outputs nothing. Have tested the voxl-innspect-pose command on a starling and it works great, key difference is we have that one running qvio server. Not sure if qvio server is required for the local pose estimator to work?

Hi, we were setting up RTK using the mRo u-blox zed-f9 rtk l1/l2 gps on a VOXL 2. This module doesn't have a magnetometer, so we disabled the mag in PX4 params for testing. Every time we would move the drone to a new location, its local position would update while moving but return to (0, 0, Z) once we put it down (i.e. either the reference position which is only supposed to be set on boot-up is getting constantly reset, or the local position estimator is not working properly). We looked through the px4 parameters but nothing seemed off and we couldn't really find anything about the local position estimator. We were finally able to trace the problem (maybe) back to voxl-inspect-pose. voxl-inspect-pose --local had no output, as did --fixed, so my current guess is the lack of magnetometer is causing the pose estimator to mess up, which is then causing px4's local_pose_NED mavlink topic to behave the way it is.

Assuming this is the problem, my solution would be to add an external mag thru the J19 connector i2c pins 4 and 5. Should this just work? The mag units we have are also accelerometers, so I'm not sure if that will throw it off.

As for the altitude drift, we kind of expected RTK to fix it but it didn't. The height estimate still slowly drifts up to +- 1.5 meters, which is crazy especially considering it should be fusing with the barometer data.

Thanks for your help, or for any input you can provide!

Hi, running a VOXL 2 with voxl-px4 firmware version 1.14.0dev, as seen in the attached screenshot in QGC. I believe we had to use this version (or a very similar 1.13 version) because other versions did not support our octocopter layout. Multiple sources of documentation say I should be able to enable the lidar-lite drivers by changing the aforementioned parameter, or at least detect the existence of the lidar as an i2c device by running i2cdetect in the mavlink console. I am not able to find any relevant parameters, like SENS_EN_LL40LS, or run any diagnostic commands to view the i2c buses. Does this version of the firmware not contain the necessary drivers / parameters in order to connect external i2c devices? And, if so, is there a firmware version that meets both our needs (i.e. has the drivers / parameters & also supports octocopter layout)

Thanks, sorry for the confusing question!