How to make the simulation faster and more deterministic?

[junfengzh]

I'm testing the same routing algorithm as used on a Spike Prime, for FLL challenge. It turns out that the Gears simulator is much slower and less deterministic than the real robot.

For example, the Spike Prime can run a loop to read the color sensor 80 times in a second to adjust line following, while the simulator can only do 2-3 times in a second. Can we make the simulation faster? I'm fine with less fancy graphics, so if there is a way to disable some 3D rendering effects I'd be happy to try that.

I also observed random drifting and turning. How can we tune the simulator code to be more deterministic?

[QuirkyCort]

If you're only getting 2-3 loops per second, then either you're reading the color sensor a lot or something is very wrong. I'm getting around 60 to 70 loops per second using a single sensor line follower, on a 6 years old i3 CPU with no discrete GPU.

On your browser end, you may want to check that GPU hardware acceleration is on. If it's not an issue of a slow hardware, it may be a browser / driver issue. You can search online for guides on troubleshooting webgl issues.

You may also be reading the color sensor very often. If you are line following using a bunch of "if / else", you should read the color sensor once, and save the readings into a variable instead of reading the sensor in every "else if".

[junfengzh]

Thanks for quick reply. I use the double line follower, and read color sensor twice (left and right) in a loop, plus adjustment to the motors. I got 20 per second with the FLL map without mission models, but 4 per second with the models. This is on a low-end chromebook. The frame rate, on the other hand, drops from 60 down to 20 once mission models are loaded.

So the mission model seems to be the main slow down factor. Is there anything I can cut down in the framework?

Aside from slowness, the robot runs have variations every time. I'm not sure this is due to intentionally added randomness, or inherent in the simulation. Is there a way to make it more deterministic?

[QuirkyCort]

It seems that your chromebook is just too underpowered.

If you are using the Cargo Connect models, those are pretty complex. If you don't need to interact with the models, you might want to create your own simpler models using the world builder. If you absolutely must, you can dig around the Gears source code and see if you can modify the color sensor to read only the ground and nothing else. That should speed things up a bit, but it's not trivial to do.

Some variations in movement is inherent in physics simulation running in real-time. When fps is high, the physics steps are small, and variation are not as significant. When fps is low, the physics steps need to be large and that causes higher variation. Some simulators forces deterministic behaviors by using a small and fixed time period in every simulation step, but this means that the simulation will no longer be real time (ie. robot will move slower when FPS drops).

Some variations in movement is considered desirable, as real robots don't drive straight either (https://www.aaai.org/Papers/Symposia/Spring/2007/SS-07-09/SS07-09-020.pdf), but I understand that it can be frustrating when fps is very low and the variation is large. It's a deliberate decision not to make GearsBot deterministic, as this presents the opportunity for users to learn how to deal with variation using feedbacks.

[junfengzh]

Thanks for the pointers. When running on a more powerful machine, the variations are much smaller and close to real world behavior. This is a great simulation platform.