Feature/technical challenge vision #465
Conversation
…tant apparently and should also be in the git repository
...al_challenge_vision/bitbots_technical_challenge_vision/bitbots_technical_challenge_vision.py
Outdated
Show resolved
Hide resolved
|
Should RobotArray messages be published in "ROS_robot_msg_topic" instead of a new topic? @Flova |
|
Use the same topic as the vision. Then you don't need to change anything downstream. The name you wrote is the name of a parameter where the topic is located (I don't like this pattern, but it is present in the vision). Just use the parameter value from the config. Should be something like |
|
I read the rules and the behavior should be pretty straightforward too. It just needs to initialize the localization at the correct point (not strictly needed, as we are starting at the sidelines, but we can reduce the initial localization time by telling the robot where it is), after that it needs to send a goal pose at the other side of the field (clearing the side line). All of that should start when we press a button. I would not use the DSD for that as it can be realized in a very simple script. The robot should not leave the area of the field where the challenge takes place. One hack to achieve this without modifying the path planning would be to publish a large number of robots around the field in an fixed interval. This should result in the robot not leaving the area. The clean way would be to draw it properly onto the nav map in the path planning. |
|
I think we should make a separate issue for the behaviour and merge this branch if you consider the vision to be complete. |
| # draw bb on debug img | ||
| annotate(x, y, h, w, (255, 0, 0)) | ||
|
|
||
| # TODO I think 1 is for the blue team? |
There was a problem hiding this comment.
You can/should use the constant in the message for that.
|
Maybe we could rename it to "bitbots_obstacle_challange_vision" |
| default_value: 0, | ||
| description: "minimum size of an obstacle to be considered", | ||
| validation: { | ||
| gt_eq<>: 0 |
There was a problem hiding this comment.
I think this might need to be gt_eq<>: [0]
| from soccer_vision_2d_msgs.msg import Robot, RobotArray | ||
|
|
||
| from bitbots_technical_challenge_vision.bitbots_technical_challenge_vision_params import ( | ||
| bitbots_technical_challenge_vision, |
There was a problem hiding this comment.
Not suuuper important, but I think it is a bit confusing that you named your parameters bitbots_technical_challenge_vision, which is the same as the python file and the package name. But because this is for a technical challenge, it is okay.
| blue_robots = [] | ||
| red_robots = [] | ||
|
|
||
| if arg.debug_mode: |
There was a problem hiding this comment.
why use arg instead of self._params? You do everything in the callback, so the parameters do not get overwritten during the image handling.
Summary
Adds a simple dynamically configurable vision package that detects obstacles for the obstacle avoidance technical challenge.
Proposed changes
-New Package "bitbots_misc/bitbots_technical_challenge_vision"
-Detect red and blue obstacles by isolating color, getting contours and finding the bounding rectangle for each contour
-Dynamically adjust color ranges and min size of bounding box in rqt
-Dynamically toggle debug mode in rqt
-Publish annotations as RobotArray messages
Questions
-Are the team numbers relevant?
-Should RobotArray messages be published in "ROS_robot_msg_topic" instead?