roboteamtwente/roboteam_ai

Artificial Intelligence repository for RoboTeam Twente

roboteam_ai's Issues

Intercept visualization

Danger flags needs testing

Control two teams for simulation

Is your feature request related to a problem? Please describe.
It would be very useful if we can control two teams (i.e. in simulation).

At the moment the robotcommands are send to the team indicated by the ROS parameter server.

Describe the solution you'd like
The best way, for now, would be to find out how to run two instances of ROS.

Describe alternatives you've considered
We could build it to run two trees simultaneously, but that is certainly not possible because of ROS params.

Interface ball and Robot display are offset

The ball position in the interface is drawn on a different point using drawDataPoints() than it is drawn as natively drawn in the interface. This also goes for robot positions, it seems.

Fix tests

IsInZone Condition has a lot of magic numbers

See the .cpp. They can probably be deduced from Field class.

Logging

Improve halt

Send 0 velocity commands to all robots before halting to stop them faster

robotclosetoball in gotoposluth does not consider time anymore

Fix goToPos implementations

there are too many go to posses everywhere,
we should limit these to -> controlGoToPos-folder and (maybe) one single gotopos-skill for when you don't need an explicit skill for going to a position.

Make an extensive BTFactory test

After the small example demo is done there should be a big BTFactory test

Variable maximum speed

It would be nice if there is a globally available max_velocity that listens to the current refstate, since the maximum velocity of our robots is dependent on that.

Major code cleanup

Roboteam as become quite big and we need to re evaluate it's structure.

Centralize ball visibility handling to world

Currently all over the place, needs to be in one place.

Creating a general angle module

Should have functionality to reliability calculate absolute angle differences, angular velocity etc.. Currently functionality for this is all over the place in our entire system.
Currently M_PI and other definitions (PI=3.14159) are used through eachother and it's quite messy.
Possibly doing this in roboteam_utils is a good idea so we can also use this consistently in roboteam_vision, roboteam_robothub and other repo's.

BTFactory legacy

There is legacy singleton code in BTFactory. This should change into static function.

Ball Placement is broken

when initializing Ball placement tree the ballplacement bot does not go to the ball but it somehow closes towards the center of the field.

Make ball class robust to disappearances

Ideally it would become a pointer in World::getBall() so that it can also dissappear, like our Robots.

IOTest_it_subscribes fails a small percentage of the time.

Describe the bug
IOTest_it subscribes fails sometimes.

To Reproduce
Steps to reproduce the behavior:
Run IOTest a gazillion times

Expected behavior
It should work ALL the time. Might be a ROS problem.

BTTest Memselector index is not working

Describe the bug
There are 3 lines which are in BTTest which I can't seem to refactor to work again (Google Friend Test is being annoying). They are commented out for now, and not very important.

New Composites

It might be a good idea to create a few (no more than 5) new composites which are more intuitive for relatively simple stuff like if/else statements etc - when compared to the current implementation.

Destructor in Mainwindow class gives segfault

Describe the bug
There is a segfault when closing a mainwindow (for example closing the window in qt). This is pretty annoying for testing especially, but for running roboteam_ai not really an issue.

System

• Ubuntu 18.04 Bionic Beaver
• ROS Melodic Morenia

Segmentation fault on startup in DangerFinder::DistanceModule::calculate

@mrlukasbos

segfault at line 20: "lastDistances[bot.id] = dist;

lastDistances is a std::map<int, double>, at segfault contains:

17 entries of which "first" equals (bot->id = 2) four times!!
My guess would be the problem is that there are four keys with the value 2..

Fix Coach

coach has a few things that should not be in there:

• whichrobothasball should be in world? or controlutils?
• what the hell is "safelyness"? magic numbers much, and probably not the right way to do it.
• there should not be a public static variable in coach.. (defencepairs)
• imo coach should have a seperate folder (like control), instead of a single file in utilities
• for the future: fix dangerfinder to work well with the coach

Robot Dealer Tests

Create (working) tests for the robot dealer.

Dangerfinder values different as compared to before

Probably some module is not working fully yet. (probably a different world object is used, since rtt::Lastworld has been replaced by rtt::ai::World.

Many PID's are not limited, which causes Robothub to not send a message.

Describe the bug
The max velocity (so (sqrt(xvel^2+yvel^2)) in a robotcommand should be 8.191 m/s (see robothub). Many skills use PID's (Keeper, Interceptball,Attack, GoToPos, DefendOnRobot,GetBall, Harrass, GoToPosLuth). If these are too high robothub will not send a command. We should build a limiter that tests if a skill is not sending too high commands. This also goes for most of the other things in a robotcommand, although velocity and orientation most commonly are the ones that break.

InterceptBall for keeper terminates too late/wrong

The keeper keeps running Interceptball after it has intercepted it and redirected it from the goal, so the condition for the skill to terminate need to be looked at and made robust so it does not try to intercept the ball after it has already been intercepted.

JSON files not properly copied towards running directory

JSON files not properly copied towards running directory

For running with roslaunch, roboteam ai gets executed in either ~/.ros or in cwd which is in this case workspace/devel/roboteam_ai/lib/. In these folders it needs the json files (specifically in roboteam_ai/src/jsons even).

The current hack is done in cmakelists.txt:

# copy all jsons to devel of ROS
file(GLOB JSONSa "${PROJECT_SOURCE_DIR}/roboteam_ai/src/jsons/keeper/*.json")
file(COPY ${JSONSa} DESTINATION ${CATKIN_DEVEL_PREFIX}/${CATKIN_PACKAGE_BIN_DESTINATION}/roboteam_ai/src/jsons/keeper)

file(GLOB JSONSb "${PROJECT_SOURCE_DIR}/roboteam_ai/src/jsons/strategies/*.json")
file(COPY ${JSONSb} DESTINATION ${CATKIN_DEVEL_PREFIX}/${CATKIN_PACKAGE_BIN_DESTINATION}/roboteam_ai/src/jsons/strategies)

file(GLOB JSONSc"${PROJECT_SOURCE_DIR}/roboteam_ai/src/jsons/tactics/*.json")
file(COPY ${JSONSc} DESTINATION ${CATKIN_DEVEL_PREFIX}/${CATKIN_PACKAGE_BIN_DESTINATION}/roboteam_ai/src/jsons/tactics)

This does not always work. We should find a better solution for this.

visualize a penalty area

Remove unused tactics

remove the tactics which are not used, which is pretty much every single one except defaulttactic.

Add ROS handlers

Remove one of the PID controllers

we currently have two classes in control which are PID's. Remove one, keep the other, and use that one everywhere.

BehaviorTree build needs finishing after Conditions/Skills are put here

Right now the TreeInterpreter creates a leaf for every leaf in the trees without the actual skill or condition that it should be. After they are in the repository this can be fixed and tested afterwards

make constants file safer to use

https://github.com/lefticus/cppbestpractices/blob/master/05-Considering_Maintainability.md#avoid-compiler-macros

Cleanup interface widgets

The interface code is mainly written in mainWindow.h/cpp, but it should be more structured, probably with separate classes for the widgets.

Goal visualization fails using SSL-vision

This is important because of testing the keeper.

Occasional segfault (code 139) in interface

segmentation fault in getgotoposluthpoints, probably due to multithreading safety

Colors in interface not corresponding to colors of real robots

The colors of the robots in the interface should correspond to the rosparam our_color

Delay compensation in world roboteam_ai

Idea

We know the delay of our system.
We know a robots' response to commands (roughly).
If we know the exact point in time of the world state, we could model where our robots' actually are by the time they receive a command based on the previous commands we sent. We would have to listen to our own robotcommands and build a module that simulates the robot behavior for short intervals (<0.2 s).

Controller needs refactoring

Describe the bug
The controller.cpp file could be neater.

Make tactics more flexible with optional roles

Currently a tactic claims a fixed amount of robots, and otherwise a custom tactic needs to be build. I suggest hereby a slightly different implementation that should make tactics more flexible while maintaining the security that a claimed robot stays claimed.

Proposal

I hereby propose that the default tactic takes not one, but two strings of robots w/ rolenames. One of these is optional and the other is required. An example for switches would be the following:

  {"SimpleDefendTactic", 
            { // required robots
                    {"simpleDefender1", robotType::closeToOurGoal},
                    {"simpleDefender2", robotType::closeToOurGoal},
            },
            { // optional robots
                    {"simpleDefender3", robotType::closeToOurGoal}
            }
}

The behaviour tree can be the same, but the fact if a robot is optional or not is dependent on the name in the tree. A tactic can execute without the optional robot, but it would be better if it has that robot. In this case we can create optional defenders for attack tactics, or claim every robot if they are available.

This would certainly reduce the amount of work needed to create custom tactics as well.

remove duplicate robothasball functions

bool robothasball() is at a lot of places.

• coach
• World
• controlUtils

we should merge these into one. (preferrably into the world one)

getRobotForId breaks with multiple robots

Describe the bug
getRobotForID will fail when trying to access multiple robots, as it is a shared_pointer. We likely want to implement a new function that can give multiple robots at once.
To Reproduce
Run WorldTest

segmentation fault in field

Describe the bug
segmentation fault in Field::getField(), probably due to multithreading / not threadsafe
segf occurs at widget/interface

fix by making Field threadsafe using lock guards

it might be nice to make more (static) classes threadsafe like world, control and other utilities

Shorten compile times

Is your feature request related to a problem? Please describe.
Compilation is taking a long time because of countless includes.

Describe the solution you'd like
Forward declarations should solve it!

Fix Change sides such that it can only be called with halted robots.

Change sides button will rotate the world_state and commands, however, because geometry data is sent only every 3 seconds our robots will drive 180 degrees the other direction and orientation. This is why we need to halt all robots before changing sides.

Remove duplicate hasBall() functionallity through our system

Is your feature request related to a problem? Please describe.
There is a lot of duplicate functions with different parameters that check whether a robot has a ball. E.g. the condition, the getBall function, the coach etc. etc.

Describe the solution you'd like
One clear function that is implemented in one place or clearly seperate names with separate functionalities.

Get all the "coach" logic out of RobotDealer

There are some function like "getRobotClosestToLine" in the RobotDealer that should be put on the coach. And some of them are just duplicated there already. Someone should purge the system of all the duplicate functions.

RobotDealer can be a lot smarter with robot locations and previous states

Right now the only condition the robot dealer uses to assign robots is if they are free from any tactic or not. This should be further improved by proximity, previous roles, and other heuristics.