Add dynamic reconfigure to so3_control

[kartikmohta]

No description provided.

[tdinesh]

@kartikmohta @versatran01 lets get this merged next?

[versatran01]

Is there a review interface on github?

1. I didn't find where the gains are limited in cfg callback.
2. I don't think this mutex is needed in line 62 of SO3Control.cpp

[tdinesh]

Is there a review interface on github?

The "files changed" tab on the PR allows for review

[kartikmohta]

Give me a couple of days to get to this

[kartikmohta]

Replying to comments from @versatran01

1. I didn't find where the gains are limited in cfg callback.

Yes, they are not. Do they need to be? If the user wants to set custom gains from the command line, they need not be restricted.

2. I don't think this mutex is needed in line 62 of SO3Control.cpp

That mutex is used by the dynamic_reconfigure::Server. Providing a mutex to the constructor is highly recommended instead of relying on the internal mutex.

[kartikmohta]

Some important warnings about the changes in this branch:

• I did not update the pid_control package in the repo to handle the use_msg_gains_flags in the updated PositionCommand message, so it does not work now. I don't think there is any need for the pid_control package since we have the TRPY controller in so3_control, so I'm strongly in favor of just removing it.
• Similarly, any controller or custom tracker (which uses non-standard gains) outside this repo will need to be updated to properly handle the use_msg_gains_flags in the updated PositionCommand message.

[versatran01]

@kartikmohta
What I meant is to relax the max and min range of the gains, but while tuning online, the user can only change by no more than say 10% of the current gain. This is to prevent a huge change in gains. Does that make sense?

[jpaulos]

@versatran01 I would find a flat 10% change restriction extremely frustrating. I'm sure you could pick a better magic number, but my point is how will you convey these restrictions to the user in a transparent manner? If one was to introduce feature creep in the gain tuning experience, I'd press in the direction of getting better feedback to the user and providing convenience functions for excitation.

[versatran01]

There needs to be some mechanism to prevent large gain changes, otherwise there will be a day when somebody accidentally types an extra 0.

[kartikmohta]

@versatran01 I think the current limits on the gains are reasonable for most of the robots we use and also prevent very big changes in the gains.

There needs to be some mechanism to prevent large gain changes, otherwise there will be a day when somebody accidentally types an extra 0.

True, can happen but I think rare enough to not be worth adding complexity to the code. Also I assume most people would just use the sliders in the rqt_reconfigure interface for basic gain tuning where making such mistakes is harder.

[tdinesh]

Some important warnings about the changes in this branch:

• I did not update the pid_control package in the repo to handle the use_msg_gains_flags in the updated PositionCommand message, so it does not work now. I don't think there is any need for the pid_control package since we have the TRPY controller in so3_control, so I'm strongly in favor of just removing it.

I rather keep it as good easy to read through example. We could just add CATKIN_IGNORE

• Similarly, any controller or custom tracker (which uses non-standard gains) outside this repo will need to be updated to properly handle the use_msg_gains_flags in the updated PositionCommand message.

Good point!

[tdinesh]

Everything looks good to me, tested in sim. Squash and merge?

[kartikmohta]

Wow, took three years to get this merged! 😄

[tdinesh]

Well one final PR remaining #88. Dreading the initial merge, going to be lot of conflicts 👎

[kartikmohta]

I'm not really in favor of merging #88, it has too many changes in one PR.