robocup-logistics / rcll-rulebook Goto Github PK

In the CircleCI configuration, the images only refer to the "latest" tag. I would suggest to at least encode the Fedora version in the tag, possibly also the used TeXLive version.

This does make upgrades more explicit. They also are then a little more work, but the config is clearer and less error prone. Also, if someone uses a different OS, they can easily spot the expected TeXLive version (if that were also encoded in the tag name). This would be similar to, for example, how we tag the rcll-sim image.

This is related to robocup-logistics/docker-fedora-texlive#1.

Hi, this is a issue just to collect ideas/stuff that is unclear during robocup so nothing gets forgotten.

• A wall that can be used to create a wall between the 2 halfs of the field if challanges are done
• If two teams book a challange slot, there is only one refbox PC. If we want that two teams can play a challange in a slot we should provide two refbox PCs, otherwise we should allow booking for the official refbox seperatly.
• Possible Rule Update: Now in the Rulebook it is stated that communication has to be 5Ghz Wifi, we should also allow other wireless methods, like LTE or similar
• Production Challanges - deliver to delivery station should be allowed, since it is only extra work for a team compared to the droping in the starting zone. I would keep it a possibility to reduce the amount of mockup machines needed.
• formalize rules reagarding hand in for challange track

Currently each team has an infinite amount of bases in each colour. Each base station magazine can hold up to 6 bases.
I propose to limit the maximum amount of bases per game, as resources in a real environment are not infinite. This would also lead to less interference by humans on the playfield refilling the base station and less work for replenisher/ referees.

Add a simulation challenge to play a full game in the challenge track.

As discussed in TC meeting 1/19, we want to add special competitive order. The competitive order is similar to a normal order, but only the team that delivers first will get points for delivering the order.

The rule change proposal should describe:

• how many order may be competitive orders
• what kind of product can be requested (e.g., should we restrict to C0s?)
• how scoring for partial production steps works (i.e., is it all or nothing?)

I read the rulebook and annotated things that cought my eyes, i opened issues for the mayor things i spotted but i also want to provide my full feedback of smaller things i noticed while reading through the rulebook. Therefore i attach an annotated rulebook that you may want to have a look at. Thanks for all your good work!

@teamsolidus suggested to add dynamic obstacles to one of the challenges (e.g., the navigation challenge). It could be as simple as having an additional machine on the field which does not get announced and acts as an unknown obstacle.

Especially for the beginners and also the challenges, where only one team is on the field, it would be helpful if the encryption of the private peers could be deactivated. Possibly with a flag in config.yaml

Hi,

during the event in Aachen we noticed that not all slides are mounted the same (see pictures below)- I would suggest each input which a robot can put a base on/in is at the same height 12cm). Sorry somehow the pictures got turned, but I am sure you see the situation.



.

Also at the output of the RingStations the boards are sometime mounted differntly bringing cables quite close to the Conveyor (other two pictures). If it is no problem for you I would add a section about in the description of the MPS.

On the day where challenges are played, the reservation for playing slots should be clarified more. Theoretically it is possible that 2 teams use the playing field at the same time, bunt only one of them can access the refbox PC. We should make an update to the rules that the refbox PC has to be reserved also. Then a second team can use one halfe of the field for testing.

We should add a appendix to the rulebook which contains a Checklist of what we need for a pysical event, like GermanOpen or RoboCup.

• Barries for playing field
• Refbox PC
• Router
• Switch
• Network Cables
• Monitor

The tournament mode is under-specified. Write down the current tournament mode and add it to the rulebook.

right now there are no rules stated on how/what has to be hand in if a team performs a challenge. I don't really remember what was meant by this, but it is stated in #63. Maybe this only applies to a online event, since there are no handin for games in person.

Right now it is only allowed to use 5Ghz network. We should update the rulebook to allow more communication methods like LTE or similar.

I think the current workflow with voting implicitly by accepting a pull request is not ideal. I therefore propose a different solution:

• Every member of the TC can vote by adding a comment (e.g., +1) to the PR.
• Reviews are for checking the exact wording, spelling mistakes, etc. We would no longer require 3 reviews, but only 1.

I've started implementing a simple GitHub votebot that automatically initializes votes, count votes, and evaluates the results. A typical workflow would be:

1. Voting is initialized with /vote init (this could happen automatically if a PR is created)
2. Every TC member votes with /vote +1, /vote 0, /vote -1.
3. As soon as a majority is found, the vote will automatically be closed and the result announced.

Do you think this approach makes sense? Any feedback (both to the procedure and to the bot) is welcome.

Currently the game offers little incentive to utilize the storage station. In the future we consider a few of the following avenues to promote its usage:

1. Longer games that create more opportunity to store products
2. Penalties for letting products rest at conveyors of machines
3. Penalties for not using initially stored products ("clear the storage" while producing)

This is not a target for 2023 yet, but the different options will be tested in the future to see how they could affect games.

There are currently quite a few rules in place that could be removed without changing the game in any way:

1. The Primary field halve
   There is currently the notation of a "primary" halve where most machines of a particular team are located. We could remove that and resort to full randomness
2. Ring color randomization
   Randomizing both ring colors and their costs is unecessary. For easier setup we could leave the ring colors constant and only randomize the color costs.
3. Storage station initial fillment
   Pre-Buffered C0 do not need to be randomized. It proves nothing other than that teams can read protobuf messages and its quite a headache to fill the storage stations at the start of each game

In TC meeting 2/19, it was proposed that a robot may extend beyond the limits during machine interaction. Extending beyond the usual limits is only allowed in the direction of the MPS.

The proposal should describe

• in what situations the robot may extend beyond the usual limits
• what the limits are in those situations (if any)
• in what direction it may extend

Right now it is only possible to deliver a product to the starting zone in the production challenges. Since this caused some problems for team solidus in Bangkok we should also allow the delivery to a normal machine #63

Comparing the maximum of 14 points which can be gained during exploration to the amount of points during production, it might make sense to create a bigger incentive to score during exploration.
Points that I could think of from the top of my head:

• Combo Score (multiply score with machines found)
• Multiplier with regards to time (Z stations found in X minutes gives Y multiplier)
• Competitive Multiplier (whoever finds CS1, CS2, etc..... first gains extra points)

Might be interesting to discuss.

Original Idea by Stefan Schiffer

To avoid the sensor to trigger twice, we filter events on the slide such that we only register one event in a time window of 5 seconds. This should be explicitly mentioned in the rules.

This section is a bit confusing and does only partially reflect the way the refbox operates.
Unless i am mistaken the refbox posts the standing orders and the C2 and C3 at the beginning of the game. In any case i guess it would be a good idea to revisit this section as well as the refbox code to ensure the description matches the behaviour.

official games during a tournament have to played with mongoDB logging, and the dumps have to be handed int.

Because the Alvar tags have been deprecated, i would like to propose that we switch to the Aruco tags, which are very common and more reliable.
Christian Deppe has confirmed to me that Festo is using the Aruco library in their Frameworks (RoboView, Smartsoft). So we also have a didactic consistency.

Variable small reductions of the field size do not impact the quality of games, especially if no storage station is used. Instead, they allow official RCLL games to be performed in additional venues. It should be considered to make the field size variable and configurable within certain constraints.

It looks wonky to drop products and there are other solutions to get rid of products. A simple penality for dropping products might give teams an incentive for cleaner performances.

As discussed in TC meeting 2/19, buffering a cap should also give points to a team.

The rule change proposal should describe:

• when a team gets points
• how many points the team gets
• what happens if the machine is reset or breaks

Hi,

during the event in Aachen we had this network hickup, should we add a section Network at competition? Were we mention the IP of the refbox and the IP ranges that teams can use? Maybe even write which team uses which right now (GRIPS 105, Carologistics: 108, Solidus: 107). What do you think?

As discussed several times, and in particular in meeting 2/19, we want to use the Storage Station in 2019.

The proposal was:

• the SS will have one copy of each possible C0 in storage
• a team can get a C0 for the price of 10 points from the SS
• each team can put the C0s in any order they want, which should be done by the replenisher before the game
• a robot has to request a RETRIEVAL and specify the storage position where to fetch the product from
• STORE requests will be ignored

In order to ensure the safety for referees, teammembers and other robots I would suggest to implement a technical scrutineering before the RoboCup Competition.
The motivation behind this is that during our tests at home we damaged a cable and this went unnoticed for a rather long time.
The purpose behind a scrutineering is that all teams start with robots that are in compliance to the rules and safe.
The scrutineering for the RCLL probably does not need to be as strict as Rallye Dakar or Formula 1 scrutineering.
In my opinion checking for:

• min/max distances, heights, etc. are kept
• cables safety (intact insulation, etc.)
• lose parts, etc
• battery safety
  should ensure a sensible minimum of security.
  As all teams have different robots, I believe we should discuss this so that fairness is ensured.

As discussed in the last TC meeting, here is an issue where we can discuss the details for the payments made at the storage station.
Most work on the refbox to control the storage station is now done, for the full thing check out: robocup-logistics/rcll-refbox#91.
To wrap up: All 48 shelf slots are usable, the refbox manages possiblly blocked slots, there are 6 pre-stored C0 products, one for each configuration, each on a different shelf. We still have to specify the associated costs for operations.

To quote the PR of the refbox repo:

There are 4 dfferent types of costs:

• each retrieval, relocation and storage has some costs attached
• each stored products induces costs each minute

Costs can be limited as follows:

• The accumulated costs from all the four sources can be capped
• the cost per minute can be capped to a max number of payments
• A grace period for free storage time for each stored product can be used

We already agreed on making the usage costs small to begin with, so we can certainly disable some of these costs/functions if we like.
Goal of this Issue is to come up with values for:

1. retrieveal costs

2. storage costs

3. relocation costs

4. store-per-volume-per-minute costs

5. grace-period time of free time before costs per minute starts (per product)

6. max cost per minute per product

7. max accumulated costs

8. Also we should decide whether pre-stored products also produce costs over time or not or if something else applies.

Instead of awarding extra points to the last ring of each product, those points may as well be added to the delivery points. This way, each individual ring mount scores a number of points that is only dependent on its color complexity. Also, the delivery as the most essential step gets more weight.

While reading the rules for handling, i felt there was lots of room for interpretation:

A few things that cought my eye:

1. Should workpieces at the input side be removed as well? This is how we handled it in practice, but the following formulation could imply that it only holds for workpieces that were processed already:

Any production that was running will be aborted and any product which was being processed is no longer available and will be removed by the referee.

2. What mps interactions are allowed during broken time (if any)? The rule states that

The machine cannot be used for 30 seconds and until repaired

Is it allowed to use a shelf of a broken CS? Does placing something on the conveyor belt (after eventual cleanup of already placed workpieces) of a machine count as using this machine? As a followup, if this is not allowed consider adding instructions to resolve this (e.g., all workpieces placed on the belt of a machine during downtime are removed, workpieces picked from a broken machines shelf are removed from the gripper by a referree).