QuirkyCort / gears

Generic Educational Robotics Simulator
Other
65 stars 41 forks source link

Feature request: Accelerating the simulation #31

Open DJuego opened 3 years ago

DJuego commented 3 years ago

Hi again!!

Over the past few weeks we have been working intensively with this environment. It is impressive! Too many good things, but now I will talk about the main drawback we have found:

The impossibility to accelerate the simulation until reaching problematic parts where the tested algorithm has to be refined. Of course the option "save current position to settings" alleviates this to a great extent. Although it has its limitations.

Here I present a video demonstration of resolution of the challenge we present. Among other changes we have edited the video to accelerate it four times to its normal speed.

Another desirable feature would be to have both views simultaneously (simulator and blocks). In Open Roberta it is possible. And already the possibility of having visual aids to be able to follow up step by step would be superb. But all this deserves a separate issue.

Thank you for revolutionizing the offering of virtual robotics simulators!!! 🥇

DJuego

humbug99 commented 3 years ago

A different way to quickly get to where you want to test/refine might be to add a teleport interface to the robot that moves it to a certain location, something like:

teleport(x, y, alpha) [ for flat worlds ] teleport(x, y, z, alt, azimuth) [ 3d version ]

or maybe:

teleport(x, y, alpha, max_linear_err, max_angle_err) to allow the robot to be somewhat out of position as it would be if it traveled there.

Using this, you teleport the robot to the location where you want to begin testing, then run the code starting at that point. Things that might be problematic with teleporting could be momentum (if the robot is already moving), and what happens to carried objects.

QuirkyCort commented 3 years ago

Due to the way Gears work, accelerating time (...or "time compression") will be very problematic.

The simulation is not fully deterministic, and relies on interaction between the GPU (...color sensor) and CPU (...everything else), both of which runs on their own clock. If we double the physics simulation speed (...double movement speed, half sleep time), the GPU will likely be unable to generate twice the color sensor readings. This will lead to the robot missing lines and colors.

The "teleport" interface that humbug99 suggested would be a better approach, but figuring out the correct position / rotation can be quite troublesome. The "save current position" feature was created to alleviate that; no need to figure out the x/y/rotation, just drive the robot there and click "save".

If you can share the use cases where "save current position" isn't adequate, let me know and I'll see if I can improve it.

DJuego commented 3 years ago

I see... Thank you very much for your elaborate response.

I already suspected that there were deep/powerful reasons for not having this valuable feature. In fact I think that this non-deterministic aspect and the variable interaction between GPU and CPU (affected by the punctual process load, the concrete computer,...) has produced us some confusion in other situations (strange and unexpected behaviors when following a line for example) :-D Luckily in a second or third attempt it usually works. :-)

In this specific case the limitation we found with "save current position to settings" is that the object being transported is lost and the arm position was incorrect...

I understand that it is very complicated to "save/restore" the whole state of the universe. :-) I also understand very well the difficulties you mention about the teleportation interface.

For the moment I think we will accept things as they are. :-) That they are already very satisfactory things. :-) Thanks again!

If we can offer you some ideas later on, don't doubt that we will do it. :-)

DJuego

QuirkyCort commented 3 years ago

Let me know if you see any strange and unexpected behaviours, especially if it cannot be explained by a slow color sensor update rate.

I believe saving of the full world state will solve your problem, and I can see that it will be useful in a lot of cases. It'll be a while before I have time to get to it, but it's a good idea that should be worked on eventually.

QuirkyCort commented 3 years ago

@DJuego I'm schedule to give a short talk on GearsBot at the Blockly Summit in a couple of weeks, so if you can share anything about how you've been using GearsBot, that would be very much appreciated.

Also, I am planning to start a repository of maps and robots. I see from your video that you have a custom map there. Would you like to contribute?

DJuego commented 3 years ago

Hi! @QuirkyCort . To avoid polluting your issues repository, I have sent you an email to try to answer your request. I hope you find it helpful.

DJuego