Ticket #341 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

colli ignores obstacles when transforms are unavailable

Reported by: thofmann Owned by: bahram
Priority: major Milestone:
Component: Fawkes Version:
Keywords: Cc: tneumann
Git Branch: common/colli

Description

With the default bbsync settings on Caesar and Brutus, the colli ignores any obstacles when no transforms are available. This happens both with relgoto and ppgoto skills.

As an example:
When the robot is right in front of table and relgoto{x=0.2,y=0.0} is executed, it does not move because it detects the obstacle (the table) in front of itself, which is the expected behavior. However, if Fawkes is stopped on Caesar, it will start to accelerate and hit the table.

Similarly, when a ppgoto skill is running and Fawkes is stopped on Caesar, the robot will continue to move and get to the target, but it will ignore any obstacles on the way.

How to reproduce:

  1. Put Caesar in front of an obstacle
  2. Execute relgoto{x=0.5,y=0.0}
  3. Unload the robot-state-publisher plugin (on Caesar)

Caesar will then hit the obstacle.

Change History

comment:1 Changed 6 years ago by bahram

  • Status changed from new to accepted

Thanks, will look into it.

This was probably introduced with the new laserdata-history, where all data is transformed to "/odom" frame first.

Should be easy to fix.

comment:2 Changed 6 years ago by tneumann

The correct possition to fix that, would be

ColliThread::interfaces_valid()

There you can check if the transform exists.

ps. but you should already see an error, since the colli should spam the err-log

comment:3 Changed 6 years ago by bahram

Yes, that's exactly the place and it's the reason why I said it should be easy to fix :)

comment:4 Changed 6 years ago by bahram

  • Status changed from accepted to reviewing
  • Git Branch set to common/colli

Should be fixed now.

I didn't modify the interfaces_valid method though. Upon transformation problems, we already get a return value of 0 when updating the occupancy-grid. I use that information now to stop immediately. It was only used for the "emergency-stop drive-mode", but a failure of the occupancy-grid should always lead to a stop.

Needs to be tested though :)

comment:5 Changed 6 years ago by bahram

  • Status changed from reviewing to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Subscriber, Participant

  • Bahram Maleki-Fard(Owner, Participant)
  • Fawkes Trac List(Always)
  • Till Hofmann(Reporter)
  • Tobias Neumann(Subscriber, Participant)