Skip to content

Conversation

@petergarud
Copy link
Contributor

Allows marking with multiple robots by coordinating who to mark using a danger score calculation

@sanatd33 sanatd33 self-requested a review November 3, 2025 01:28
Copy link
Contributor

@sanatd33 sanatd33 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can yall just go through and also just remove any logs/commented out code

_colcon_prefix_chain_bash_source_script "$COLCON_CURRENT_PREFIX/local_setup.bash"

unset COLCON_CURRENT_PREFIX
unset _colcon_prefix_chain_bash_source_script
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you remove these changes from the commit (same for install/setup.zsh)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think anything got changed here. Looks like just removed then added the line back.

@@ -0,0 +1,12 @@
Metadata-Version: 2.1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you remove the rj_gameplay stuff from your commit too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

clientHandles_->markingClient->am_i_marking()) {
return MARKING;
} else {
SPDLOG_INFO("Robot {}: After pending marking, not a member so idling", robot_id_);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we remove this log

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don.e


switch (current_state_) {
case IDLING:
// SPDLOG_INFO("Robot {}: idling", robot_id_);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we remove this comment

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

rishiso

This comment was marked as outdated.

Copy link
Contributor

@rishiso rishiso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few initial comments will look more later

public:
FreeKicker(int r_id);
FreeKicker(int r_id, std::shared_ptr<ClientHandles> clientHandles);
FreeKicker(const Position& other, std::shared_ptr<ClientHandles> clientHandles);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider making clientHandles part of Position instead of adding to every specific position? If we are doing it this way, would it make sense to only pass the clients it actually needs rather than a struct with all of them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried doing this in the past and remember encountering a lot of weird errors. I think there are a lot of places that end up expecting to have some definition of clienthandles (b/c included in position) but it's hard to pass one in. I tried again just now and still getting a lot of weird errors. I can try to debug but I think it would just take a long time and this approach already works so I would prefer to move on.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just got a fix for this working, i can either add it to this PR or just make a new one after this gets merged, up to you @petergarud

// Position&)
current_position_->die();
current_position_ = std::make_unique<Pos>(*current_position_);
current_position_ = std::make_unique<Pos>(*current_position_, clientHandles_);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you wanted to do conditional passing of handles based on position, you could use template specializations here, but I personally think client handles should just be added to Position itself

@petergarud
Copy link
Contributor Author

Pretty much everything should be resolved aside from potentially adding clientHandles to Position which does not feel necessary right now.

automated style fixes

Co-authored-by: petergarud <[email protected]>
Copy link
Contributor

@sanatd33 sanatd33 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good for now, i have some ideas on how to simplify the client_handles_ thing but i think that can be done after this is merged?

@rishiso rishiso self-requested a review November 11, 2025 03:00
Copy link
Contributor

@rishiso rishiso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some more comments

void revive() override;

private:
// static constexpr int kMaxWallers{6};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this out-of-date comment with kMaxWallers = 6

Marker marker_;
bool sent_join_marking_group_request_ = false;
RJ::Time request_time_;
RJ::Seconds kMarkingGroupJoinTimeout{2.0};
Copy link
Contributor

@rishiso rishiso Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make kMarkingGroupJoinTimeout static constexpr


std::array<uint8_t, kNumShells> marking_list_{};
std::array<double, kNumShells> danger_score_{};
std::array<uint8_t, kNumShells> enemey_to_friends_{};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: enemy mispelled

Copy link
Contributor

@shourikb shourikb Nov 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we noticed that and left it because it's kind of funny but we can change that if necessary and if it could cause future issues

Just changed it to enemy to prevent future headaches

std::array<uint8_t, kNumShells> marking_list_{};
std::array<double, kNumShells> danger_score_{};
std::array<uint8_t, kNumShells> enemey_to_friends_{};
std::vector<uint8_t> queue_;
Copy link
Contributor

@rishiso rishiso Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Can we use a more descriptive name for the queue (ie. available_markers)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to unassigned_markers_queue to be more descriptive. Kept the queue in there so people know it's a queue.

struct Result {
bool am_i_member{false}; // Whether this robot is currently a member of the kicker group.
std::optional<bool> am_i_marking{false};
std::optional<uint8_t> who_i_am_marking{kInvalidRobotId}; // ID of Kicker id
Copy link
Contributor

@rishiso rishiso Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to make these optional variables? Seems like we never set them to nullopt anywhere

Update: Looking at this more closely, can we just remove this struct altogether and pass a single bool?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we still need to know if we are marking someone along with if we are member. Removed am_i_marking and just kept who_am_i_marking (changed variable name for consistency). This is an optional now (got rid of the default value) and if it is set then we treat it as they are marking someone, if it is empty they are not marking someone.

uint8_t most_dangerous = kInvalidRobotId;
double min = std::numeric_limits<double>::infinity();
for (size_t i = 0; i < danger_score_.size(); ++i) {
// don't include marked robots or the guy with the ball in most dangerous calculation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure this logic is repeated elsewhere in the file. Probably should make this a helper function. In general, some refactoring might be nice here considering these functions are pretty long

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made helper function to find most dangerous robot

onOurSide = robot.pose.position().y() > field_center.y();
}

if (onOurSide) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use our_half constant instead of this. Shapes have a .contains() method

static constexpr int kMaxMarkers = 2;
// this is the threshold value for switching
// you can play with these constants if the current results aren't good enough
static constexpr double kSuperDangerSub = 3.1415926535;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we have a PI constant?

Copy link
Contributor

@shourikb shourikb Nov 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically this is just a random number and not pi, but I'll change it to 3.2 so no one else gets confused


// for (size_t i = 0; i < 6; ++i) {
// SPDLOG_INFO("Robot {} has danger score {}", i, danger_score_[i]);
// }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Omit

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept that one in because it's really easy to uncomment for debugging purposes but can remove if it is clutter

Copy link
Contributor

@Squid5678 Squid5678 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logic makes sense to me, though this PR requires changing a significant number of our classes to incorporate this functionality. While they are minor changes, I do think it's worth documenting somewhere what these changes are and why we made them for future reference.

// static constexpr int kMaxWallers{6};
static constexpr int kMaxWallers{
static_cast<int>(kNumShells)}; // This effectively turns off marking
static constexpr int kMaxWallers{2};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this be changed into a constant

Marker marker_;
bool sent_join_marking_group_request_ = false;
RJ::Time request_time_;
RJ::Seconds kMarkingGroupJoinTimeout{2.0}; // 2 seconds
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make this a constant as well in case needs to be tuned later

class Defense : public Position {
public:
Defense(int r_id);
Defense(int r_id, std::shared_ptr<ClientHandles> clientHandles);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ClientHandles seems to play a very large part in the implementation of coordinators going forward. I'm in agreement with Sanat here that we could find a solution in the future, but I am also on the side that if this works, we should not change it and finish off the coordinator design.

It would be nice if we could have a doc created on the purpose of these ClientHandles. Nothing too crazy, just explaining the purpose and where they should be used.

danger_score_[i] = danger_score;
}

// for (size_t i = 0; i < 6; ++i) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove comments; in the future if you want to include something for debugging purposes, just add to clickup description, easier for everyone to access.

[this](const rj_msgs::msg::Marking::SharedPtr msg) { // callback=std::move(callback)
selected_robot_marking_id_ = msg->mark_robot_ids[robot_id_];
am_i_marking_ = (selected_robot_marking_id_ != kInvalidRobotId);
// callback(Result{true, selected_robot_marking_id_});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove

automated style fixes

Co-authored-by: petergarud <[email protected]>
Copy link
Contributor

@sanatd33 sanatd33 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nothing blocking but if you need to make changes anyway go fix all the small stuff me and rishi commented on

static constexpr int kMaxMarkers = 2;
// this is the threshold value for switching
// you can play with these constants if the current results aren't good enough
static constexpr double kSuperDangerSub = 3.2;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe some more info on what each param is?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants