I’m assuming this is a relatively straightforward issue. I’m working with a researcher who has an os1-128 ouster lidar scanner, and I’m excited to see that in ouster-sdk v 16 there is support for using IMU data to assist with the SLAM process. When I ran this I saw the warning [ouster::sdk::core] [info] IMU data not available, falling back to ConstantVelocityDeskewMethod so I checked the pcap file for any imu packets and there aren’t any.
Can someone help me find instructions to ensure that the IMU data from the os1-128 is also stored in the pcap file?
The IMU integration requires fw3.2 which we will release in approximately two weeks. In the meantime, you can develop with the 0.16 SlamEngine interface which is the correct interface for both fw3.1 and fw3.2 with or without IMU data.
Thanks so much for your reply @yggdrasil . I think I’m following, but I figure I should confirm: there’s no specific setting that needs to be turned on in the ouster studio recording system to make sure that the pcaps produced contain imu packets as well as lidar ones? Or is this only going to be available for sensors that come out after the firmware update?
I believe this is an older model os the os1-128. I’ll include the json metadata in case that helps answer whether this particular device will benefit from the firmware release you mention coming out soon. gist:4295dcc3d84effb72de8e70175e1db37 · GitHub
Hi @devin,
Thanks for the JSON metadata file. Those settings look fine. I see that the relevant IMU settings are not blank so IMU packets should be present (i.e. "udp_profile_imu": "LEGACY", "udp_port_imu": 7503, "udp_dest": "192.168.1.X")
How are you recording the pcap file?
Ouster Studio?
Ouster SDK’s ouster-cli?
Can you paste your command and SDK version?
SDK version can be found: pip list | grep ouster
Wireshark/tcpdump?
Can you let us know any filters you’re using (e.g. IP, interface, ports)?
I believe the researcher I’m supporting is using ouster studio to kick off the recordings. I saw in the past ouster studio didn’t allow for IMU data to get stored in the cap (maybe this isn’t true?) but it sounds like that’s been fixed.
This warning doesn’t indicate the IMU data is missing from the capture but it indicates that this capture doesn’t have synchronous IMU data which is only available through the upcoming FW 3.2 release. To have Synchronous IMU data enabled requires enabling ACCEL32_GYRO32_NMEA profile with FW 3.2 and SDK 0.16.
Note that you are only getting this warning when running SLAM. Maybe it worth we update the wording of the warning to be specific of need to have Synchronous IMU data in the capture.
To have Synchronous IMU data enabled requires enabling ACCEL32_GYRO32_NMEA profile with FW 3.2 and SDK 0.16.
since this is a relatively old os1-128 scanner, will it still be able to receive the firmware update ( i saw something about the revision number needing to be 5 or greater ? )
since my researcher is traveling before the firmware update comes out, does this mean that our recordings won’t be able to make use of this new feature of the sdk’s slamming capabilities? Or is there a way to make use of the existing IMU data in the capture still?
@4wheeler I was afraid this might be the case, but it’s helpful to have it confirmed.
So it sounds like not having the synchronous IMU data provided by firmware update means that the v16 IMU slamming capability of the sdk won’t be possible to use with this older scanner? Sorry to ask something that might be self explanatory at this point, but just want to confirm everything beyond any doubt.
That is correct. You need FW 3.2 with synchronous IMU feature (enabled via the new IMU udp profile) in order to have the builtin slam use the IMU for motion compensation.
@Samahu I really appreciate the confirmation, thanks for all the information folks have been providing in this thread. I’ll hit close, happy first week of the year everyone!
