Tune kick and walk parameters

[philipniklas-r]

Why? What?

Handles Issue #1524
Also tune walk parameters while I am at it.

Reasoning for the kicks:

• Forward kick: do less large forward steps, which caused falls
• Turn kick: prestep shall move feet slightly together, to make kick step more stable. Also less forward step size, which caused falls
• Turn kick orientation: judging from videos, the kick is often kick with less turn in reality, therefore reduce planned direction.

Reasoning for the walking:

• foot_lift_apex => how high the swing foot is lift up from the ground.
  • I see no advantage from changing the height. This only causes problems (e.g. doing a large side step followed by executing a zero step. Therefore while the feet are moving together again the swing height is only 8 mm instead of an actually needed higher value. This makes no sense -> changed to a constant value)
  • foot_lift_apex_increase set to 0, as this height should be constant. The only expected side effect is when stopping and standing still and starting to walk again before the robot settled from left over swinging. If this is actually the case, this special problem should be handled separate.
• foot_offset_left -> This kind of defines the origins of the legs/soles. Shifting both 50 mm to the sides makes sense (because of the kinematic of the robot). But then actually use the 50 mm from the specification. If the robots like to fall sideways (which a slight increase could handle) then there is another problem, which should not be handled with those parameters.
• step_duration -> For forward and turn steps I see no advantage from increasing the step duration. Only side steps need a correction.
  • Therefore: Max side speed of 0.1 and increase factor of 0.6 => 0.1 * 0.6 = 0.06. Step duration for max side step => 0.25 ms + 0.06 ms = 0.31 ms.
  • I recommend to implement an own variable for the step height duration. The robot only needs a slower interpolation for the swing height, but not for the side translation interpolation. As long as those use the same duration variable, the full step duration needs to be increased.
• torso_offset -> With the code rewrite in April it seems the torso_offset got removed and replaced with the torso tilt. From my testing a translation shift works better, therefore use the "typical" 12 mm shift, to shift the feet backwards and therefore the torso forward. In case the sign is wrong, change the -0.012 to 0.012.
  • torso_tilt -> The tilt should no longer be necessary.
• starting_step -> The first step should use the same duration, but half of the normal swing height. NOTE: I assume that the step_duration increase is applied for the starting step too. Therefore starting with a large side step should work in theory
• step_midpoint -> what the fuck? why were the mid points shifted ??? Judging from the commit history, those seems to be adjusted very often when calibrating the walk parameters. I am open to feedback and other point of views, but I would recommend: don't touch them. If there are stability problems -> add a separate step height duration variable instead.

ToDo / Known Issues

• I can't code in rust and doing the below ideas by myself :(
• Also I don't know if the sign for torso_offset is correct.
• PR Fix walk acceleration #1514 needs to be merged first. Afterwards step_duration_increase.left might need to be adjusted.

Ideas for Next Iterations (Not This PR)

Add a step height duration variable, similar to the normal step duration one. step height duration should also be at least as big as the normal step duration value, but it is allowed to be bigger.

With that the side walking could interpolate the step height slower (with the mid point being still fixed at 125 ms, or 50% of the normal step duration). Also the kicks could use it too.

In both cases a too early support foot switch could be prevented. The increase could be from the (now configured by be) normal 250 ms step duration to something like 280-300 ms. Such "small" increase is sufficient enough.

For the kicks, a parameter for the turn values representing to which % time of the step the turn value should be finished could improve the accuracy.

How to Test

First merge PR #1514.

For the walk parameter changes:

• Let the robot walk around and play with the ball a bit. In case it is tilting too far back/falling a lot backwards, change torso_offset from -0.012 to 0.012, because this could be a case of a false sign for this parameter.
• Also look if the side walking and walking around the ball looks better (e.g. being faster and also more stable).
• Check if the first walking step looks good in different scenarios

For the kicks:

• Disable all kicks except the forward kick. Check if the kick is stable and also kicks the ball far
• Disable all kicks except the turn kick. Check if the kick is stable and also kicks the ball far

In both cases I recommend to also test with the main branch, to get a good comparision of before and after. Also record the testing with a smartphone/camera. This is helpful to better compare the before and after state.

[schluis]

I tested the parameters.

I like the kick parameters. This looks equal / better.
The walking parameters unfortunately don't seem to improve the walking quality. Have you considered testing on a robot in your lab? The deploying should be fairly easy, just update the team.toml, set your team number and add a nao, run pepsi gammaray <ip> and run pepsi upload <ip>

[philipniklas-r]

The walking parameters unfortunately don't seem to improve the walking quality. Have you considered testing on a robot in your lab? The deploying should be fairly easy, just update the team.toml, set your team number and add a nao, run pepsi gammaray <ip> and run pepsi upload <ip>

Did you remember to combine it with the PR of #1514 ?

[philipniklas-r]

The walking parameters unfortunately don't seem to improve the walking quality. Have you considered testing on a robot in your lab? The deploying should be fairly easy, just update the team.toml, set your team number and add a nao, run pepsi gammaray <ip> and run pepsi upload <ip>

Did you remember to combine it with the PR of #1514 ?

In case you did, on one hand, I would need to see it on a nao. For that I would actually need to set everything up on my computer 😅 It could be that the walk might only improve in minor details, but overall does not decrease the fall rate further (which #1514 already should do mostly).

On the other hand, judging from the fall numbers of the RoboCups in the past years, it could be that the walk is (again with #1514) already as stable as it can get, without adding further features.
Therefore if you agree, I can change the PR to only include the kick parameters. I would only add the walk parameters, as those are more cleaned up and simplify the walk.

[schluis]

The walking parameters unfortunately don't seem to improve the walking quality. Have you considered testing on a robot in your lab? The deploying should be fairly easy, just update the team.toml, set your team number and add a nao, run pepsi gammaray <ip> and run pepsi upload <ip>

Did you remember to combine it with the PR of #1514 ?

No, but I don't think this would make a large difference. I tested mainly walking forwards and sidesteps.

[schluis]

The walking parameters unfortunately don't seem to improve the walking quality. Have you considered testing on a robot in your lab? The deploying should be fairly easy, just update the team.toml, set your team number and add a nao, run pepsi gammaray <ip> and run pepsi upload <ip>

Did you remember to combine it with the PR of #1514 ?

In case you did, on one hand, I would need to see it on a nao. For that I would actually need to set everything up on my computer 😅 It could be that the walk might only improve in minor details, but overall does not decrease the fall rate further (which #1514 already should do mostly).

On the other hand, judging from the fall numbers of the RoboCups in the past years, it could be that the walk is (again with #1514) already as stable as it can get, without adding further features. Therefore if you agree, I can change the PR to only include the kick parameters. I would only add the walk parameters, as those are more cleaned up and simplify the walk.

Yes, that sounds good! Maybe you're right 👍🏻