CURRENT BUGS & ISSUES
Gait switching interface
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?
Correct switching from squatting to squatted
Correctly use spin find ball and chasing.
Fix stopping during approachBall, should never setSpeed(0,0,0) during approach or goTo
Tucker: Localization, comm Joho: Motion Chown: Vision?
Get more people. duh.
High Level and biggest goals
- 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
Double check the MOTION TIME STEP
so we can make the switch to 10ms timesteps
Navigator refuses Step commands
when the walk is already active.
Move each gait into a separte file
All gaits get separate file, in a folder called motion/gaits
Better Webots gait
Fix factor of 2 in straffing
Decouple Step creation and ZMP generation
Walking interface to Python to move a certain distance & angle
Fix/Dehack how walk engine does turning steps
Make hip offsets variable, so we can widen stance of robot
Rearchitecutre Walking (see details)
Move more complexity out of step generator
And into Controller/WalkingLeg, and make Step Gen really just a glorified list
ZMP recalculated after each frame depending on new steps
Decouple ZMP and Step creation
Should be solved also if ZMP is constantly recalculated
Steamline cycloid calculation
Put cycloids and trapezoids in own class and only compute once
Ensure that nothing identical is calculated twice
See if STRAFE ZMP and L/R ZMP OFF can be merged
once the stance width actually works
Figure out a better way to use angleXY as sensor feedback
Clean out MotionInterface of unused functions
Figure out how to move each provider into its own directory
This probably requires a motion/include folder, and potentially some virtual class to protect other modules from including too many headers from inside motion
DeHack the fake typing that exists inside MotionCommand.h
The enum of Command types needs to go. Maybe replace with a static pointer to the associated Provider?
Determine if the PyXXCommand wrappers could be removed entirely
We might be able to totally remove the PyWrapper classes and just use boost to wrap the actual command classes directly
Replace all pointers in PYXXCommands with boost pointers
This would allow only creating those commands once in Python. Otherwise if the command is sent twice, a deleted pointer will get deleted again.
Investigate if Python could be fixing mutexes
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.
Remove the MOTION_DEBUG ifdefs from the headers
this will speed up compilation when this flag is switched
[#B] Kick engine
Needs adjustable resultant distances and angles. Dynamic depending on ball placement. Inverse kinematics plus COM-Control.
Look-To RelX, RelY in the HeadProvider
Potentially redo velocity clipping in NaoEnactor
Implement NUBot esque fall positions
Opponent recognition (also with sonar)
Open goal detection
Implement TOOL-side regression testing in learning modul
Check edge detection
[#A] Improve green between line endpoints and corner sanity check
Improve CC detection
Improve intersection between endpoints detection
Possibly: augment simple between(intersection,endpoint1,endpoint2) with info about where the visible line ends, how many points on each side of it.
When detecting a CC, label the line as CC-Lines
Improve T detection
Some of CC detection could be applied here
Improve T classification
Use length of bar and stem
Bottom/top T corners will have very long stem and bar. Either means it’s a bottom/top.
Use some ambiguous landmarks to ID corners
A goal post can at least narrow down the choices.
Use other VisualCorners to identify corners
If there is an L corner near a T corner, then the T-corner is a goal T corner
Fix CC-unused point identification
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).
Fix/remove field angle sanity check
Possibly just broaden it significantly
Set shape when setting possible corners
Loop through and remark all CC-intersections given other corners
Better use corner information to identify lines
Identify lines without corners
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.
[#B] Improve Kalman filter
[#B] Investigate using unscented or multi-modal filter
[#B] Improve handling of unexpected observations
Could turn it off or use a counter for when to use observations again.
[#C] Move from boost/UBLAS to the Eigen matrix library.
Do ball covariance differently / landmark cartesian coordinates
There will be comments in the LocEKF and BallEKF describing this
Investigate sensor based odometry
[#B] Test/improve odometry
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.
[#C] Teammate localization
[#C] Opponent localization
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.
[#A] Better ambiguous landmark usage
Use a joint probability for all landmarks, instead of a NN association for each landmark independently
Use a multi-modal kalman filter
Use L-Corner shape to identify ambiguous corners.
If we’re not in the goalbox, field corners should look very different than other ones.
[#A] Replace hand coded kick decision with computational best kick choice.
[#A] Python kick objects.
Objects store kick characteristics like distance, angle, and total move time.
[#A] Kick objectives define high level desired ball placement.
E.g. “in their goal”, “opponent side of the field”, “in front of my teammate”
[#A] Improve positioning on ball before kick.
Choose kick before stopping, then position accordingly.
[#B] Better shot aiming
First, aim where they’re likely to not be. Then, add in shot detection.
Goalie saves (that do not harm the robot, preferably)
e.g. kick leg out when ball is close enough, or at least a gentle dive.
Fall protection, a la NuBots.
Keep detection in C++, but increase its robustness and add Python mid-fall response.
Smarter and faster panning, ball searching
Don’t look of the field, face the field
Re-implement Aibo role selection as per NBites paper on subject
This is pretty much there
Just need to add in stuff for the third robot
Work out 3 robot deployment strategy
Monitor robot stability online:
(maybe by amplitude of aX/aY oscillation), and potentially have behaviors react when this oscillation becomes too large
Setup TCP streaming to robots
Be able to stream localization info, including landmark detection from a robot in real time
Use tickets more to manage team workflow
Check out the burst tools and adapt them to our needs. Possibly write integrate into TOOL.