search

yujinrobot / yujin_ocs

Yujin Robot's open-source control libraries
http://wiki.ros.org/yujin_ocs
235 stars 178 forks source link

Suppress smoother warnings that can arise from multiplexing #98

Closed stonier closed 8 years ago

stonier commented 8 years ago

Provides a parameter (default is false, so that it doesn't change existing behaviour) to disable the warning that can frequently arise from multiplexer usage. This tends to get in the way of debugging when using a teleop on top of navi.

bit-pirate commented 8 years ago

Just to make sure I understand correctly:

  1. We use odometry feedback for our smoothers and the mux is currently passing through the navi smoother's output.
  2. Now, we teleop and the mux changes it's input from navi (lower prio) to teleop (higher prio).
  3. Navi's smoother starts complaining, because the odometry feedback is to different from the navi's output.

Is this correct? Assuming it is, I would be OK with this change. Though I'm wondering what would better.

Probably any velocity command publisher should know when to "give up". For example, add a handle to the mux, so it can realise when it's output is not used any more. This would also enable it to react to this is situation (not needed for teleop, but could be useful for navi).

@corot do you have any suggestions?

stonier commented 8 years ago

Is this correct?

Yep.

Adding extra wiring between the smoother and the mux might be the technically correct thing to do, but I think it's not the practical thing. The point of the warning is to give you some debugging, alert you when something is wrong so you can fix the wiring. With a 'quiet' parameter, someone can enable the parameter when first putting the system together and catch alerts when something is wrong. Once its all wired up correctly, they can then disable it.

Now, extra wiring solely to enable a debugging message that helps you to fix your (probably wiring) problems, is probably going to backfire when your extra wiring itself has introduced problems. Getting complicated. I prefer this flag I can disable once I know the system is working.

bit-pirate commented 8 years ago

Fine with that. I would be OK with going even a step further: convert that warning into a DEBUG message.