robocup-logistics / rcll-refbox Goto Github PK

Replace the communication to the MPS machines with a OPC-UA communication based on open62541.

For testing, use the mockup developed in robocup-logistics/rcll-mps-stations#1.

Implement competitive orders as described in robocup-logistics/rcll-rulebook#14.

• Generate one competitive C0 order in every game
• Generate an additional C0 order in over-time
• Remember if a delivery has happened for a competitive order
• Adapt scoring
• Indicate competitive orders in shell

When restarting a game, with random field turned off, the ring colours of the ring station get randomized non the less.
This delays a restart, since the referees have to rearrange all rings.

According to the rules, the points for feeding in bases into a RS should be deducted if the RS is reset. Currently, the points are not deducted.

The default config now is configured to no longer have mockup connection mode configured for the mps.
If you just start the RefBox without any MPS stations to connect to, your CPU gets fried, this is probably avoidable.

Hi,

I checked the dockerhub today (https://hub.docker.com/r/robocuplogistics/rcll-refbox/tags?page=1&ordering=last_updated) and there is no version for the challanges refbox, can someone who has access right upload it? I guess that would be a nice.
If someone adds me to the Dockerhup I would also do it myself.

Thanks a lot,
Peter

Current CircleCI builds on Ubuntu do not include MongoDB support. Since this is crucial during tournaments, and we may end up with a Ubuntu machine, build with MongoDB integration. Probably requires extended the prerequisites?

When using the tool rcll-prepare-machine, I can observe old prepare messages being processed in the refbox quite frequently. As an example:

1. ./rcll-prepare-machine Carologistics C-CS1 RETRIEVE_CAP: machine is prepared as expected and processes the workpiece successfully
2. ./rcll-prepare-machine Carologistics C-CS1 MOUNT_CAP: sometimes, an old prepare message reaches the refbox and it tries to process another RETRIEVE_CAP, which breaks the machine.

Another example:

1. ./rcll-prepare-machine Carologistics C-CS1 RETRIEVE_CAP: machine is prepared as expected and processes the workpiece successfully
2. ./rcll-prepare-machine Carologistics C-CS2 RETRIEVE_CAP: (note that I'm preparing C-CS2). Both machines are prepared, C-CS1 breaks because it's already holding a cap.

In both cases, it seems like an old message from the previous prepare is processed again. I never see this happening on the first prepare message.

I also don't see this when processing prepares from robots.

Once robocup-logistics/rcll-rulebook#1 is accepted, we no longer need a referee to manually enter a delivered order. Instead, the refbox can assign points automatically.

On each delivery to the DS, the refbox should:

1. Check whether the order exists
2. Ask the referee whether the correct product as delivered
3. If the referee confirms, compute the points and assign them to the team automatically

As discussed in TC meeting 2/19, the wiki needs to be updated to reflect the current state of the refbox.

Currently it is that the entire refbox has to be installed and compiled also if just the messages are needed (e.g. for the teams or the visualization). Is it possible to separate the rcll messages from the refbox and provide them in an independent package e.g. rcll-msgs?

Hey,

At the end of the new exploration part of the production phase it can happen that the machine positions in the ground truth messages are identical for several machines. Currently we avoid problems with some sanity checking and waiting for the groundtruth to place every machine on a different position.

Hi,

is there a possibilty to run the same game multiple times (same map, same orders, and so on). Is this planned or isn't that on the roadmap yet?

Thanks a lot,
Peter

The return type of a number of libmicrohttpd functions changed, quote from the changelog:

Wed 08 Apr 2020 10:53:01 PM CEST
Introduce enum MHD_Result for #MHD_YES/#MHD_NO to avoid using 'int' so much.
Note that this change WILL cause compiler warnings until (most) MHD callbacks
in application code change their return type from 'int' to 'enum MHD_Result'.
That said, avoiding possible confusions of different enums is going to make
the code more robust in the future. For conditional compilation, test
for "MHD_VERSION >= 0x00097002". -CG

This causes a build failure (example).

The current mockup machine behavior can cause a bug where, if the machine is set to down during a conveyor movement, READY-AT-OUTPUT is never reached.

The way points are calculated for C3 differ from the way it is done for C1 and C2 products. For both C1 and C2, points are assigned for mounting 1 and 2 rings, respectively, as well as for mounting the last ring. For C3, points for mounting rings 1 and 2 but not 3 are assigned, followed by assigning points for mounting the last ring.

I attached a logfile copied from the refbox shell for clarification.

│16:09:59.018 A: Order 4: 1 x C3 from 11:37 to 14:20
│16:09:59.021 A: Order 2: 1 x C1 from 00:00 to 17:00
│16:09:59.022 A: Order 1: 1 x C0 from 00:00 to 17:00
│16:10:22.027 A: Order 3: 1 x C2 from 11:09 to 14:01

• Here we can see, points are awarded for mounting a ring of complexity CC2
• as well as for mounting the last ring of order 2, which is a C1

│16:11:48.704 L: Sending completed order for team MAGENTA (base: BASE_RED, rings: RING_GREEN, cap: CAP_GREY)
│16:11:48.740 C: Awarding 20 points to team MAGENTA: Delivered item for order 2 (PRODUCTION @ 109.723537)
│16:11:48.741 C: Awarding 10 points to team MAGENTA: Mounted cap for order 2 (PRODUCTION @ 109.723537)
│16:11:48.741 C: Awarding 10 points to team MAGENTA: Mounted last ring for complexity C1 order 2 (PRODUCTION @ 109.723537)
│16:11:48.741 C: Awarding 20 points to team MAGENTA: Mounted CC2 ring of CC2 for order 2 (PRODUCTION @ 109.723537)

• Here, for the C2 product from order 3, points are awarded for mounting
• rings 1 (CC0) and 2 (CC2), respectively. Also, points for mounting the
• last ring are awarded.

│16:21:41.869 L: Sending completed order for team MAGENTA (base: BASE_RED, rings: RING_YELLOW|RING_GREEN, cap: CAP_GREY)
│16:21:41.897 C: Awarding 20 points to team MAGENTA: Delivered item for order 3 (PRODUCTION @ 702.880562999996)
│16:21:41.898 C: Awarding 10 points to team MAGENTA: Mounted cap for order 3 (PRODUCTION @ 702.880562999996)
│16:21:41.898 C: Awarding 30 points to team MAGENTA: Mounted last ring for complexity C2 order 3 (PRODUCTION @ 702.880562999996)
│16:21:41.898 C: Awarding 20 points to team MAGENTA: Mounted CC2 ring of CC2 for order 3 (PRODUCTION @ 702.880562999996)
│16:21:41.899 C: Awarding 5 points to team MAGENTA: Mounted CC0 ring of CC0 for order 3 (PRODUCTION @ 702.880562999996)

• For the C3 product from order 4, points are only awarded for mounting
• rings 1 and 2, followed by awarding points for mounting the last ring.

│16:22:35.045 L: Sending completed order for team MAGENTA (base: BASE_RED, rings: RING_BLUE|RING_YELLOW|RING_GREEN, cap: CAP_GREY)
│16:22:35.057 C: Awarding 20 points to team MAGENTA: Delivered item for order 4 (PRODUCTION @ 756.040481999995)
│16:22:35.057 C: Awarding 10 points to team MAGENTA: Mounted cap for order 4 (PRODUCTION @ 756.040481999995)
│16:22:35.057 C: Awarding 80 points to team MAGENTA: Mounted last ring for complexity C3 order 4 (PRODUCTION @ 756.040481999995)
│16:22:35.057 C: Awarding 20 points to team MAGENTA: Mounted CC2 ring of CC2 for order 4 (PRODUCTION @ 756.040481999995)
│16:22:35.057 C: Awarding 5 points to team MAGENTA: Mounted CC0 ring of CC0 for order 4 (PRODUCTION @ 756.040481999995)

Hi, when we were testing the nav challange last week we noticed that two machines C-CS1 and M-CS1 where assigned the same zone. Is this on purpose or a mistake? We used the branch neltester/challanges-2021. If this is the wrong branch please tell us which one we should use. below a screenshot from the new webui.

all the best,
Peter

Compilation on Fedora 30 fails:

  --> Entering sub-directory shell ---
      --- Compiling shell.cpp (C++)
/home/thofmann/code/llsf-refbox/src/shell/shell.cpp: In member function ‘void llsfrb_shell::LLSFRefBoxShell::client_msg(uint16_t, uint16_t, std::shared_ptr<google::protobuf::Message>)’:
/home/thofmann/code/llsf-refbox/src/shell/shell.cpp:820:76: error: no matching function for call to ‘boost::posix_time::seconds::seconds(float)’
  820 |       attmsg_endtime_ = now + boost::posix_time::seconds(am->time_to_show());
      |                                                                            ^
In file included from /usr/include/boost/date_time/posix_time/posix_time_types.hpp:16,
                 from /usr/include/boost/asio/time_traits.hpp:23,
                 from /usr/include/boost/asio/basic_deadline_timer.hpp:28,
                 from /usr/include/boost/asio.hpp:24,
                 from /home/thofmann/code/llsf-refbox/src/shell/shell.h:42,
                 from /home/thofmann/code/llsf-refbox/src/shell/shell.cpp:39:
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:57:16: note: candidate: ‘template<class T> boost::posix_time::seconds::seconds(const T&, typename boost::enable_if<boost::is_integral<T>, void>::type*)’
   57 |       explicit seconds(T const& s,
      |                ^~~~~~~
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:57:16: note:   template argument deduction/substitution failed:
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp: In substitution of ‘template<class T> boost::posix_time::seconds::seconds(const T&, typename boost::enable_if<boost::is_integral<T>, void>::type*) [with T = float]’:
/home/thofmann/code/llsf-refbox/src/shell/shell.cpp:820:76:   required from here
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:57:16: error: no type named ‘type’ in ‘struct boost::enable_if<boost::is_integral<float>, void>’
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:53:30: note: candidate: ‘boost::posix_time::seconds::seconds(const boost::posix_time::seconds&)’
   53 |   class BOOST_SYMBOL_VISIBLE seconds : public time_duration
      |                              ^~~~~~~

When producing a C3 that requires two rings with color complexity 0 and one ring with higher complexity, the 5 points for color complexity 0 are only added once instead of twice. Not sure if this issue becomes obsolete in #30, as i did not have time to review it, yet.

13:33:49.048008 C: Giving 10 points to team CYAN: Mounted cap for order 2 (PRODUCTION @ 259.279909)
13:33:49.048255 C: Giving 80 points to team CYAN: Mounted last ring for complexity C3 order 2 (PRODUCTION @ 259.279909)
13:33:49.048496 C: Giving 10 points to team CYAN: Mounted CC1 ring of CC1 for order 2 (PRODUCTION @ 259.279909)
13:33:49.048741 C: Giving 5 points to team CYAN: Mounted CC0 ring of CC0 for order 2 (PRODUCTION @ 259.279909)
13:33:49.049013 C: Giving 20 points to team CYAN: Delivered item for order 2 (PRODUCTION @ 259.279909)
13:33:49.049278 C: Machine C-DS finished processing

Maybe it is worth a thought to generate the machine positions in a way, that the DSs are always in good view for the audience. Such as positioning it always on the edges of the field across from the referee table.

Once robocup-logistics/rcll-rulebook#9 is accepeted. Refbox needs to keep track of and award points for Caps Buffered at Cap stations in the according to the following flow:

1- Points are awarded when a team successfully retrieves a cap.
2- As long as the cap is buffered at the cap station, the team can potentially lose those points in the case that machine goes to a broken state (weather due mishandling or a reset msg was sent)
3- Once the cap has been mounted on a product, the team can no longer lose those points and it is counted in the final score.

The docker image currently fails to run:

$ podman run --rm --net=host robocuplogistics/rcll-refbox                                                                                                                                                                                                                                                         
06:55:26.901500 RefBox: Using 2014 machine assignment
06:55:26.916815 RefBox: Creating CLIPS environment
06:55:26.917609 Websocket: loading JSON schemas for command validation
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid

I initially thought this is because the image still uses Fedora 31, but that's not the issue. Upgrading to Fedora 32 does not fix it.

Right now the refbox sends a separate message to the Webshop to confirm an order.
This message could be replaced by checking the OrderInfo messages for the order in the Webshop backend, or some other form of confirmation.

If a machine is prepared, and immediately after that goes into DOWN state, the machine is broken after it resumes its normal operation due to no product fed in time. I think if a machine goes into DOWN state, the downtime should be added to the time allowed for feeding a product.

We tested the NavChallange today for the first time, the refbox sends only an empty route, we used the branch neltester/challenges-2021 for our testing.

Log output of the received route, one route is created but it does not contain anything. We are in the Production Phase (afaik the routes are only send during Production or?)

2021-06-03 15:25:00.089  INFO 11225 --- [       Thread-9] c.g.r.m.NavigationChallangeHandler       : Got navigationoRoutes: team_color: MAGENTA
routes {
  id: 1
}

our refbox config:

  # navigation easy
  challenges:
    enable: true
    name: "nav_easy"
    # max is 7 x 8
    field:
      width: 5
      height: 5
      # if true this effectively doubles the field size
      mirror: false
    # Phases in which the machine positions are broadcasted
    send-mps-ground-truth: []

    production-time: 1020
    orders:
      # if disabled, use default orders from rcll
      customize: false
      # each order is nvamed O<INTEGER>
      O1:
        base-color: BASE_RED
        ring-colors: [RING_BLUE, RING_YELLOW, RING_ORANGE]
        cap-color: CAP_BLACK
    publish-routes:
      enable: true
      num-points: 12
      num-routes: 1
      pause-duration: 5

The positioning of the SS is buggy. It allows the SS to be positioned such that it is facing the wall, therefore the machine is inaccessible.

Hi,

I just tried out the new version with the new config handeling, if I build the Dockerfile and then run it, the refbox crashes with a segfault.

[root@grips-simpc-left /]# llsf-refbox -h
Segmentation fault (core dumped)
[root@grips-simpc-left /]# 

@TarikViehmann can you test if this also happens for you?

Hi,
is there some kind of documentation, we noticed that now the BaseStation goes into the state RETRIVED and stays there (not going back to IDLE any more). Is this intended? All this happens in the simulation. Should it be possible to prepare the machine while it is in the RETRIVED state? Or do we have to do something to get it back to IDLE?

The machine notices that the workpiece has been picked up, so I guess the configuration for the refbox and rcll-gazebo should be fine. Even though we now have mps/enabled = true and the mps/STATION/connection = mockup. Otherwise the machines do not spawn in gazebo. We noticed that apparently there it is also a valid option to set the connection to simulation, but no idea what that does.

I am thankful for any kind of help,

regards,
Peter

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. So it's easyier to communicate with the refbox from scratch.

It may be useful to auto-confirm deliveries, e.g., when running in simulation.

Add a configuration flag that enables auto-confirmation, which automatically confirms every deliver without checking whether the correct product was delivered.

When an MPS goes DOWN while it is processing, it times out after it is back up. We have seen this at least for the CS:

I 07:32:01.502897 C: Received prepare for C-CS1
I 07:32:01.502921 C: C-CS1 is IDLE, processing prepare
I 07:32:01.502943 C: Prepared C-CS1 (RETRIEVE_CAP)
I 07:32:01.503063 C: Machine C-CS1 prepared for RETRIEVE_CAP
I 07:32:02.582809 C: Received prepare for C-CS1
I 07:32:03.063492 C: Machine C-CS1 retrieving a cap
I 07:32:20.583073 C: Machine C-CS1: move to output
I 07:32:20.583471 C: Giving 2 points to team CYAN: Retrieved cap at C-CS1 (PRODUCTION @ 567.519947000001)
I 07:32:23.062977 C: Machine C-CS1 down for 51 sec
I 07:33:14.102981 C: Machine C-CS1 is up again
E 07:34:24.063241 C: Machine C-CS1 timed out while processing
I 07:34:24.063488 MPS: Resetting machine C-CS1
I 07:34:24.063580 C: Machine C-CS1 broken: MPS C-CS1 timed out while processing
I 07:34:24.063811 MPS: Resetting machine C-CS1
I 07:34:24.063883 C: Giving -2 points to team CYAN: Deducting retrieved cap at C-CS1 (PRODUCTION @ 691.000110999995) 

See also the attached full logs:
clips.log
refbox.log

This is related to #6, but not exactly a duplicate.

Assuming that the barcode reader provides us with a workpiece ID at every MPS, keep track of the workpieces in the refbox and assign partial points for production steps according to the rules.

Hi all refbox devops,

to update the logistics league visualization for this years robocup I tried to install the refbox in a VM and had some issues with compiling the protobuf messages:
When compiling the refbox, the build of the protobuf messages fails at MachineInstructions.proto line 64/65. Here the qualifier "reserved" is not accepted, just the qualifiers "required", "optional" and "repeated".
MachineInstructions.proto:64:3: Expeced "required", "optional", or "repeated".
This is followed by some aftereffects.

The changes at this part of code were made by @morxa just a month ago. As I suggest, that the build succeded at your development, you probably used different dependecies as I. Are there new dependencies, maybe proto3, which would allow this qualifier? If yes, please update the installation guide and move it to this repo, that the teams have a chance to build the updated messages and changed refbox.

My system environment is as follows:

• Virtual Machine, Ubuntu 16.04 (64bit)
• Refbox dependencies installed along Fawkes Refbox Installation Guide; Note: At apt-get dependecies libncurses5-dev or similar is missing
• master branch of this repo

Thanks for your help!

Best regards
Florian

This was proposed by @TarikViehmann. This is useful for debugging and maintaining databases with game-specific information (For the refbox as well as the teams)

We observed that the refbox occasionally crashes when someone connects using the webfrontend.
For now this happens rarely and mostly when a particularly old laptop is hosting the refbox, but we should keep an eye on this issue.

The tool rcll-refbox-instruct as used by the gazsim script with the parameter -w sporadically ends up in a deadlock situation on some systems. The deadlock occurs in io_service_.run() on line 313 in the context of this loop:

do {
	io_service_.run();
	io_service_.reset();
} while (!quit_);

Backtrace:

#0  0x00007f17aed58d1e in epoll_wait () from /lib64/libc.so.6
#1  0x0000000000494a60 in boost::asio::detail::epoll_reactor::run (this=0x1c121f0, usec=-1, ops=...) at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:471
#2  0x0000000000495feb in boost::asio::detail::scheduler::do_run_one (this=0x1c12920, lock=..., this_thread=..., ec=...) at /usr/include/boost/asio/detail/impl/scheduler.ipp:385
#3  0x0000000000495a64 in boost::asio::detail::scheduler::run (this=0x1c12920, ec=...) at /usr/include/boost/asio/detail/impl/scheduler.ipp:154
#4  0x0000000000496541 in boost::asio::io_context::run (this=0x4e3910 <io_service_>) at /usr/include/boost/asio/impl/io_context.ipp:62
#5  0x000000000048dbf9 in main (argc=2, argv=0x7ffeec257758) at /home/dswoboda/rcll-refbox/src/tools/rcll-refbox-instruct.cpp:322

Add timeouts to the generation of field layouts to automatically trigger a new generation. Additionally, ground truths should only be sent when the generation is actually concluded.

Having a separate repo for proto messages allows all communicators (refbox, simulations, team servers, robots) to integrate that repo as a submodule.

Certain information that is integral to the correct operations of the robots of all teams (e.g. field dimensions, starting time of the game, etc.) should be broadcasted by the refbox during setup phase (or the switch to production phase) s.t. teams can have their robots automatically configured.

Example: Teams need to configure the field sizes in their navigation stacks. Having a wrong configuration might occur easily during the competition (e.g. configuration used for challenges does not apply to a full game, or the field size is changed due to local constraints). The refbox needs to know the field size in order to generate the machine positions. So the refbox might as well provide this information s.t. teams can automatically configure their navigation stack.

Implement the changes from robocup-logistics/rcll-rulebook#12:

• Allow two maintenances per bot
• Deduct 5 points for the second maintenance

Hi,

during the Exploration Phase there is the problem that a team can only check if the report of a machine was correct by observing the points. Since this is possbile, I would propose that we have a clear way of comunicating the ground trooth, best I guess is to just publish the MachineInformation on the team peer.

But I am open for other Ideas as well.

regards,
Peter

I encountered the following issue while working on an implementation for the storage station:
I started the refbox, entered the production phase (no robots connected) and used the rcll-prepare-machine tool to send machine instructions manually in order to debug my code.
My code seemed to work fine (you can find it here: https://github.com/robocup-logistics/rcll-refbox/tree/tviehmann/storage-station), but from time to time a machine would break after issuing consecutive storing operations.
I wanted to know whether it was due to the tool sending wrong stuff or it was caused by the receiving end of the protobuf communication so i added a field to the prepare message that contains the timestamp of the sender. It appears that upon sending the second message, one of the old messages arrives in clips and is processed (note that this never happens when i do a single prepare).

Here is what the rcll-prepare-machine command does:

[tarikwork@localhost bin]$ ./rcll-prepare-machine Carologistics C-SS STORE 4 0
Waiting for beacon from refbox...
Announcing machine type
prep message built with 1, 4 0
GameState received:  00:00:13.279  PRODUCTION RUNNING  0:0 points, Carologistics vs. 
Set crypto key to randomkey (cipher aes-128-cbc)
Announcing machine type
prep message built with 1, 4 0
MachineInfo received:
  C-RS1, state: IDLE
  C-DS, state: IDLE
  C-BS, state: IDLE
  C-CS2, state: IDLE
  C-CS1, state: IDLE
  C-RS2, state: IDLE
  C-SS, state: PROCESSING
[tarikwork@localhost bin]$ ./rcll-prepare-machine Carologistics C-SS STORE 4 1
Waiting for beacon from refbox...
Announcing machine type
prep message built with 1, 4 1
GameState received:  00:00:45.920  PRODUCTION RUNNING  0:0 points, Carologistics vs. 
Set crypto key to randomkey (cipher aes-128-cbc)
Announcing machine type
prep message built with 1, 4 1
GameState received:  00:00:49.920  PRODUCTION RUNNING  0:0 points, Carologistics vs. 
MachineInfo received:
  C-RS1, state: IDLE
  C-DS, state: IDLE
  C-BS, state: IDLE
  C-CS2, state: IDLE
  C-CS1, state: IDLE
  C-RS2, state: IDLE
  C-SS, state: BROKEN

Here is the refbox log (the timestamp of the message shown converts to 4:45:02.500 PM so it refers to the first attempt of preparation)

I 16:45:01.539741 C: Received prepare for C-SS
I 16:45:01.540323 C: C-SS is IDLE, processing prepare                           
I 16:45:01.541330 C: Machine C-SS prepared for STORE                            
I 16:45:02.542987 C: Received prepare for C-SS                                  
I 16:45:06.983291 C: Machine C-SS finished storage at (4, 0)                    
I 16:45:06.984939 C: Machine C-SS finished processing                           
I 16:45:08.260396 MPS: Resetting machine C-SS                                   
I 16:45:09.740395 C: Received prepare for C-SS                                  
I 16:45:09.740602 C: C-SS is IDLE, processing prepare                           
I 16:45:09.741353 C: Machine C-SS broken: Prepare received for C-SS with STORE operation for occupied shelf slot (4, 0), recv 1598539502500
I 16:45:09.741829 MPS: Resetting machine C-SS   

And here is the clips log when the old protobuf message arrives note how it is processed directly after it arrives (the production-machine-prepare rule causes the printout with the timestamp in the above refbox log):

D 16:45:09.703800 C: ==> f-2048  (protobuf-msg (type "llsf_msgs.PrepareMachine") (comp-id 2000) (msg-type 101) (rcvd-via BROADCAST) (rcvd-from "127.0.0.1" 4441) (rcvd-at 1598539509 703661) (client-type PEER) (client-id 1953722218) (ptr <Pointer-5-0x7f2c580016b0>))
D 16:45:09.738501 C: FIRE    2 ws-update-gamestate: f-2050                      
D 16:45:09.740317 C: FIRE    5 production-machine-prepare: f-2050,f-2048,f-213  
D 16:45:09.740355 C: <== f-2048  (protobuf-msg (type "llsf_msgs.PrepareMachine") (comp-id 2000) (msg-type 101) (rcvd-via BROADCAST) (rcvd-from "127.0.0.1" 4441) (rcvd-at 1598539509 703661) (client-type PEER) (client-id 1953722218) (ptr <Pointer-5-0x7f2c580016b0>))
D 16:45:09.740857 C: <== f-1956  (machine (name C-SS) (team CYAN) (mtype SS) (actual-lights GREEN-ON) (desired-lights GREEN-ON) (productions 0) (state IDLE) (prev-state IDLE) (task nil) (mps-busy FALSE) (mps-ready FALSE) (proc-time 0) (proc-start 33.280192) (down-period -1.0 -1.0) (broken-since 0.0) (broken-reason "") (pose 0.0 0.0 0.0) (pose-time 0 0) (zone C_Z68) (rotation 0) (prep-blink-start 14.559444) (idle-since 33.280192) (wait-for-product-since 11.519568) (mps-base-counter 0) (bases-added 0) (bases-used 0) (bs-side INPUT) (bs-color BASE_RED) (ds-gate 0) (ds-last-gate 0) (ds-order 0) (ss-operation STORE) (ss-shelf-slot 4 0) (rs-ring-color RING_BLUE) (rs-ring-colors RING_GREEN RING_BLUE) (cs-operation RETRIEVE_CAP) (cs-retrieved FALSE))
D 16:45:09.740918 C: ==> f-2053  (machine (name C-SS) (team CYAN) (mtype SS) (actual-lights GREEN-ON) (desired-lights GREEN-ON) (productions 0) (state BROKEN) (prev-state IDLE) (task nil) (mps-busy FALSE) (mps-ready FALSE) (proc-time 0) (proc-start 33.280192) (down-period -1.0 -1.0) (broken-since 0.0) (broken-reason "Prepare received for C-SS with STORE operation for occupied shelf slot (4, 0), recv 1598539502500") (pose 0.0 0.0 0.0) (pose-time 0 0) (zone C_Z68) (rotation 0) (prep-blink-start 14.559444) (idle-since 33.280192) (wait-for-product-since 11.519568) (mps-base-counter 0) (bases-added 0) (bases-used 0) (bs-side INPUT) (bs-color BASE_RED) (ds-gate 0) (ds-last-gate 0) (ds-order 0) (ss-operation STORE) (ss-shelf-slot 4 0) (rs-ring-color RING_BLUE) (rs-ring-colors RING_GREEN RING_BLUE) (cs-operation RETRIEVE_CAP) (cs-retrieved FALSE))

If an early delivery happens, there are 0 points awarded for the whole product. Shouldn't the production points be awarded and just all 20 delivery points deducted?

At least if we have intermediate points it would be the case anyhow that you get points for any work-task and just not get any points for the delivery since it was too early.

Maintainance via UI kills the refbox.

If an order is delivered late, then no points are given for mounting the cap.

According to the rules, points for a mounted cap should be given immediately, even if the final product is not delivered. We cannot do this, as we cannot detect whether the correct cap was mounted. For this reason, we give the points for the cap mount only on delivery of the product. However, if the delivery is late, the points for the cap should still be given.

When the Refbox is configured to load the stored machine positions from MongoDB (e.g. to have the same setup for testing purposes), it can occur that there is a mismatch between the ring-colors and the colors at the RS, leading to the error Machine XYTZ broken: Prepare received for XYZ for invalid ring color (ABC). The problem results in extremely low scores in some scenarios. Attached are two logs that examplify the problem.

refbox.log
refbox.log

Running the refbox in a container currently results in a high CPU load, as the AvahiThread uses 100% CPU. This is also the reason why the container images is built without Avahi support:

However, this doesn't solve the underlying issue. Also, when installing the refbox in a container, e.g., using the refbox COPR, the issue appears again.

In order to integrate the Storage Station into the League we will need to discuss the interface.
Preferably it would look something like this:

• ActionId for Store, Retrieve, Reset
• Data[0] for each storing shelf (0-5)
• Data[1] for each slot in a shelf (0-7)

Band Actions remain the same as CS,RS