Needs to be moved into more sensible location in Python and its interface needs to be rethought. How we do it now is unsustainable and bug-inviting. Possible gait FSA?
Tucker: Localization, comm Joho: Motion Chown: Vision?
- Significantly better localization
- This entails improvements in a few places (vision, Kalman filter). Will allow for improvements in positioning and kick decisions.
- Kick engine
- Omni-directional and distance varying kicks
- Precise stepping and stopping
- More accurate positioning before kicks.
- Integrate previous components into behaviors
so we can make the switch to 10ms timesteps
when the walk is already active.
All gaits get separate file, in a folder called motion/gaits
Decouple Step creation and ZMP generation
And into Controller/WalkingLeg, and make Step Gen really just a glorified list
Should be solved also if ZMP is constantly recalculated
Put cycloids and trapezoids in own class and only compute once
Ensure that nothing identical is calculated twice
once the stance width actually works
This probably requires a motion/include folder, and potentially some virtual class to protect other modules from including too many headers from inside motion
The enum of Command types needs to go. Maybe replace with a static pointer to the associated Provider?
We might be able to totally remove the PyWrapper classes and just use boost to wrap the actual command classes directly
This would allow only creating those commands once in Python. Otherwise if the command is sent twice, a deleted pointer will get deleted again.
Currently, if a walk command is sent, the python thread must wait until all the walking processing is finished before it is able to set the next command. The walk provider should run pretty fast, but it doesnt run instantaneously. This may not be a huge issue also because WalkCommands are only sent once a frame from python. A better solution might be to keep a list of waiting commands, and only lock the provider mutexes when the Switchboard is signaled.
this will speed up compilation when this flag is switched
Needs adjustable resultant distances and angles. Dynamic depending on ball placement. Inverse kinematics plus COM-Control.
Possibly: augment simple between(intersection,endpoint1,endpoint2) with info about where the visible line ends, how many points on each side of it.
Some of CC detection could be applied here
Bottom/top T corners will have very long stem and bar. Either means it’s a bottom/top.
A goal post can at least narrow down the choices.
If there is an L corner near a T corner, then the T-corner is a goal T corner
Sees far too many CC corners because of stray points. Maybe check on opposite side of T-intersection for lots of white/try and create line points on opposite side (maybe in tighter configuration).
Possibly just broaden it significantly
Maybe scan off the end of a line for more white, then try to make more line points, tightly and add them to the line. Debug current system.
Could turn it off or use a counter for when to use observations again.
There will be comments in the LocEKF and BallEKF describing this
Take a robot with a blank color table, have it walk forward for a set distance. See what the EKF gives and compare it to the truth value.
Each opponent can be treated the same way as the ball. The code from the BallEKF should work fine, the one difference is that we need to do data association between the observations and the different robot estimates. Said otherwise, we have to track four opponent robots and we need to have some way of matching the observation to the correct of the four robots. First try is nearest neighbor. The literature has many other solutions. If people need help send Tucker an email and he can give you some jumping off papers.
Use a joint probability for all landmarks, instead of a NN association for each landmark independently
If we’re not in the goalbox, field corners should look very different than other ones.
Objects store kick characteristics like distance, angle, and total move time.
E.g. “in their goal”, “opponent side of the field”, “in front of my teammate”
Choose kick before stopping, then position accordingly.
First, aim where they’re likely to not be. Then, add in shot detection.
e.g. kick leg out when ball is close enough, or at least a gentle dive.
Keep detection in C++, but increase its robustness and add Python mid-fall response.
Don’t look of the field, face the field
(maybe by amplitude of aX/aY oscillation), and potentially have behaviors react when this oscillation becomes too large
Check out the burst tools and adapt them to our needs. Possibly write integrate into TOOL.