Welcome to the community! I'm not sure if I followed you correctly. At one point, I think you're talking about something like this:
However, in the beginning you mention "one same external experiment server", which you might mean:
In both scenarios, there is one variable in the core server which is something like:
This represents a queue, which might have a number of slots (10 in your case). Students will be balanced among those slots randomly by default. So as to manage the size of the queue, you play with this other variable:
Here, "exp1"-"exp10" is the instance (the same name that will be used in the laboratory server). "robot|Robotics experiments" is the name that is used in the database. So in the database you establish experiment "robot" of category "Robotics experiments", and here you define how many there are. Finally, on the right side, "robot1@robots" indicates the slots in the queue. So you are telling weblab "exp2" of "robot" of category "Robotics experiments" is the slot "robot2" of the queue "robots".
As it explains in the docs
, you may repeat the slots if two experiments refer to the same equipment. For example, you may have a "robot-demo" and then you mean "robot2@robots", so no one can end in "exp2" of robot-demo and in "exp2" of "robot" at the same time. But in your case, you're clearly talking about 10 robots, so it should be as I mentioned.
Then, you have to configure it in the laboratory server. Here it depends on the two scenarios:
Scenario 1: 10 WiFi-controlled experiment servers
You have multiple experiment servers. Then (I only put 3, but you could put the rest):
Note that I'm assuming that in configuration.yml, you have 10 different hosts called robot1_host to robot10_host. Each will have a different IP address, because they are located in a different machine (each robot). You can see here a template
Scenario 2: 1 experiment server acting as gateway for 10 WiFi-controlled robots
In some circumstances, you may want to have a single experiment server, and then 10 devices. For example, if the devices are resource constrained and can not run complex software. You can either run 10 times the same software on one server (using different ports), or you can have a single one which internally assigns the 10 sessions somehow (and this depends on you). For this, there is the "concurrent api". There is an example here
. As you can see, the "DummyExperiment" only receives the regular arguments, while the "DummyConcurrentExperiment" receives those arguments plus a "session_id", which identifies the user. So if you have 3 students, you will have to keep track that one session_id is for one robot, another for another and so on. You typically do this assignments in the "do_start_experiment" and "do_dispose" methods. If you are using weblablib
, or any HTTP unmanaged, then you must use 'experiments.http_experiment.ConcurrentHttpExperiment'. instead of 'experiments.http_experiment.HttpExperiment' in the configuration.yml
In this case, you still need exp1..exp10, but the coord_address will be the same for all. Note that the 'api' is "2_concurrent".
Hope this helps. We are aware that the mechanism is too complex and should be done through the user interface. It's in our plans to do it in the next big release.