Feature/ht kick#936
Conversation
|
closes #937 |
jgueldenstein
force-pushed
the
feature/ht_kick
branch
from
bfe854c to
50d003e
Compare
|
tested on the robot and working well, does not do anything as long as the action is not called. |
| // Forward the kick goal to the motors if we are in a state that allows it. | ||
| // CONTROLLABLE lets the first goal through (which then transitions us to | ||
| // KICKING), and KICKING keeps the following goals flowing. | ||
| if (current_state_ == bitbots_msgs::msg::RobotControlState::CONTROLLABLE || |
There was a problem hiding this comment.
This is a bit risky as the walking also talks during controllable. The state essentially is "walking ready to give up control". And the argument that we would drop the first tick otherwise also only applies of we kick if we are in controllable (e
g. standing stable for one second or more). In all other situations the first tick is indeed dropped. The line here could enable a situation where both talk during controllable which might be pretty bad.
There was a problem hiding this comment.
The state is changed to kicking after the a tick of the hcm dsd
| result = Kick.Result() | ||
|
|
||
| while self._node.get_clock().now() < end: | ||
| if goal_handle.is_cancel_requested: |
There was a problem hiding this comment.
We might want to cancel ourselves if we are in the wrong robot state. Especially with the fast standup it could happen that we fall and standup before the kick has finished leading to weird behavior. It would be easier to self cancel in that case.
There was a problem hiding this comment.
please make a future work issue
|
|
||
| # MultiThreadedExecutor so the kick action's timed execute callback (its own | ||
| # reentrant callback group) runs concurrently with the 50 Hz control timer. | ||
| executor = MultiThreadedExecutor() |
There was a problem hiding this comment.
This is really dangerous. For both performance and reliability reasons never use the multi threaded executor. You can use async for the action server callback and have a future
that is awaited inside it. This frees the executor while it is waiting for the kick to finish. Then you have a tick / update that is called by the main policy timer. This checks a shared reference of the action goal for things like cancelation etc, sets feedback and sets the result of the future if we are finished/canceled and want to continue with the action callback to the end. This way you gain the advantage of a much more controlled update schedule with significant lowers risks for deadlocks and improved performance.
There was a problem hiding this comment.
please make an issue for future work, the kick works reasonably well with this setup
This reverts commit 7e6f2d5.
3 participants
Summary
Include kick policy from hightorque in our rl framework
called via an action, incorporation in behavior pending
the policy could also do walking but I propose to walk to a suitable position with our own policy and activate the kick policy from there.
preliminary tests on robot worked well, kick direction is not so accurate, kick strength matters quite a lot.
Checklist
pixi run buildTODO: