## Making wheeled vehicles with kinematics and no dynamics?

Typically: "How do I... ", "How can I... " questions
RobAtLab
Posts: 86
Joined: 10 Jan 2018, 17:49

### Making wheeled vehicles with kinematics and no dynamics?

I've got a simulation of a modular robot which works very nicely alone. It contains many dynamic and responable components. The key things this robot does are to drive around, dock with other robots (using dummies with dynamic overlap constraints), and hinge in the middle to lift other robots up. Due to the real thing being quite small and lightweight I found that in V-REP I needed to give my model an unrealistically high mass and moment of inertia so it would behave properly, this isn't something which worries me. I had to also magnify up the torques by a vast amount to compensate for these unrealisticaly heavy and hard-to-rotate parts, this doesn't bother me either. But I'm finding that when I simulate multiple robots the simulations are painfully slow, for 5 robots which haven't even docked yet I can barely manage a 20th of realtime speeds. This is a problem as I want to do a rather large number of fairly complex simulations.

So I wondered if I could manage the same thing but abandon dynamics and use just kinematics instead? I know some of your default models do this, especially the robot arm ones. Especially because my mass, moments of inertia and torque values are already quite unrealistic there seems little point in sticking to dynamic if I can escape it. The issue is that I've made a lot of use of joints in torque/force mode and I have some rather special wheels and rollers in the model. How do I replicate this with purely kinematic methods? Is it even possible to make wheels using kinematics instead of dynamics, or does the fact that a wheel relies on friction make this impossible? In a kinematic model if robots are assembled in some structure which folds and hence lifts itself up (the image at https://encrypted-tbn0.gstatic.com/imag ... oUotEQ-EUI gives some idea of what I mean by this, though it does not depict the same design of robots as I'm working with) can kinematics handle considerations of "if an object is this shape with masses at certain points in it which angle will it rest on the ground at"? With that image you can imagine if one of those "leg" robots bent it's hinge and lifted itself upward could kinematics show how the rest of the structure would topple (not break apart, just fall and land at a new angle) when the shape changed?

Are there any other considerations which could help me speed up my simulation by abandoning considerations of dynamic forces and switching to a kinematic simulation?

Thank you

coppelia
Posts: 8206
Joined: 14 Dec 2012, 00:25

### Re: Making wheeled vehicles with kinematics and no dynamics?

Hello,

you can switch to a kinematics simulation, but I am afraid that this is quite complex and probably not worth the speed gains. For simple wheeled robots that roll on a flat surface, this would be quite straightforward. But in your situation... not really.

What physics engine are you using? did you try with the others? Vortex normally doesn't require any special tweaking of masses and/or inertias.

In your situation it is important to identify the sources for the slow-down. Is it really the physics engine? If yes, you have at least 2 possibilities (depending on the used engine):
• Try to adjust the engine's general properties. e.g. solving iterations, dyn. step size
• Try to have very simple respondable shapes for the dynamics. Best would be to model your robot with pure cubes, spheres and cylinders. No convex shapes (convex shapes are still better than random shapes) or random shapes, since that slows down a lot due to collision point calculations
Cheers

RobAtLab
Posts: 86
Joined: 10 Jan 2018, 17:49

### Re: Making wheeled vehicles with kinematics and no dynamics?

I have had to have quite a few convex shapes, the issue is that some of my shapes are the kind of thing which is really hard to represent as a collection of cyliners and/or cubes. Any tips for easy and efficient ways to make shapes of this sort of form https://encrypted-tbn0.gstatic.com/imag ... xIwlT-YHUA (ignore the dimensions, it's just a picture online of "barrel shape") where the change in radius along the length of the cylinder follows a particular curve (part of the edge of a circle) from pure shapes? I don't think a perfect sphere or cyclinder would be quite good enough, and putting several together to make that might be challenging. Right now I've got lots of convex meshes that shape (48 per robot) in the scene, maybe even just changing them and not altering the other shapes in the scene might help.

I wasn't quite sure how to enable vortex, as far as I can tell it must be downloaded separetly and installed in a way that V-REP can access? I think the makers site for vortex has changed since the links to it on various V-REP help pages were made as things seem to redirtect to a homepage rather than straight to the relevant vortex version.

Promity sensing might be slowing things down a bit too, I've got quite a lot of proximity cones in the scene, although many are doing pretty basic jobs. I'd be happy to make any changes that would speed these up at significant cost to their accuracy (say perhaps +/-20% or worse on readings from them), but while I've tried using random ray instead the random rays do not seem to stick to their cones. The rays leak out of their cones and detect things they definitely shouldn't see. I've also thought about "explicit handling" but quite a lot of my proximity sensors are there to do this viewtopic.php?f=9&t=7182 so I don't know if explicit handling might stop them noticing whether dummies had entered their cone.

My lua scripts controlling the robots are pretty simple right now so I'm fairly sure they cannot be the cause of my slow sims.

Thanks

coppelia
Posts: 8206
Joined: 14 Dec 2012, 00:25

### Re: Making wheeled vehicles with kinematics and no dynamics?

The barrel could be approximated with one sphere and 2 cylinders. Spheres are basically the easiest to compute for a physics engine. But it is important to really identify the source of slow-down. It could also be some threaded scripts that waste time hardly doing anything (in that case sim.switchThread comes in handy).

The Vortex elements are actually already in place. All that is missing is the license. Instructions are given here. In short: you create an account with them, you get from them a Vortex studio essentials activation key. Then you can download and install Vortex studio essentials. In the installation folder you will find an executable similar to VortexLicenseManagerGUI.exe. You enter your activation key there and then restart V-REP.

You can reduce the number of facets of your proximity sensors. Explicitely handling all sensors can also help (e.g. then you can decide to read your sensors every simulation step, every second simulation step, or even less (say once per second if that is enough). But proximity sensor are normally quite fast when detecting dummies (it is basically just checking whether a point lies within its volume).

Cheers

RobAtLab
Posts: 86
Joined: 10 Jan 2018, 17:49

### Re: Making wheeled vehicles with kinematics and no dynamics?

I've tried doing all explicit handling, it speeds things up a bit (a sim that took 2min 17sec on my PC now runs in 1min 57sec, the sim covers 7.4 sec of simulated time). How would I go about finding out whether there are any threaded scripts present which are wasting time and need to be stopped by sim.switchThread. Beyond proximity sensors, time wasting threaded scripts that do almost nothing, and convex rather than pure geometry what else could be slowing my sim down (note that this is a sim using lua and internal scripts, no external scripts or remote API are involved)?

P.S. if I change from convex meshes to pure shapes, would having 48 pure spheres, each of them child of a separate joint, be faster than using 24 of the convex barrel meshes each of them child of a joint? If not it isn't going to help me much when I change to pure shapes as the only way I'll be able to replace my barrels with speheres is if I use more spheres than there currently are barrels.

Thanks

RobAtLab
Posts: 86
Joined: 10 Jan 2018, 17:49

### Re: Making wheeled vehicles with kinematics and no dynamics?

Ok, I've tried removing all my barrels and adding twice the number of spheres in their place. The sim is no faster. I've also tried running the sim with while showing a hidden layer that has only a view joints rather than the usual 8 upper layers with all the fancy visual content in them. I still can't get much below 2 minutes in either case. There must be something else slowing me down but I've no idea how to work out what.

Unless they have come from a default object supplied with V-REP which I may have pasted into my scene, or they are somehow part of the mainscript, I can't see any way that a threaded script might be involved in my simulation. All my robot controllers, proximity sensor guidance cones, and other child scripts on various objects are non-threaded.

And I've tested a variety of scenes with 7 of my robots in them, they all seem to run at about the same rate, 7 seconds sim in 2 minutes cpu time, regardless of how simple or complex their controllers are and whether they spend that time moving around or just sitting still and writing and readings signals.

RobAtLab
Posts: 86
Joined: 10 Jan 2018, 17:49

### Re: Making wheeled vehicles with kinematics and no dynamics?

I've found what is slowing me down. I had a go at disabling the script which writes to dummies depending on whether they are illuminated in the cones of LEDs (proximity sensors act as these cones in the sim). My sim now runs in 48 secs rather than 2min 17, a great improvement.

I've attached the content of the child script which runs on my "LEDs". Bear in mind that my scene has 28 such LEDs in it. And about 168 dummies, 140 of which are supposed to be written to. The other 24 dummies are there for other purposes and while I wasn't sure how to stop them getting custom datablocks put on them, it doesn't harm them to have such blocks written. Could you take a glance at the script and suggest which parts are causing the wirst slowing. can you also advise whether there is a convenient way in which the child script which runs on the parent object of an LED might be able to turn the LED's child script on and off, such that the LED need only write to datablocks when the childscript of the LED's parent tells it to be in "writing mode" and at other times the LED can be "swithced off", that is to say not writing any datablocks. If you could advise as to what part iof the child script will do the worst slowing (for example the signals, or all the data packing and unpacking, or those key/value arrays which have data placed into the LightSource th place.

I also wondered if the following edit would help speed things up:
somewhere near the top of the line 31 "for i=1,#PhotoTransistors,1 do" for loop add it a piece which checks for each phototransistor dummy whether it is within a certain range (a range of perhaps 1.1*actual_range_of_proximity_sensor_cone) and only does the lower stuff in the for loop if the position of a dummy is within this range as calculated by some sim.getObjectPosition() and some pythagoras . Or would such a retreival of positions and then a distance calculation take more CPU time than would be spent on doing the table packing/unpacking for phototransistor dummies which don't need anything doing to thejm as they are well out of range?

The child script is shown below:

Code: Select all

function GetParentObjectID() --a function to get the hash number of the top level parent of an object, the way that robot models are set up this should be the robot base object cube
LevelUpObject=sim.getObjectAssociatedWithScript(sim.handle_self)--this object handle starts by respresenting the object on which this child script is running, but then moves up the hierachy to the highest parent
while (sim.getObjectParent(LevelUpObject) ~= -1)do --this while loop runs until we get to a point where there isn't a higher parent to move to
LevelUpObject=sim.getObjectParent(LevelUpObject) --each time the loop runs we move up to the next level of parent
end --by the time the while loop ends we have reached an object which has no parent
NameHashed=sim.getObjectName(LevelUpObject)--we take the name of that highest level object
Hash,NameUnHashed =sim.getNameSuffix(NameHashed)--and we break the name into the unhashed bit and the hash number
ParentObjectID=tonumber(Hash)--then finally we have the hash ID of the parent object, note that this only maks sense if all highest level parent objects have the same name except the hash part, but with my modular robots this should generally be the case
--print("Parent: ")
--print(ParentObjectID)
return ParentObjectID
end

if (sim_call_type==sim.syscb_init) then
local Lightsource=sim.getObjectAssociatedWithScript(sim.handle_self)
local PhotoTransistors=sim.getObjectsInTree(sim.handle_scene,sim.object_dummy_type) --actually gives a list of all dummies, not only the ones representing phototransistors, but as robot modules will only read the datablocks deposited onto dummies which are representing phototrans then this is fine
for i=1,#PhotoTransistors,1 do --this bit sets up the custom datablock on dummy objects
IlluminationList={} --we make a small array of zeroes
sim.writeCustomDataBlock(PhotoTransistors[i],'IlluminatedBy',sim.packTable(IlluminationList)) --and lastly we pack IlluminationList back into a table and write it to the object as a datablock called IlluminatedBY
end
end

if (sim_call_type==sim.syscb_sensing) then
local Lightsource=sim.getObjectAssociatedWithScript(sim.handle_self)
RobotID=GetParentObjectID()--this automatically gets the ID # number of the highest level parent of the LED object, the highest level parent should be the robot module base object MyRobot#X
PortNumber=1 --this is manually set in the child script of each LED in a robot model
--print("RobotID:")
--print(RobotID)
local PhotoTransistors=sim.getObjectsInTree(sim.handle_scene,sim.object_dummy_type) --actually gives a list of all dummies, not only the ones representing phototransistors, but as robot modules will only read the datablocks deposited onto dummies which are representing phototrans then this is fine
for i=1,#PhotoTransistors,1 do --this bit sets up the custom datablock on dummy objects
local IlluminationList=sim.readCustomDataBlock(PhotoTransistors[i],'IlluminatedBy')--reads a datablock from the relevant Phototransistor object if such a block exists
if IlluminationList and #IlluminationList>=6 then -- an empty packed table has length 6, so if this is true then the datablock exists and holds a packed table object
IlluminationList=sim.unpackTable(IlluminationList) --if there is an IlluminatedBy datablock we unpack the data from it to process
else --if there isn't one we'll make a table which we will later make into an IlluminatedBy custom datablock to go on the phototransistor
IlluminationList={}
end
--at this point IlluminationList is now containing the previous content of the custom datablock

InFieldOfView=sim.checkProximitySensor(Lightsource,PhotoTransistors[i])
--the if loop below will put a 1 if we can see the PhotoTransistor or a 0 if it is obscured from the LED that we are representing in this code
if (InFieldOfView == 1) then
IlluminationList[Lightsource]={RobotID,PortNumber,1} --for phototransistor objects which have been illuminated
else
IlluminationList[Lightsource]={RobotID,PortNumber,0} --for those that aren't illuminated
end
--print("IllumList:")
--print(IlluminationList[Lightsource])

sim.writeCustomDataBlock(PhotoTransistors[i],'IlluminatedBy',sim.packTable(IlluminationList)) --and lastly we pack IlluminationList back into a table and write it to the object as a datablock called IlluminatedBY, we have overwritten the old datablock if it existed, but we've overwritten it with a version containing everything it held plus whatever we've just appended to it
--specifically we have appended over the top of what our LED told the phototransistor last step, but we haven't appended over what other LEDs are telling the phototransistor
end
end

if (sim_call_type==sim.syscb_cleanup) then
local Lightsource=sim.getObjectAssociatedWithScript(sim.handle_self)
local PhotoTransistors=sim.getObjectsInTree(sim.handle_scene,sim.object_dummy_type) --actually gives a list of all dummies, not only the ones representing phototransistors, but as robot modules will only read the datablocks deposited onto dummies which are representing phototrans then this is fine
for i=1,#PhotoTransistors,1 do --this bit sets up the custom datablock on dummy objects
IlluminationList={}--0,0,0}
sim.writeCustomDataBlock(PhotoTransistors[i],'IlluminatedBy',sim.packTable(IlluminationList)) --and lastly we pack IlluminationList back into a table and write it to the object as a datablock called IlluminatedBY, we have overwritten the old datablock
end
-- Put some restoration code here
--simUI.destroy(ui)
end


coppelia
Posts: 8206
Joined: 14 Dec 2012, 00:25

### Re: Making wheeled vehicles with kinematics and no dynamics?

Can you post a self-contained scene that illustrates your problem? It will be easier to identify the problem in your script that slows down everything.

Cheers

RobAtLab
Posts: 86
Joined: 10 Jan 2018, 17:49

### Re: Making wheeled vehicles with kinematics and no dynamics?

I might be able to post one, but I've already isolated the source of slowness to within that child script. If it the 28 copies of it are deleted from the 28 proximity sensor objects which they are on then the sim speeds up by a factor of about 3.

Can you advise what, amongst that script, is the thing which in lua is going to be the most processor hungry?

Thanks

coppelia
Posts: 8206
Joined: 14 Dec 2012, 00:25

### Re: Making wheeled vehicles with kinematics and no dynamics?

Looking at your code, the call to sim.checkProximitySensor on line 40 is probably the slowest of all. Specially if you are calling it for all dummies in the scene, even those that are actually not part of your detection.

You can further check timingy via sim.getSystemTimeInMs.

To increase speed, skip the dummies that are not part of your detection mechanism. For that you may have to add an additional tag to your special dummies to easily differentiate them from the others. Also, in the initialization phase, you can just create a list with all the dummies you need to check (no need to continuously retrieve all dummies via sim.getObjectsInTree). Additionally, reduce the complexity of your proximity sensor (reduce the number of faces).

By the way, try to use the new function notation:

Code: Select all

if (sim_call_type==sim.syscb_init) then
...
end
do:

Code: Select all

function sysCall_init()
...
end
Same for all the others (e.g. clean-up, actuation, sensing, etc.).

Cheers