Posts made by Eric Katzfey

@LuisRzdearbulo-0 Can you provide a link to the documentation that you are referring to? What type of simulation are you looking to do?

The ICM42688 is an IMU and there is already one of those on the VOXL2 so you don't need that external one. The RM3100 is supported by ArduPilot. If it is not detecting it then we need to do some troubleshooting. First is to double check the wiring to make sure that the i2c pins for the RM3100 are correctly routed to the i2c pins on J19. You said dev board 6 pin UART. A UART should be only TX and RX (And power and ground for the external board) so only 4 pins. Are the other 2 pins for sure the i2c lines for the RM3100? And what pins are you connecting to on the VOXL2 J19 connector? Perhaps put a scope on those lines to see if you can detect activity. Make sure COMPASS_ENABLE is set to 1. You can limit which magnetometers that ArduPilot searches for on initialization by setting the COMPASS_DISBLMSK parameter. Make sure all bits are set except for the RM3100 bit (bit 16) to force it to only look for RM3100. Bus speed should be 400 kHz by default.

@Plingaas02 Regarding odometry in voxl-mavlink-server, it will not modify timestamps on this message. There will be, potentially, VIO odometry messages going to the flight controller from voxl-vision-hub via voxl-mavlink-server and flight controller odometry messages being routed out to the GCS and to the onboard stream. The odometry messages coming from PX4 will have the DSP monotonic timestamp which is different than the Linux monotonic clock and these will drift with respect to each other over time. PX4 runs the timesync service so it can correct the incoming messages from VIO.

@Dan-Jennings Honestly, I don't think updating the SDK version will help this issue. But, we highly encourage everyone to be on the latest SDK, regardless, since that's where you'll get the latest fixes and features. And it's how you'll get the best support from us. but in this case I don't think a newer SDK will get you the battery_status. It's probably a hardware issue or a parameter issue. You swapped boards and that didn't help. What about the cable? Those 4 wire cables are notoriously fragile. Can you swap it out and see if that helps? The other item is parameters. You saw that other post about setting BATT_MONITOR to 21 and BATT_I2C_BUS to 1. If you don't see the BATT_I2C_BUS parameter then it must mean that BATT_MONITOR hasn't been set to 21. Make sure it is set to 21, then reboot, then you should see the BATT_I2C_BUS parameter. Then set it to 1, reboot, then you should see correct battery_status.

@Daehan-Won You would need to add the support to PX4 since you are using the DSP I2C pins and only PX4 can access those while it is running. There is some useful developer documentation here: https://docs.modalai.com/voxl-px4-dev-build-guide/. Also visit the PX4 documentation as well. At a high level you'll need to fork our repo, make a branch off of voxl-dev, add the driver to the default.px4board file for voxl2-slpi, build the image, and add a start command into the startup script voxl-px4-start

@minhthinh The params are in our voxl-px4-params repo. For example: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-px4-params/-/blob/master/params/v1.13/Platforms/M500_FCV2.params?ref_type=heads

@Aniruddha Did you follow this guide: https://docs.px4.io/main/en/config/level_horizon_calibration

@Aniruddha Can you use level calibration in QGC instead? Are you saying that you are crashing after running voxl-calibrate-px4-horizon or in your attempt to run it? What flight mode are you using in your flight? If you fly in manual mode is everything okay?

@Daehan-Won The mb12xx px4 driver is not in our build so you would need to add it to the voxl2-slpi build. Which pins are you attaching it to on J19?

@Dan-Jennings I'm also guessing that the driver may not be detecting the hardware so is not able to get the data for the battery_status. Have you tried swapping some other hardware to see if the problem is associated with a particular unit?

@RyanH You don't need to fly the drone to get a log. Perhaps take off the props, arm it, throttle it up a few times, then disarm.

@RyanH I'll let another of my associates comment on the purchase of a new motor. But can you also share a px4 log file from such a flight. It would be helpful for us to take a look at it.

@Nikos-Mavr You're welcome! And can you please start a new forum post for this new issue? Thanks!

@Dan-Jennings I'd try our voxl-inspect-mavlink application. Check voxl-inspect-mavlink mavlink_onboard and voxl-inspect-mavlink mavlink_to_gcs and see if battery_status appears at all. I just loaded voxl-ardupilot_ArduCopter_4.8.0-94b27fd3_arm64.deb on my voxl2 with our standard APM and I see battery status in QGroundControl and with voxl-inspect-mavlink mavlink_to_gcs. Also, can you upgrade to VOXL SDK 1.6.x?

@restore There are a few examples of code that listens for Mavlink messages in our SDK. For example, in voxl-mpa-tools, take a look at the source code for voxl-inspect-mavlink.c. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-mavlink.c?ref_type=heads

Probably would be a good idea to run voxl-inspect-mavlink on the mavlink_onboard and mavlink_to_gcs pipes to see which one has the desired Mavlink message in it. Then create your own application that listens for the Mavlink message on that pipe.

@Nikos-Mavr Can you reboot, try the command again, and send the entire output of PX4 so that I can see the entire startup process?

@Dan-Jennings Rather than use voxl-inspect-battery have you tried QGC or Mission Planner or Mav Proxy?

@Dan-Jennings Which arducopter build are you using?

@Nikos-Mavr I added the ina226 and ina228 drivers into the build. Updated build can be found here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.136-202603180951_arm64.deb

To try it out use the command qshell ina226 start -X -b 4 or qshell ina228 start -X -b 4 from the px4 command line to see if the driver sees your device.

@Nikos-Mavr Okay, great, so the I2C is working then. But address 0x41 is an INA226, not an INA228. The PX4 driver indicates that an INA228 has an address of 0x45. And the Holybro data sheet for the PM02D indicates that the lower voltage one for up to 6S battery uses the INA226 while the higher voltage one for up to 12S. Am I reading that correctly? Regardless, it doesn't matter how you set POWER_MANAGER in voxl-px4.conf because that just determines whether it will start the voxlpm driver. But, probably best to set it to EXTERNAL for now. The bigger issue is that the drivers for INA226 and INA228 are not in the image. So they need to be added to the image and then started in the voxl-px4-start startup script located in /usr/bin.