At the time of this review the package was named laser_scan
Proposer: Tully Foote
Present at review:
- List reviewers
Question / concerns / comments
- Location and name suggestions??
- kwc: naming inconsistency: package is 'laser_scan_utils' but namespace is 'laser_scan'. That implies that the package name should be 'laser_scan'
- stu: swap 'angle_max' and 'angle_min' in getUnitVectors
jml: How does this interact with "TransformListener::transformLaserScanToPointCloud," since this provides similar (but inferior) functionality?
vijay: A LaserMedianFilter is defined, but I imagine there could be many more types of laser filters (eg. intensity filter, between-ranges filter)
It might be useful to have an abstract LaserFilter type that any laser filter would inherit off of.
- eric: in Median filter, num_ranges and averaging_length are not clearly defined. At least one likely needs re-naming
eric: in Projector, what is the need for preservative parameter, when the range also defaults to -1?
- brian: Do we intend to keep using NEWMAT data types? Should we instead use ublas or something similar?
Interface with libtf?
- Move libtf laser projection into here
- Make selection of quality vs. speed selectable
- Pull laser_scan message into this package (Decided against)
- Don't want to add deep dependency tree in order to get laser_scan message
- Put laser_scan in robot_msg, its own package, or just depend for messages
- Can keep using
- Don't return Newmat externally
Package status: API partially reviewed. Second review needed.
Rename to laser_scan
Move laser_scan into robot_msg
Move tf laser_scan transform code into laser_scan
Remove num_ranges, and just allocate when scan received (num_ranges may change)
Propose and review filter base-class and extensibility
Review TF integration API