Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More active HULKs on the field #38

Closed
Bendodroid opened this issue Jan 8, 2023 · 2 comments
Closed

More active HULKs on the field #38

Bendodroid opened this issue Jan 8, 2023 · 2 comments

Comments

@Bendodroid
Copy link
Member

Bendodroid commented Jan 8, 2023

We want to have more active HULKs on the field during a game.
This means less falling over, less bumping into other robots, and a faster stand-up motion if a fall occurs.
Less bumping into other robots will also help reducing our penalties.
For this to happen we need better obstacle detection (including the damned goal posts).
See also: Robot Detection #44

This topic is closely related to 7v7 Games #37

@philipniklas-r
Copy link

Philip from the team B-Human here,

to the topic less falls and faster stand-up I could give some insights if you are interested.

For less falls, judging from the code for the walking, I think https://github.com/HULKs/hulk/blob/main/crates/control/src/sole_pressure_filter.rs#L34 and https://github.com/HULKs/hulk/blob/main/crates/control/src/support_foot_estimation.rs#L52 could result in some problems, which could explain a handful of falls at the last competition. With the low-pass filtering a detected support foot switch will be delayed. With the already present delay of about 3 motion frames between sending requests to the joints and the measured execution of such requests, adding more delay sounds like an unintended effect.

The usage of the hysterese, to decide which foot is the supporting one, is a good idea. But from lots of testing a hysterese should only be necessary if the FSRs of both feet measure close to 0 pressure. I am not sure, if this is only because we auto calibrate the FSRs values (similar to the original rUNSWift walk, but for both min and max values).

If both things are changed, I expect the actual walk duration to be closer to your intended 260 ms one (at the last RoboCup the robots looked like walking with a lot higher walk duration). From experience I can tell that this shorter duration is on average more stable, but can result in other problems. Like worn out robots walking a lot slower than intended or your really strong forward kick resulting in a lot more falls. But those problems can be easily addressed.

@h3ndrk
Copy link
Member

h3ndrk commented Feb 22, 2023

Moin @philipniklas-r, thank you very much for your input! We are currently looking into your proposed changes. 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

5 participants