weixin_39886841
weixin_39886841
2021-01-12 19:24

Making pose in FixedFramePoseData optional.

This is for the case that the GPS signal is not available.

该提问来源于开源项目:cartographer-project/cartographer

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

11条回答

  • weixin_39866867 weixin_39866867 4月前

    Not necessarily. nullptrs are usually wrapped inside a unique_ptr, which makes a value non-copyable. Generally speaking nullptrs are a bad idea if you have access to std::optional.

    You are right that some functions return nullptr as null value or take arguments as pointers which are nullptr. Now we can fix these and use a better semantic.

    点赞 评论 复制链接分享
  • weixin_39866867 weixin_39866867 4月前

    -the-cartographer merge

    点赞 评论 复制链接分享
  • weixin_39557402 weixin_39557402 4月前

    Merge requested by authorized user SirVer. Merge queue now has a length of 1.

    点赞 评论 复制链接分享
  • weixin_39781209 weixin_39781209 4月前

    nullptrs are usually wrapped inside a unique_ptr

    I said "nullptr unique pointers" in my question, have you missed this? :-)

    , can you please give a bit of context what's going on here? What is the advantage to adding FixedFramePoseData with empty optionals into the MapByTime holding the GPS measurements?

    点赞 评论 复制链接分享
  • weixin_39781209 weixin_39781209 4月前

    If we have a gap in GPS data, interpolating between the poses before and after the gap is not a good idea.

    Ah, this is it. Thanks.

    Speaking of that, why are we doing interpolation of fixed frame poses, and not just applying them only at the nodes where they were taken? If you have fixed frame measurements every e.g. 10 or 20 seconds, you shouldn't be doing any interpolation at all. You should just apply the measurements at their corresponding nodes.

    If I understood everything correctly, with this implementation, in case you have rare measurements (e.g. every 20 seconds), after receiving a measurement, you should insert a "missing" measurement within a small time interval after (e.g. half a second?). This forbids interpolation for all nodes which are stamped half a second after the fixed frame pose measurement.

    点赞 评论 复制链接分享
  • weixin_39627405 weixin_39627405 4月前

    We have to interpolate since fixed frame poses and trajectory nodes can have different timestamps, i.e. there is no "corresponding node". We could as you say add a cost term for each fixed frame measurement, but would have to interpolate between the two adjacent trajectory nodes in this case. We chose to do it the other way around for simplicity of implementation, specifically to reuse the already existing cost function.

    Even if we did interpolate trajectory nodes, we would have to be able to have "no data" as valid sensor data since Cartographer merge sorts input streams from all its sensors. If we did not insert "no data" into the input stream from GPS, unavailable GPS data would block progress.

    点赞 评论 复制链接分享
  • weixin_39781209 weixin_39781209 4月前

    thanks on the explanation. I have one final question - what do you think, how long should we wait until we insert "no data" (i.e. if the GPS measurement is stamped with t, "no data" is stamped with t + dt - what should dt be equal to)? Based on your description, my guess is that dt should be something like 2 to 3 rangefinder periods - short enough not to block the multi ordered queue, and long enough to encompass 2 to 3 trajectory nodes which are stamped closest to the GPS measurement, i.e. interpolating the GPS data returns a result only for these nodes.

    点赞 评论 复制链接分享
  • weixin_39627405 weixin_39627405 4月前

    I'm not sure I understand the question. A GPS receiver should provide new data at a certain update rate, e.g. 20 Hz. In this example dt would be 50 ms. Whenever the GPS receiver sends an update without a fix, we would add this as fixed frame pose data without a pose.

    点赞 评论 复制链接分享
  • weixin_39781209 weixin_39781209 4月前

    What if the update rate of our GPS sensor is low, e.g. 1 Hz? This means that the multi ordered queue gets blocked a lot, and interpolating far away from the GPS measurement is a bad idea. I thought it would be a good idea to insert the "missing measurement" some short time after the measurement has been received. Something like this:

    GPS measurement is added at t = 0.0s "No measurement" is added at t + dt = 0.05s "No measurement" is added at t + 2dt = 0.1s .... GPS measurement is added at t = 1.0s "No measurement" is added at t+dt = 1.05s .....

    If I understood correctly, this means that we allow interpolating only between 0.0s and 0.05s, 1.0s and 1.05s and so on. First question is: does this make any sense, and second, if it does, what dt should we use. My guess from above:

    Based on your description, my guess is that dt should be something like 2 to 3 rangefinder periods - short enough not to block the multi ordered queue, and long enough to encompass 2 to 3 trajectory nodes which are stamped closest to the GPS measurement, i.e. interpolating the GPS data returns a result only for these nodes.

    点赞 评论 复制链接分享
  • weixin_39627405 weixin_39627405 4月前

    The problem you describe is the same for all sensor input to Cartographer and different from what this PR is about. If a sensor is slow, Cartographer must wait to be able to merge sort. It would only be possible to advance without waiting if you could tell Cartographer that for a certain sensor no data will arrive until a certain point in time.

    This is different from what we do here, though: Here we inform Cartographer that we have "no fix" (i.e. no pose) at a certain point in time, not that there is no data from the receiver. Our receiver will send us updates at sufficiently high frequency.

    If you wanted to support GPS receivers with very slow update rates without blocking Cartographer, you would still need this PR to handle the "no fix" situation in addition to an implementation that allows telling Cartographer that no data will arrive until a certain point in time.

    点赞 评论 复制链接分享
  • weixin_39781209 weixin_39781209 4月前

    So far, nullptr unique pointers have been used for missing value semantics, right?

    点赞 评论 复制链接分享