Joint_state_broadcaster throws error when no states exist, even if none are "requested"

[ethanholter]

By default, joint_state_broadcaster publishes all available states when none are specified in its parameters. If there are no states at all (none present in the urdf), it throws a confusing error message [joint_state_broadcaster]: None of requested interfaces exist. Controller will not run. This message implies that there are joint states that are supposed to exist but don't, when in reality there are simply no states to publish

This behavior can be undesirable for example, when a project is in development it can often make sense to first implement open loop control to verify the hardware is working, before moving on to closed loop control.

I propose replacing this behavior with a simple warning indicating that no states exist to publish

[saikishor]

Hello @ethanholter !

Do you mean that it's better to change the error to a meaningful one and abort? Or just printing this error and just continue publishing an empty one?. The second one doesn't make sense to me much.

[christophfroehlich]

This behavior can be undesirable for example, when a project is in development it can often make sense to first implement open loop control to verify the hardware is working, before moving on to closed loop control.

why would you then launch the joint_state_broadcaster?

[ethanholter]

In my case, I developed a pretty comprehensive launch file for gazebo and copy pasted most of the code over from there. I am now developing the hardware interface with the rest mostly done.

I cant imagine I am the first person to adopt this workflow so that's why I suggest allowing the node to continue with nothing but a warning. This would mean just a little bit less screwing with random launch file settings

That being said, that's just my use case so I'm not sure if it's really ideal for everyone. At the very least, the error message should be more descriptive. This caused quite the headache for me.

[saikishor]

@ethanholter may be we can reformulate the error message to be meaningful, but I don't find it reasonable enough, to just print a warning and continue.

[christophfroehlich]

in fact it does not make a big difference in your workflow if it continues or not? so let's just reformulate the message.

[ethanholter]

I think simply changing the message is fine. I’ll take a look sometime in the next few days unless someone else gets to it first

[saikishor]

@ethanholter checkout #1584 please :)