Update from new firmware updates
Closed this issue · 6 comments
I see this just got pushed to their master branch (I've asked them repeatedly to stop pushing directly to master and go through a proper PR.... sigh).
ouster-lidar/ouster-sdk@68ad03c
Looks like some new autoexposure and other capabilities worth adding.
Just yesterday, I was given access to v1.14-beta11 firmware which AFAIK is the latest firmware which will be the basis for the "official" v2.0. This firmware supports all sensors Gen1, Gen2, OS0, OS1, OS2 to include the 128 beam models, etc. I am sure you have it as well @SteveMacenski
There are several important changes in there to include:
- A more precise model for computing the Cartesian data from the range data + intrinsics
- The LiDAR only sends back data relevant to the particular sensor model. E.g., an OS1-16 will only contain 16 rows worth of data for the configured LiDAR mode rather than all the rows of zeros.
Ouster is providing an updated "client" (presumably open-source once released officially) to support all these new changes. Question for you @SteveMacenski Do you have a gut feel on level of effort to integrate in changes from the Ouster client? When you bootstrapped this project how far from the Ouster-supplied code did you stray? Trying to get a sense as to how tough it will be to drop the Ouster code in and begin to use it. Concern is that we don't have a test suite (yet) to evaluate the impact even if we can get it to compile and link. Need to lean on your "tribal knowledge" on how you originally set up this code base.
TIA for any insights.
I do not have this version.
If they update / give an analog, I think it should be relatively easy. I made some changes and minor reorganization but overall the bulk of it is the same. I'd probably first sit down and look at a diff to see how much it varies and then rectify changes manually, since I expect it to be mostly adding new features rather than a total re-write.
On Dec 4th the new firmware v2.0 (former 1.14-beta) was released. It unifies the data format for all Ouster sensors models (OS-0, OS-1, OS-2) as well as scan lines (16, 32, 64, 128). Unfortunately after a firmware update the current ROS node doesn't work anymore because of the changes in packet structure. Is there a plan to integrate the latest changes in the ROS node and support all models?
See this description #63 (comment)
Of course it is my intent to support V2, but this update came with no warning a couple of weeks before christmas... so my time to be able to resolve this right now is near-zero. I outlined my strategy for the V2 client support in the comment link above. I'd be happy to review / merge any updates folks can provide to make it work with the v2 firmware if you're able to spend some cycles getting a prototype up and running. It might be just as easy as copying over the new files from ouster_client with some superficial updates on packet sizing for os1 sensor. If you are able to even get that much working, I can commit to addressing the specific client changes we made in this repo to support different time modes / other updates we specifically made within a day or two.
Another issue I just thought about is the fact that I only have 1 sensor. If I were to update to v2 to test some changes, I'd be shooting myself in the foot for being able to fix / maintain the V1.x versions while the v2 version is being worked on to support. This creates a little bit of a chicken and egg problem. It would be great if someone was able to get a basic prototype running using the updated client code such that I could take it from there to polish it up with ROS2-driver-project-specific changes which I'm the best suited to handle.
Else, this will likely have to wait until early to mid January when I'll be back home with the sensor.
@SteveMacenski
I think we are on the same boat with a small difference that I have 2 sensors out of which I ruined one. The features of firmware 2 are promising but not good enough to give up ROS2.
It would be great to have the below-mentioned features as a part of the os1.yaml file or as ros2 services or both.
Feature highlights:
- Define your field-of-view - You now have the option to define and crop out any unwanted portions of the horizontal field of view by setting a Configurable Azimuth Window.
What this means is reduced data rates and simplified data processing to optimize your network bandwidth. - Standby Mode - Optimize the battery life of your vehicle, robot, or done with the sensor’s new low-power Standby Mode.
- Increase in maximum range, improved precision - Due to significant digital signal processing improvements in v2.0, all Gen 1 sensors will see the increased maximum range for all target types with no increase in false-positive rates.
- Reduced data rates, faster data processing - Data rates on the Gen 1 OS1-16 and OS1-32 will decrease by 75% and 50%, respectively.
- Platform stability - v2.0 provides a reliable platform to support your long-term application development. This includes addressing critical bug fixes and introducing other performance improvements – we’ve got you covered!
--
@Mohit-Ak PRs appreciated. As mentioned above, there is not yet support for v2 firmware to even add those.