Old Behaviors Page - northern-bites/nbites GitHub Wiki

** WARNING: This page is part of the LEGACY WIKI - information included here is possibly out of date. **

Our behavior system is where we take in information that gets processed in Vision, Localization, and Comm (once it's redone because currently Comm data is processed in the behavior) and make decisions to take certain actions. Most of those actions are taken through the Motion system through the Head Tracker and Navigator interfaces. Much of the decision making is done in the Kick Decider and Playbook systems and all of this is coordinated by the Player.

Something unique to our behavior system is that it is written in Python. We use Python version 2.6 because it is faster than the other, newer versions. Python allows us to develop the high level behaviors much faster than we could in C++ and it is quite useful for a behavior language since it is a scripting language. However, it does get annoying at times, in addition to its relative slowness, and there is talk of switching to something else in the distant future. In the meantime, we want to try to move some parts of the behavior such as the Comm processing and Kick Decider/Playbook systems into C++.

One thing that is incredibly important for behaviors is that other systems reliably work how they are supposed to. This means that other systems have to be accurate and precise in order for the behavior to work properly and nicely. We got by in behaviors for a long time by hacking our way around a lot of things, but in doing so we saw a lot of weird, seemingly random bad decisions crop up. It is not until the fundamentals of Vision, Localization, and Comm are reliable, sound, and robust that a truly reliable, sound, and robust behavior system can be written. A problem emerges when one of the lower level systems has a problem with its accuracy or precision. For example, you may write a behavior for the goalie that says to chase the ball when it is within 1 meter of you. While testing, you place the ball 1.5 meters away and the goalie sits there how it is supposed to, but it is not until the ball gets to .75 meters that the goalie starts chasing. A common thing for others who don't know what you coded is to say, "That's a problem with behaviors! Chase the ball when it's further away!" But we know that, in fact, it is a vision problem where the ball distance estimate is not accurate. Behaviors will get blamed for a lot of things and it is easy to hack fixes most of the time, but before doing this, really figure out if the problem is with your input or your computations.

FSAs

FSAs or Finite State Automata (also known as Finite State Machines or FSMs) are very simple computation machines. They consist of a bunch of "States" and there are certain circumstances which cause the machine to switch into a different state. Here is a Wikipedia Link for curious persons. You will learn more about these in CS:289 or maybe even in Math:200 if you're lucky enough. These are incredibly simple, but provide enough power for use in our scenario.

It's important to note that we cheat with our system of FSAs. We keep extra variables and do all sorts of other heresy, but we're allowed to not stick to the theory of the pure FSA if it helps our cause. We have several systems that are built on an FSA: Game Controller, Fall Controller, Player, Head Tracker, and Navigator. All these systems cycle through a series of states to control the behavior of the robot. For example, it is typical to see the chaser go through the series of states: ... --> 'Chase' --> 'PositionForKick' --> 'KickBallExecute' --> 'AfterKick' --> 'Chase' --> ...

Things in our FSA system can get really messy, however. We just finished reworking the Player FSA. To give you an idea of how complicated things can get when the behaviors are poorly maintained, here are a few pictures. The text in the bubbles indicate different states and the arrows between them are the transitions. The dotted lines mean that the transition takes place after the next vision frame is acquired and solid lines mean that the next state looks at the current information. The different colors just indicate which files the states are in.

Old FSA

New FSA

So hopefully that gives you an idea of what our system of FSAs looks like, but here's the code in case it doesn't. In the future, we would like to eliminate some, if not all of our FSAs for a few different reasons. The Head Tracker and Navigator systems should act more like interfaces to a C++ based control mechanism. The Motion system should receive objectives or goals from the behavior, but it alone should decide how best to move to the objective. This means building higher level control into the Motion System, which seems counter-intuitive, as the high level stuff should be in behaviors. However, the motion system has the knowledge of how itself operates (e.g. maximum speeds, safe angles, etc.) that the behavior doesn't need to know necessarily. Encapsulation FTW!!! Also moving the player from an FSA to a behavior tree approach would definitely be a good thing to explore, if not implement.

Order of Operations

No, this will not be a review of PEMDAS. This section will explain what actually gets called and in what order. This is important to know so that when using information from a submodule, you aren't using the previous frame's data. The origin of behavior processing is in the C++ in Noggin.cpp, which calls the 'run' method in Python. From there we have a pretty simple order:

• run() = main control loop
  • time.time() = updates the current time
  • sonar.updateSensors() = updates the sonar sensors
  • updateComm() = updates any new information from comm
  • updateObjects() = updates visual/localization information for ball, posts, self (should rename this)
  • leds.processLeds() = sends color update to LEDs (should move this toward the end)
  • gameController.run() = runs the python interface for the gameController (FSA)
  • fallController.run() = runs the submodule to ensure we fall safely and get back up (FSA)
  • updatePlaybook()/playbook.update()/pb.run() = main loop for playbook
    • aPrioriTeammateUpdate() = updates all the teammate information needed for playbook
    • strategize() = runs decision tree process for playbook
    • updateStateInfo() = report any changes
  • player.run() = runs player decision process where Kick Decider and tracker and navigator calls happen (FSA)
  • tracker.run() = runs decision process for head tracking, currently not overwritten (FSA)
  • nav.run() = runs decision process for navigation (FSA)
  • setPacketData() = sends comm latest information
  • out.updateLogs() = updates logs if logging is turned on (shouldn't use this)

Hopefully this will let you explore the codebase a little easier than finding things on you own. But don't worry. There's still lots of exploration to be done! There are many more method calls that are too complicated to include here, but you can track them down without too much trouble.