Support for Windows

[omichel]

An effort to port AIWC simulation to Windows is being conducted at https://github.com/omichel/test_world. Basically, the communication system between the simulation supervisor and competitor code was changed. The supervisor was ported to Python and uses a simplified network protocol without any dependency on boost or bonefish libraries. This issue lists all the remaining problems and bugs that need to be fixed to complete the support for Windows:

• [x] 1. Commentator and Reporter APIs: Fixed by @stefaniapedrazzi.

• [x] 2. The Python supervisor does not transfer image frames to the participant programs (also image_buffer.cpp/hpp is not in Python counterpart). Fixed by @davidmansolino.

  • [x] 2.1 It looks like the image received is not updated accordingly but constantly printing the initial image (Also, I think it would be better to use cv2 instead of PIL because cv2's imshow can update images on single window while PIL's imshow creates a new window per each frame)

• [ ] 3. C++ participant example program is missing.

  • [x] 3.1 player_random-walk_py was converted to C++ by @davidmansolino,
  • [ ] 3.2 @chshong will implement rest of C++ examples from there.

• [x] 4. Robot positions reset are not matched to the formations. Fixed by @chshong.

• [x] 5. The sample participant program is not working as intended: If the program is correct, F2 robot should move toward and kick the ball to initiate the kickoff. Instead, F2 robot seems to move away from the ball (it seems like it is highly possible that either incorrect position/orientation data are sent to the participant or the wheel speeds sent from the participant programs are not applied to the robots correctly. Fixed by @omichel.

• [x] 6. The key string is not used in validation of the participant programs' credentials. The only place the key is used is in Line 171. Since this only checks if the key is same with Team RED's key, the commentator and the reporter will be able to control Team BLUE's robots if they use 'aiwc.set_speeds'. In the cpp program, 'aiwc.set_speeds' can only be used by red and blue participants, 'aiwc.comment' by commentator, and 'aiwc.report' by reporter. Fixed by @stefaniapedrazzi .

• [x] 7. Rules do not seem to be applied accordingly.

  • [x] 7.1 Sometimes all robots are sent out to the foul area at the same time (I observed this when I manually moved the ball to a goalpost. After the game reset, all robots were sent to the foul zone). Assigned to @stefaniapedrazzi.
  • [x] 7.2 When the ball is sent out to the corners, the game crashes instead of starting a corner kick. Fixed by @stefaniapedrazzi.
  • [x] 7.3 When the ball is in blue team's penalty area and more than 3 blue robots are in the area, a penalty kick should start, but the game crashes. Fixed by @stefaniapedrazzi.
  • [x] 7.4 When the ball is send out to the corners, the game is restarted in the wrong corner. Assigned to @stefaniapedrazzi.
  • [x] 7.5 Deadlock does not happen even if the ball stayed still for more than DEADLOCK_DURATION_MS.
  • [x] 7.6 The game ends 0.01 seconds late.
  • [x] 7.7 In goal kick, penalty kick, and corner free kick cases, the robots do not seem to be unlocked when the movable robot touches the ball (the condition for unlocking all robots is either 1) the movable robot touches the ball, and 2) the ball is not touched for (rule)_TIME_LIMIT_MS seconds. (additional note: touch sensory information does not seem to be working)
  • [x] 7.8 In goal kick, penalty kick, and corner free kick cases, the robots are not stopped and frames are sent to the participants continuously (easily can be seen by checking the comments the commentator makes when a goal happens in one of these cases). (probably this is tied to issue 7.7 since whenever the ball is moving, the game state would be in STATE_DEFAULT)

• [x] 8. The timestamp (one updated by update_label()) is not updated in real time but once in a second. Fixed by @chshong.

• [x] 9. 'address already in use' error seems to happen occasionally. Fixed by @stefaniapedrazzi.

  • [x] 9.1 'address already in use' error still happens (seems like happening only on Linux). The error seems to happen when Webots simulation is reloaded/reset in middle of a game. The cause seems to be the player programs becoming zombie processes when the game is terminated in middle. Can the supervisor force the player programs to be terminated when reload/reset happens? @michel cannot reproduce this bug on the current develop branch.
  • [ ] 9.2 When using C++ participant programs, issue similar to 9.1 is still happening (found on Linux). The participant programs become zombie processes (yet they do not cause 'address already in use' error. They just slow down the PC) when the game is terminiated in middle. Can you investigate on this issue? @omichel

• [x] 10. reset_reason messages are sent to the client programs multiple times instead of just one. Fixed by @stefaniapedrazzi.

• [x] 11. frame messages sent could be concatenated and truncated when reading them from the socket buffer in the client program. Fixed by @stefaniapedrazzi and @DavidMansolino.

• [x] 12. Remove the dependency on boost from the soccer_robot controller. Fixed by @omichel.

• [x] 13. 'data path' not handed over to AI Soccer programs. Fixed by @stefaniapedrazzi.

• [x] 14. The simulation runs slower than when C++ controllers were used (with C++ controllers, the simulation usually ran in x1.0. with Python controllers, the simulation runs in about x0.66). Simulation not running in real-time can greatly affect participant programs since the simulation should be asynchronous. (additional note: This looks like a bug. The simulation returns to x1.0 speed when a goal is made and game is resumed. Only the "beginning->first goal of the game" segment is slowed down) (additional note 2: The issue looks more severe on Windows. The simulation speed even drops to about x0.33. The simulation returns to normal speed just like on Linux after a goal is made.). Fixed by @omichel.

• [x] 15. The reporter's report is not received by the supervisor.

• [x] 16. Participant programs seem to start operate 0.2-0.5 seconds (in simulation game_time) after the game begins. This can be seen by the timestamp put on the comments and the robots not moving for about first 0.2-0.5 seconds. Fixed by @omichel (note: after fixing 14, I could not reproduce this problem).

• [ ] 17. The supervisor does not start or terminate the game after WAIT_READY_MS seconds have passed when one of programs does not send aiwc.ready. If at least two AI Soccer participants are ready, the supervisor should drop not responding commentator/reporter and start the game. If any of AI Soccer participant was not ready within WAIT_READY_MS seconds, the game should be terminated.

• [x] 18. The goalkeeper behavior of rulebased when put on Team B seems to imply that the team acts as if they are located on left in view of spectators. The data sent to Team B should be rotated by 180 degrees.

• [x] 19. When the supervisor launches the participant program, it ignores the shebang on Linux. (Although the shebang specified python3, the python launched is python2 - can be checked by print(sys.version))

• [ ] 20. The supervisor publishes frames 10 ms period (basic time step) instead of 50 ms period (PERIOD_MS). (In the C++ AIWC system, we have game::step(std::size_t ms) method to be used instead of directly using Webots' supervisor step method.) This mismatch between the basic time step and supervisor step was an intended one so that the simulator can have more continuous simulation (such as minimizing the chance for the ball to pierce through robots due to the simulation step being too large) while the participants can control the robot with 50 ms period (50 ms is the control period of real AI Soccer robots).

• [ ] 21. The comments made by commentator are handled bit delayed. When a goal is made, the commentator's "Team Red Scored!!" message was shown immediately in C++ system. In current Python system, the message is displayed only after the field is reset and the game resumes. (I checked that the commentator program receives the frame as soon as the goal is made. However, when the commentator program sends the comment to the supervisor, callback(self, client, message) method is called after the game resumes instead of before the game goes in halt.)

• [ ] 22. In the game_info json, unnecessary information are handed over to the participants (team_info and key). In the case of 'key', TeamA's key is distributed to the commentator and reporter in game_info that this makes a door for the commentator and reporter algorithms to masquerade as Team A.

[chshong]

Currently the rulebased python example is not working (robots do not move at all and "Error: participant.py: Invalid JSON object." message is displayed many times). Is this an issue tied with 11?

[stefaniapedrazzi]

Yes. This message is displayed when the received frames cannot be handled correctly because they are truncated.

It is very likely that fixing the main loop in supervisor.py (related to issues 10. and 7.) will also fix this issue.

[chshong]

In compiling the C++ example program (which seems to use Unix headers), should I use MSYS environment? Could there be an easier way to compile on Windows?

[DavidMansolino]

Using MSYS should indeed fix the problem (can you confirm that please?). We can write a Makefile so that it will be possible to use Webots to compile the program, would this be fine for you?

[chshong]

I am not sure how I can use cmake on MSYS console to generate makefile and build the program. I used MinGW64 console, cmake -G "MSYS Makefiles", make and the result says it cannot find "arpa/inet.h"

[chshong]

and yes, if we can build the program using Webots + makefiles, it would be more convenient for the participants

[stefaniapedrazzi]

I will also fix 13. 'data path' not handed over to AI Soccer programs.

[DavidMansolino]

and yes, if we can build the program using Webots + makefiles, it would be more convenient for the participants

I will add a makefile in #8

[omichel]

I believe all the major issues are now fixed. @chshong: can you test it? I will investigate 9.1 now.

[chshong]

[supervisor]   File "supervisor.py", line 1368, in <module>
[supervisor]     controller.run()
[supervisor]   File "supervisor.py", line 918, in run
[supervisor]     self.tcp_server.spin(self)
[supervisor]   File "supervisor.py", line 109, in spin
[supervisor]     game_supervisor.callback(s, data.decode())
[supervisor]   File "supervisor.py", line 245, in callback
[supervisor]     speeds = [float(i) for i in speeds.split(',')]
[supervisor] ValueError: could not convert string to float: 
WARNING: 'supervisor' controller exited with status: 1.

I got this error when I ran the simulation right after the start. Could it be only happening on Linux?

[omichel]

Are you using Python 2?

[chshong]

Yes I do, we currently support both Python 2 and 3.

[omichel]

I see, it's probably a Python 2 issue. I will investigate and try to fix it.

[omichel]

Meanwhile can you test with Python 3?

[omichel]

I just tested on a fresh Ubuntu 18.04 with Python 2.7.15+, Webots R2019b and the current version of AIWC from https://github.com/omichel/test_world and I don't get any error. The rulebased-B python program seems to work fine and is able to score goals. I get no error. Can you try again and let me know?

[chshong]

I have tried again with print commands to locate the issue. It seems like the message is sometimes not a complete message as can be seen below (role: True means Team Red - rulebased-B and False means Team Blue - random-walk). It looks like the connection between the supervisor and participant programs is not stable. I ran the same setting several times and observed that the program sometimes run correctly but crashes like below occasionally.

Case 1

[supervisor] Traceback (most recent call last):
[supervisor]   File "supervisor.py", line 1369, in <module>
[supervisor]     controller.run()
[supervisor]   File "supervisor.py", line 919, in run
[supervisor]     self.tcp_server.spin(self)
[supervisor]   File "supervisor.py", line 109, in spin
[supervisor]     game_supervisor.callback(s, data.decode())
[supervisor]   File "supervisor.py", line 246, in callback
[supervisor]     speeds = [float(i) for i in speeds.split(',')]
[supervisor] ValueError: could not convert string to float: -
[supervisor] ('Role: ', False, ' Message received to split: ', u' 0.793643353317, 1.73699993703, 1.27201089653, 1.92776450033, 1.78566228763, 1.35845655587, 1.60706625009, -1.53683277559, -1.05533897153, 2.46122045843')
[supervisor] ('Role: ', False, ' Message received to split: ', u' -0.817598474881, -0.393538677105, 1.18629227742, -0.619832761918, 0.117035903087, 0.47500720918, 1.2700671649, -0.160436069376, -1.32681555854, -0.164168912824')
[supervisor] ('Role: ', False, ' Message received to split: ', u' -0.639982528729, -1.35098411394, 1.34600229547, -0.368081583583, 1.87518300798, -0.50845565348, -1.37320663802, 0.628441467972, -1.94345325374, 2.44777278243')
[supervisor] ('Role: ', False, ' Message received to split: ', u' -0.973450556943, -1.71392057337, -0.619133167566, 1.92882713395, -0.224762435429, -0.324615712064, 1.17314159236, 0.922825288809, 0.708797863002, 2.53989859372')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 0.780658625474, -0.325832405436, -0.8135886439, -0.606678106332, -0.502235162816, 0.444931243152, -0.248071414388, 0.30581451815, -0.642865722686, 2.00835645537')
[supervisor] ('Role: ', False, ' Message received to split: ', u' -1.11873367099, 0.785748591479, -2.05673863084, -1.59483426861, -0.969473648258, -1.25016702781, 0.847111090582, -1.96018073931, -2.51587674958, 0.682503499166')
[supervisor] ('Role: ', False, ' Message received to split: ', u' -0.419485746728, -0.0319858246695, -1.77358043943, 1.00328971313, 1.95778536801, -2.0572219908, -0.932080716535, -0.608885006187, 1.30274862599, -1.94488123926')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 0.0827961125212, 0.554252553553, 1.94330854372, 1.00879318018, 0.444503189964, 2.07985308256, 0.169269125297, -2.09621564773, 2.44216669789, 0.965941705581')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 1.06618804039, -1.66816245, 1.81840687986, 0.393160382621, 1.74676440302, 0.585275658503, -1.78742813051, -0.949271592013, 1.0295763781, -0.740713480369')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 1.32648243264, 0.55491002429, 1.37135599021, 1.64693229387, -0.0357995999925, -1.226279594, 1.03443960592, -2.53408267526, -0.36526753254, 0.97058134599')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 0.230363242053, 0.0703741957169, -1.02956955406, -1.58986865097, 0.0194498267489, 0.700593293756, -2.2852464126, -1.66305177744, -0.332459052181, -0.212916196843')
[supervisor] ('Role: ', False, ' Message received to split: ', u' -1.62740120963, -0.558982552721, 0.530678208966, 1.36576550916, 2.05116839375, -1.68022576365, 1.01413767207, -2.27318566747, 2.19643955378, 2.16832816994')
[supervisor] ('Role: ', False, ' Message received to split: ', u' -1.75941719357, 0.898341806637, 0.719696732856, 0.178484895717, -1.38100472714, -1.31552511097, 0.101119956659, -1.89269978533, 1.0903918208, -0.083480102348')
[supervisor] ('Role: ', False, ' Message received to split: ', u' -0.667188065938, 1.52189298325, -1.63641553505, -1.13982990476, -0.247805095905, -0.215667483055, -0.651729077249, -0.634010672381, 1.65210782759, -2.29610389852')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 1.02152199776, -0.157363339322, 0.272790214923, 1.59241899118, 1.38870210434, -0.00105461563213, -2.28940456024, -0.206344324666, 0.970801535492, 2.00985649759')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 0.354643172393, 1.70120638754, -0.485606287044, 0.63607505375, 0.530184231488, 1.34844453733, -1.17251230846, -0.263329510026, 2.36740538983, -1.40560591411')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 1.10735529266, -0.255259984149, 1.29701335573, -0.330659746428, 0.816597920375, 1.31280468144, -1.31547680499, 1.20741556326, 2.54567273037, 1.82020399588')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 0.189366127109, 0.559617266816, 2.08637022089, 0.162724875244, -1.80836078853, 2.09152818593, -0.271419824961, 0.21667935124, 0.753593356563, -0.863779898916')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 0.627802283463, 1.38720503327, 1.33671704783, 0.640127816009, -0.0475528004774, 1.57586440211, 0.760461140838, 0.83424923228, 0.963475665358, -0.0683017415056')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 1.55254677323, 1.73375627809, -0.706542320656, 0.688692850404, -0.20193947549, -1.18375680517, 0.797138838188, 2.29814918992, -1.66270382781, 0.0792566738189')
[supervisor] ('Role: ', False, ' Message received to split: ', u' 1.74339131038, 0.387537079014, 0.107985686577, -1.30571109527, -0.211342823655, -1.71119808353, -0.413665098827, 0.983137134522, -0.224752120308, -0.829281181583')
[supervisor] ('Role: ', False, ' Message received to split: ', u' -0.487182343644, -0.571924232064, -0.273997151894, 0.721396168378, 0.563313602419, 1.23103156146, -0.994349832276, -')
WARNING: 'supervisor' controller exited with status: 1.

Case 2

[supervisor] Traceback (most recent call last):
[supervisor]   File "supervisor.py", line 1369, in <module>
[supervisor]     controller.run()
[supervisor]   File "supervisor.py", line 919, in run
[supervisor]     self.tcp_server.spin(self)
[supervisor]   File "supervisor.py", line 109, in spin
[supervisor]     game_supervisor.callback(s, data.decode())
[supervisor]   File "supervisor.py", line 246, in callback
[supervisor]     speeds = [float(i) for i in speeds.split(',')]
[supervisor] ValueError: could not convert string to float: 
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75806660849, 1.75806660849')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75806660849, 1.75806660849')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75771940501, 1.75771940501')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75736702824, 1.75736702824')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75730832176, 1.75730832176')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75725866073, 1.75725866073')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75721644873, 1.75721644873')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75718056834, 1.75718056834')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75715006998, 1.75715006998')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75712414642, 1.75712414642')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75710211151, 1.75710211151')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75708338198, 1.75708338198')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75706746203, 1.75706746203')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75705393023, 1.75705393023')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75704242835, 1.75704242835')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75703265188, 1.75703265188')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75702434202, 1.75702434202')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75701727875, 1.75701727875')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75701127508, 1.75701127508')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75700617205, 1.75700617205')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75700183455, 1.75700183455')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75699814775, 1.75699814775')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75699501403, 1.75699501403')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75699235042, 1.75699235042')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75699008639, 1.75699008639')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75698816201, 1.75698816201')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75698652632, 1.75698652632')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75698513602, 1.75698513602')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75698395428, 1.75698395428')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75698294983, 1.75698294983')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75698209606, 1.75698209606')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75698137037, 1.75698137037')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75698075355, 1.75698075355')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75698022926, 1.75698022926')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697978363, 1.75697978363')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697940485, 1.75697940485')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697908289, 1.75697908289')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697880923, 1.75697880923')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697857663, 1.75697857663')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697837892, 1.75697837892')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697821087, 1.75697821087')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697806803, 1.75697806803')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697794662, 1.75697794662')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697784343, 1.75697784343')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697775571, 1.75697775571')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697768115, 1.75697768115')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697761778, 1.75697761778')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697756392, 1.75697756392')
[supervisor] ('Role: ', True, ' Message received to split: ', u' 0, 0, 0, 0, 0, 0, 0, 0, 1.75697751814, 1.75697751814')
[supervisor] ('Role: ', True, ' Message received to split: ', u'')
WARNING: 'supervisor' controller exited with status: 1.

[omichel]

:eyes: (I suspect that a message from a socket is not fully read in some cases, I will try to reproduce and fix this)

[omichel]

I assume this happens on Linux with Python 2.7, right?

[chshong]

Yes, my testing environment was Ubuntu 16.04, Python 2.7

[omichel]

I believe I fixed the problem here: https://github.com/omichel/test_world/pull/14 Can you check it and approve the PR if that works for you as well?

[chshong]

This maybe an unrelated issue but I keep getting below message even when I change the shebang of supervisor.py to #!/usr/bin/python3

[supervisor] DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of Webots will drop support for Python 2.7.

Does Webots print the message regardless of the Python version using?

[chshong]

Can you make a working example of image-fetch in python? It seems like simply migrating the old example to new example does not work. Are the contents of 'subimages' sent by the supervisor different from the old one?

[DavidMansolino]

Can you make a working example of image-fetch in python? It seems like simply migrating the old example to new example does not work. Are the contents of 'subimages' sent by the supervisor different from the old one?

The format is similar (same base64 encoding and same sub-image resolution) however, it is encoded in a JSON string. I will create a simple image-fetch example in python.

[omichel]

Webots is ignoring the shebang line in controller programs. Rather, it is using the python version specified in the Webots preferences, regardless of the shebang. So, if the Webots preferences specify python2, it will use python2 even though the shebang request python3. We could possibly fix that in Webots, but it will be integrated only in the next version.

[chshong]

Okay, I think I should notify this along with AIWC simulation program distribution since the message may confuse the participants

[DavidMansolino]

It may be possible to force the use of python3 using a runtime.ini file close to the controller: https://cyberbotics.com/doc/guide/controller-programming#languages-settings

[omichel]

About the speed of execution, we investigated but found that webots uses 90% of the CPU of one core while the python controllers use about 15% of the CPU on another core. Therefore, the Python controllers are not the performance bottleneck. So, I don't understand why you get such a bad performance with the python controller. Can you provide more detail about your configuration (operating system, Python version, number of CPU cores, graphics card, etc.)? Thank you.

[chshong]

My OS: Ubuntu 16.04, Windows 10 (the issue happens on both) Python version: 2.7.12, 3.7.3 (the issue happens on both) CPU Cores: 8 GPU: GTX1080ti

However, I believe this is an issue happening inside the supervisor controller because the simulation slows down at the beginning of the game only and returns to normal speed when a goal happens and the field is reset. Regardless of when the first goal happened, the speed returned to normal so I think the issue is happening due to some part of the initialization of the system that are reset when a goal happens.

p.s. from tomorrow until upcoming Sunday, I am on a vacation that I would not be able to respond

[omichel]

We just fixed the support of Python shebang here: https://github.com/omichel/webots/pull/800.

[omichel]

We just fixed the performance problem you reported (14) here: https://github.com/omichel/test_world/pull/16

[omichel]

We just fixed the time of the end of the game (7.6) here: https://github.com/omichel/test_world/pull/17.

[omichel]

We cannot reproduce 9.1 on Linux. So I will consider it's fixed unless you can still reproduce the problem.

[chshong]

Now I am back on work.

Regarding issue 9.1, I think this issue was fixed when commit 2cec48 happened.

Other fixes, I will check from now and get back to you if I find something

[chshong]

About issue 2.1, replacing PIL to cv2 is simple as below

Replace from PIL import Image to import cv2

Replace

            for j in range(h):
                for k in range(w):
                    self.ImageBuffer[j + y, k + x, 0] = image[j, k, 2]  # red channel
                    self.ImageBuffer[j + y, k + x, 1] = image[j, k, 1]  # green channel
                    self.ImageBuffer[j + y, k + x, 2] = image[j, k, 0]  # blue channel
        # Uncomment this part to display the image
        img = Image.fromarray(self.ImageBuffer, 'RGB')
        img.show()

to

            for j in range(h):
                for k in range(w):
                    self.ImageBuffer[j + y, k + x, 0] = image[j, k, 0]  # blue channel
                    self.ImageBuffer[j + y, k + x, 1] = image[j, k, 1]  # green channel
                    self.ImageBuffer[j + y, k + x, 2] = image[j, k, 2]  # red channel
        # Uncomment this part to display the image
        cv2.imshow('image', self.ImageBuffer / 255.0)
        cv2.waitKey(1)

[DavidMansolino]

Yes indeed, since the buffer is a numpy buffer, it should be directly compatible with opencv.

[chshong]

I added general_check-variables_py example to this branch. This program can be useful in debugging data managements as it prints all value based items the participant program receives.

[omichel]

About (19): only the nightly build version of Webots takes into account the shebang on Linux. Webots R2019b doesn't. Can you test with a nightly build and confirm?

[chshong]

@omichel I just tested with the cpp version of the aiwc system and confirmed that the shebang is taken into account. Shouldn't it be taken into account on the participant programs since they are run as child processes run separately from the supervisor which is directly launched by Webots?

(I put shebang of one example to use python2 and the other to use python3)

[supervisor] 2019-08-22T10:13:36+0900 I am the reporter for this game!
[supervisor] 3.5.2 (default, Nov 12 2018, 13:43:14) 
[supervisor] [GCC 5.4.0 20160609]
[supervisor] 2019-08-22T10:13:36+0900 I am ready for the game!
[supervisor] 2019-08-22T10:13:36+0900 I am the commentator for this game!
[supervisor] Starting a new game
[supervisor] 2.7.12 (default, Nov 12 2018, 14:36:49) 
[supervisor] [GCC 5.4.0 20160609]
[supervisor] 2019-08-22T10:13:42+0900 I am ready for the game!

[omichel]

You are right. I misread (19), unlike previous versions, the new version of Webots actually takes into account the shebang to start Webots controllers. But what you report is about the Python supervisor starting participant programs ignoring the shebang. I will investigate this problem now.

[omichel]

I just proposed a fix for (19) in https://github.com/omichel/test_world/pull/22. Can you review it and approve it if that works for you?

[DavidMansolino]

I can indeed reproduce the issue 2.1, that's very strange because at some point it was working fine, I will fix it and try to switch to opencv instead of pil.

[DavidMansolino]

The issue 2.1 is caused by omichel/test_world#16, if I remove this patch then it works fine:

[DavidMansolino]

2.1 should now be fixed, @chshong can you please confirm it is now working for you too?

[chshong]

@DavidMansolino Yes the images are updated accordingly. However, 1) Currently the R channel and B channel in the numpy buffer are flipped 2) Please leave the imshow() part uncommented so that the participants can see the image directly when the program is run without any edits.

[DavidMansolino]

1. Currently the R channel and B channel in the numpy buffer are flipped
2. Please leave the imshow() part uncommented so that the participants can see the image directly when the program is run without any edits.

This is now fixed in omichel/test_world#25

[chshong]

@omichel Can you give @lfelipesv permissions to make changes on Python porting fork? He will join us reviewing this work from this Wednesday or Thursday.

[omichel]

Done. I just added @lfelipesv as a developer on our repo.

[chshong]

Issue 7.8 seems to be still existing, I will investigate this more and reply back

nevermind

[chshong]

Regarding the image data sent from supervisor to participants, does the supervisor send image with RGBA channels instead of RGB channels? If so, how should the supervisor be changed to make the supervisor send RGB image instead of RGBA image? This is because since the AIWC system does not use the alpha channel, it would be more efficient to send RGB only.

Also, can you check the C++ general_image-fetch example pushed here? It currently has two issues. 1) The program cannot be compiled with Makefile & Webots combination (probably library path with opencv libraries are not handled correctly in the Makefile). 2) The received data look correct, but how the received image is displayed on the screen implies the pixel data order is not handled correctly (I copied the image handling method from general_image-fetch_cpp of old example so it can be possible that the data order was changed when the supervisor system was ported to python version)

[DavidMansolino]

Yes, the supervisor does indeed send RGBA channels, this is done for efficiency reason, on the supervisor side we do send all the image in a bulk, this avoid having to loop through each pixels and therefore speedup the sending of images (we do indeed send a bit more data, but this is still more efficient than having to loop through each pixels).

I will check your C++ general_image-fetch example.