Skip to content
This repository
branch: master
Fetching contributors…

Cannot retrieve contributors at this time

file 213 lines (183 sloc) 9.913 kb

CURRENT BUGS & ISSUES

Motion

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?

Goalie issues

Correct switching from squatting to squatted

Correctly use spin find ball and chasing.

Vision

Localization

Behaviors

Fix stopping during approachBall, should never setSpeed(0,0,0) during approach or goTo

Misc.

Comment code

Tucker: Localization, comm Joho: Motion Chown: Vision?

Get more people. duh.

NEW FEATURES

High Level and biggest goals

  1. Significantly better localization
    • This entails improvements in a few places (vision, Kalman filter). Will allow for improvements in positioning and kick decisions.
  2. Kick engine
    • Omni-directional and distance varying kicks
  3. Precise stepping and stopping
    • More accurate positioning before kicks.
  4. Integrate previous components into behaviors

Motion

Double check the MOTION TIME STEP

so we can make the switch to 10ms timesteps

Walking

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

Faster stopping

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

Movable steps
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

Consolidate FinalizeJoints

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

Kicking

[#B] Kick engine

Needs adjustable resultant distances and angles. Dynamic depending on ball placement. Inverse kinematics plus COM-Control.

Head

Look-To RelX, RelY in the HeadProvider

Misc motion

Potentially redo velocity clipping in NaoEnactor

Rapid spinning

RoboGuardian

Implement NUBot esque fall positions

Vision

Opponent recognition (also with sonar)

Open goal detection

Improve FieldLines

Implement TOOL-side regression testing in learning modul

Corners

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

Lines

Better use corner information to identify lines
Identify lines without corners
Extend lines?

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.

Localization

[#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.

Topological localization

[#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.

Behaviors

[#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 positioning

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

Passing

Monitor robot stability online:

(maybe by amplitude of aX/aY oscillation), and potentially have behaviors react when this oscillation becomes too large

Tools

TOOL

Classifier.

Setup TCP streaming to robots

Be able to stream localization info, including landmark detection from a robot in real time

Trac

Use tickets more to manage team workflow

Other

Burst tools

Check out the burst tools and adapt them to our needs. Possibly write integrate into TOOL.

Website

Added a captcha to reduce spam comments on blog

General

Systematically ensure all method declarations are not in headers

Systematically make sure GPL license is everywhere

Something went wrong with that request. Please try again.