Menu
▾
▴
simspark-devel
|
From: Oliver O. <Oli...@ne...> - 2007-02-02 21:39:22
|
On 03/02/2007, at 2:21 AM, Yuan Xu wrote: > Hi Joschka, > > >> What do you think about this approach? Do you think you could work >> on that? > > Yes, multi-threads should be introduced. > I will try to work on this. > As I know, we can use three thread libraries: pthread, boost::thread > and SDL::thread, > and I think we may choose one between boost::thread and SDL::thread, > since they are all convenient and platform-independence. > what do you think about it? sounds all quite good. I've also found this hints for timing the physics loop (in a computer game) here: [1], it's an interesting read, at least. From this page, there are also more interesting articles. I'm also re-directing this thread to the simspark-devel mailing list (I know you're all subscribed :-), because the advantage of this list is that everybody interested can read what's going on and the emails get archived automatically. Please, let's continue our discussions there. cheers Oliver [1] http://www.gaffer.org/game-physics/fix-your-timestep/ -- Oliver Obst ES208 form follows function (Louis Sullivan). Fon: +61 2 492 16175 http://oliver.obst.eu/ Uni Newcastle School of Electrical Engineering and Computer Science |
|
From: Oliver O. <Oli...@ne...> - 2007-02-05 03:31:18
|
Hi, On 04/02/2007, at 3:50 PM, Yuan Xu wrote: > 2007/2/3, Oliver Obst <Oli...@ne...>: >> sounds all quite good. >> I've also found this hints for timing the physics loop (in a computer >> game) here: [1], it's an interesting read, at least. From this page, >> there are also more interesting articles. [...] >> [1] http://www.gaffer.org/game-physics/fix-your-timestep/ > The article is great! > There is a similar implementation in the simspark ( See void > SimulationServer::Step() ). > Set the mSimStep to 0.01, then the physics will run in 10ms step. a smaller step should make the simulation more stable, but for this, we need to run some experiments (maybe later on). > I face a problem when try introduce the threads: > there is only one scene information in the simulator, > then, different threads can not operate the scene information at > the same time. > For example, when the agent-management-thread encodes the > perception messages, > the scene information should not be changed, > so the physics-thread should be hang up. > As a result, this kind multi-threads is meaningless, I think. I understand the problem. But it's not entirely meaningless, please see below. > Maybe we need a buffer, like the frame buffer in OpenGL, > saving the scene information which will be handled by > agent-management-thread to the buffer. > But it is not a straight-forward work, for the scene information is > stored in different objects. Well, one direction to approach that would be (1) to start using threads anyway: 1.a) We decide to care about inconsistencies in sensor readings. We could start this by using no buffer, and for the beginning, we could use locks so that no 2 threads operate on the scene graph. Later on, if the threads are working, we can think about something to get rid of the big locks (like the proposed buffer). 1.b) We decide not to care about inconsistencies in sensor readings. We start using threads and no buffers (like 1.a), but care only about multiple writes (which are obviously a bad thing, and shouldn't happen anyway). At the moment, I think the worst thing that can happen would be an inconsistent sensor reading... the physics should be fine. But maybe I'm missing something, what would be the reason for the physics thread to hang up? Inconsistent readings can happen with real sensors as well (e.g. a laser range finder and moving objects etc). Later on, if that's working, we resolve the inconsitency issue by small locks or buffering. The alternative approach (2) would be to not use threads in the simulator for now, but to think of a smart single-threaded solution along the lines of the article [1] above. The single-threaded solution would be more interesting for the development phase, because it's easier to debug (and maybe also easier to implement). At the end of the day, I'd prefer a multi-threaded solution, because it might help with the current performance issues (and all the machines are becoming multi-core anyways). But if a single threaded solution is more stable, let's stick with one thread and think about more threads later. > If there is a class or struct represent the scene information, the > work will be easier. > But the plug-in mechanism makes the scene changes, so build such a > scene class is not simple. The original idea of the whole simulator framework was to represent all kind of information of an object in an extended scene graph (tree); this includes visual aspects like textures etc, if an object possesses these. I still think, that the tree kind representation is still very good, but for a few reasons we have to think over this concept again. Firstly, if the monitor is external (a separate program), there is no point in representing (and updating) visual information together with the physical properties of an object. Secondly, even if the monitor is part of the simulator process (which would be nice to avoid serialization), the visual information doesn't need to be updated at the same rate as the physical information. My feeling is that some of the steps to a solution are something like this (comments more than welcome): - initially (or whenever new objects are spawned), the simulator needs to tell the monitor _how_ everything wants to be displayed (in terms of textures, meshes etc). The simulator has to store this information somewhere (but not necessarily in the part of the tree that get's updated by the physics). - if we want an extra thread for the visualization, we should check if it's better to copy the scene tree or if it's better to let the visualization plugin access the scene tree directly (using a lock or so). Copying takes extra time, but can have advantages too. - the same thing holds for the agents' sensors, with the difference that these have to be coupled with the actual simulation speed, whereas the visualization just displays the situation as it currently is (i.e. the visualization can run at a constant framerate even if the simulator step rate changes). - the actions of an agent should then not modify the world directly, but be placed in a queue and the physics loop should take care of them (so that there is only a single thread actually changing the world directly). I think that's not fundamentally different from the current approach, but still worth looking over. - if we want the agents to run as fast as possible, we should use something like a syncmode in 2D, but for giving the agents enough time to think, the simulator should wait with the physics if it is faster than real time for competition settings. cheers Oliver -- Oliver Obst ES208 form follows function (Louis Sullivan). Fon: +61 2 492 16175 http://oliver.obst.eu/ Uni Newcastle School of Electrical Engineering and Computer Science |
|
From: Joschka B. <jbo...@un...> - 2007-02-05 10:31:55
|
Hi, Oliver Obst wrote: > Hi, > > On 04/02/2007, at 3:50 PM, Yuan Xu wrote: > > >> 2007/2/3, Oliver Obst <Oli...@ne...>: >> >>> sounds all quite good. >>> I've also found this hints for timing the physics loop (in a computer >>> game) here: [1], it's an interesting read, at least. From this page, >>> there are also more interesting articles. >>> > [...] > >>> [1] http://www.gaffer.org/game-physics/fix-your-timestep/ >>> > > > >> The article is great! >> There is a similar implementation in the simspark ( See void >> SimulationServer::Step() ). >> Set the mSimStep to 0.01, then the physics will run in 10ms step. >> > > a smaller step should make the simulation more stable, but for this, > we need to run some experiments (maybe later on). > > Exactly. So far, I've had good experience with 0.01 s, but we can play around to find a good value. >> I face a problem when try introduce the threads: >> there is only one scene information in the simulator, >> then, different threads can not operate the scene information at >> the same time. >> For example, when the agent-management-thread encodes the >> perception messages, >> the scene information should not be changed, >> so the physics-thread should be hang up. >> As a result, this kind multi-threads is meaningless, I think. >> > > I understand the problem. But it's not entirely meaningless, please > see below. > > >> Maybe we need a buffer, like the frame buffer in OpenGL, >> saving the scene information which will be handled by >> agent-management-thread to the buffer. >> But it is not a straight-forward work, for the scene information is >> stored in different objects. >> > > Well, one direction to approach that would be (1) to start using > threads anyway: > 1.a) We decide to care about inconsistencies in sensor readings. > We could start this by using no buffer, and for the beginning, we > could use locks so that no 2 threads operate on the scene graph. > Later on, if the threads are working, we can think about something to > get rid of the big locks (like the proposed buffer). > 1.b) We decide not to care about inconsistencies in sensor readings. > We start using threads and no buffers (like 1.a), but care only about > multiple writes (which are obviously a bad thing, and shouldn't > happen anyway). At the moment, I think the worst thing that can > happen would be an inconsistent sensor reading... the physics should > be fine. But maybe I'm missing something, what would be the reason > for the physics thread to hang up? Inconsistent readings can happen > with real sensors as well (e.g. a laser range finder and moving > objects etc). Later on, if that's working, we resolve the > inconsitency issue by small locks or buffering. > I think we could start with 1a) and guarantee mutually exclusive operation on the SceneGraph between the different threads. You can set a Mutex for this if you want to use the SceneGraph, then you'll have exclusive access, and then remove that Mutex once you're done. This way, another thread might have to wait for a while to get access, but you'll have correct data all the time. The only way the system could 'hang' is, if a Mutex doesn't get removed. But even then, there are time out mechanisms that can be used. Since the physics thread runs a lot faster than visualization and agent updates, these locks won't occur too often, I think. If 1a) turns out to be too slow, we could consider option 1b). > The alternative approach (2) would be to not use threads in the > simulator for now, but to think of a smart single-threaded solution > along the lines of the article [1] above. The single-threaded > solution would be more interesting for the development phase, because > it's easier to debug (and maybe also easier to implement). At the end > of the day, I'd prefer a multi-threaded solution, because it might > help with the current performance issues (and all the machines are > becoming multi-core anyways). But if a single threaded solution is > more stable, let's stick with one thread and think about more threads > later. > > Yes, debugging multi-threaded programs is not exactly fun in most cases :-( But in the end, the performance gain might be worth it, I think (especially on multi-core machines). >> If there is a class or struct represent the scene information, the >> work will be easier. >> But the plug-in mechanism makes the scene changes, so build such a >> scene class is not simple. >> > > The original idea of the whole simulator framework was to represent > all kind of information of an object in an extended scene graph > (tree); this includes visual aspects like textures etc, if an object > possesses these. I still think, that the tree kind representation is > still very good, but for a few reasons we have to think over this > concept again. Firstly, if the monitor is external (a separate > program), there is no point in representing (and updating) visual > information together with the physical properties of an object. That's true. > > Secondly, even if the monitor is part of the simulator process (which > would be nice to avoid serialization), the visual information doesn't > need to be updated at the same rate as the physical information. > What visual information do you mean? Position and orientation are needed by both physics and visuals, and stuff like textures and the meshes (usually) don't change much I think. Oh, but maybe you're thinking of animation data? I think having all the necessary information in one scene structure (like the scene tree) is nice if you have internal rendering. > My feeling is that some of the steps to a solution are something like > this (comments more than welcome): > - initially (or whenever new objects are spawned), the simulator > needs to tell the monitor _how_ everything wants to be displayed (in > terms of textures, meshes etc). The simulator has to store this > information somewhere (but not necessarily in the part of the tree > that get's updated by the physics). > - if we want an extra thread for the visualization, we should check > if it's better to copy the scene tree or if it's better to let the > visualization plugin access the scene tree directly (using a lock or > so). Copying takes extra time, but can have advantages too. > If you want to copy, you have to lock anyways if you're using threads, I think. Otherwise you might have inconsistent data to display. > - the same thing holds for the agents' sensors, with the difference > that these have to be coupled with the actual simulation speed, > whereas the visualization just displays the situation as it currently > is (i.e. the visualization can run at a constant framerate even if > the simulator step rate changes). > - the actions of an agent should then not modify the world directly, > but be placed in a queue and the physics loop should take care of > them (so that there is only a single thread actually changing the > world directly). I think that's not fundamentally different from the > current approach, but still worth looking over. > That sounds reasonable. > - if we want the agents to run as fast as possible, we should use > something like a syncmode in 2D, but for giving the agents enough > time to think, the simulator should wait with the physics if it is > faster than real time for competition settings. > Yeah, a sync mode would definitely be a nice feature :-) Cheers, Joschka |
|
From: Oliver O. <Oli...@ne...> - 2007-02-05 11:58:45
|
Hi Joschka, On 05/02/2007, at 9:30 PM, Joschka Boedecker wrote: > I think we could start with 1a) and guarantee mutually exclusive > operation on the SceneGraph between the different threads. You can > set a > Mutex for this if you want to use the SceneGraph, then you'll have > exclusive access, and then remove that Mutex once you're done. This > way, > another thread might have to wait for a while to get access, but > you'll > have correct data all the time. The only way the system could > 'hang' is, > if a Mutex doesn't get removed. But even then, there are time out > mechanisms that can be used. Since the physics thread runs a lot > faster > than visualization and agent updates, these locks won't occur too > often, > I think. If 1a) turns out to be too slow, we could consider option > 1b). 1a should at least not be (much) slower than using no separate threads at all. If we find a way to program everything so that we can switch back to single thread easily, that would be really great (for debugging), but I'm not sure if this can be done. > What visual information do you mean? Position and orientation are > needed > by both physics and visuals, and stuff like textures and the meshes > (usually) don't change much I think. Oh, but maybe you're thinking of > animation data? mmh, yeah, but maybe I'm wrong. At least if we only store the data close to the object they belong to, that shouldn't affect the performance. We have this graphics-engine part inside the project (kerosin), which was really cool stuff when it was created. But as nobody is really using and maintaining it, we should think of using 3rd party graphic libs, and they will handle this kind of data internally. So in the simulator core, the graphics stuff would be mainly needed for initialisation, and then be passed to the graphics engine. Anyway, as long as additional data is only stored in the tree, we can put in anything we want. We'd have to think about an interface to possible graphics engines, though. > I think having all the necessary information in one scene structure > (like the scene tree) is nice if you have internal rendering. yep. Would be great to just pass a pointer to the graphics engine, saying "here's my scene", now please render it. Well, this was the initial idea of our approach with kerosin, and yes, it would be nice to continue this idea even with other graphic engines. Might work, as they will also use a tree internally. So we could use nodes of an external graphics engine inside our scene tree, but of course that would add a compile time dependency on a particular engine. I'm currently looking into this. > If you want to copy, you have to lock anyways if you're using > threads, I > think. Otherwise you might have inconsistent data to display. yes, but I'm not sure if this would be a big problem. The updates between single steps are usually not large, so it should be possible to ignore inconsistencies. But as I said, I'm not sure. >> - if we want the agents to run as fast as possible, we should use >> something like a syncmode in 2D, but for giving the agents enough >> time to think, the simulator should wait with the physics if it is >> faster than real time for competition settings. >> > > Yeah, a sync mode would definitely be a nice feature :-) especially for machine learning and a new internet league, some speed improvements would be really good. We also have to think about a logfile format... and what get's logged with the more complex bodies anyway. A mpeg or quicktime from a match would certainly be nice (and probably not much bigger than textlogging everything), but if you want to kind of replay the match from every possible angle, that's not enough. We should think about something smarter, maybe --- the logging takes also a lot of cputime. Logging keyframes and updates, maybe, or ... cheers Oliver -- Oliver Obst ES208 form follows function (Louis Sullivan). Fon: +61 2 492 16175 http://oliver.obst.eu/ Uni Newcastle School of Electrical Engineering and Computer Science |
|
From: Joschka B. <jbo...@un...> - 2007-02-06 00:35:10
|
Hi Oli, Oliver Obst wrote: > [...] >> What visual information do you mean? Position and orientation are >> needed >> by both physics and visuals, and stuff like textures and the meshes >> (usually) don't change much I think. Oh, but maybe you're thinking of >> animation data? > > mmh, yeah, but maybe I'm wrong. At least if we only store the data > close to the object they belong to, that shouldn't affect the > performance. We have this graphics-engine part inside the project > (kerosin), which was really cool stuff when it was created. But as > nobody is really using and maintaining it, we should think of using > 3rd party graphic libs, and they will handle this kind of data > internally. So in the simulator core, the graphics stuff would be > mainly needed for initialisation, and then be passed to the graphics > engine. Anyway, as long as additional data is only stored in the > tree, we can put in anything we want. We'd have to think about an > interface to possible graphics engines, though. Of course, you're right. Sorry, I forgot about the plan to change to an external graphics lib for a moment there :-/ >> I think having all the necessary information in one scene structure >> (like the scene tree) is nice if you have internal rendering. > > yep. Would be great to just pass a pointer to the graphics engine, > saying "here's my scene", now please render it. Well, this was the > initial idea of our approach with kerosin, and yes, it would be nice > to continue this idea even with other graphic engines. Might work, as > they will also use a tree internally. So we could use nodes of an > external graphics engine inside our scene tree, but of course that > would add a compile time dependency on a particular engine. I'm > currently looking into this. Hmm, yeah, it would be nice not to have these dependencies. Maybe having two different scene trees (one for the physics, one in the rendering engine) is not a bad idea after all. > >> If you want to copy, you have to lock anyways if you're using >> threads, I >> think. Otherwise you might have inconsistent data to display. > > yes, but I'm not sure if this would be a big problem. The updates > between single steps are usually not large, so it should be possible > to ignore inconsistencies. But as I said, I'm not sure. We can try with locking first and then see what happens :-) I think the locking shouldn't be a big problem either though. > >>> - if we want the agents to run as fast as possible, we should use >>> something like a syncmode in 2D, but for giving the agents enough >>> time to think, the simulator should wait with the physics if it is >>> faster than real time for competition settings. >>> >> Yeah, a sync mode would definitely be a nice feature :-) > > especially for machine learning and a new internet league, some speed > improvements would be really good. > > We also have to think about a logfile format... and what get's logged > with the more complex bodies anyway. A mpeg or quicktime from a match > would certainly be nice (and probably not much bigger than > textlogging everything), but if you want to kind of replay the match > from every possible angle, that's not enough. We should think about > something smarter, maybe --- the logging takes also a lot of cputime. > Logging keyframes and updates, maybe, or ... Yeah, something along the lines of the delta-scenes we have in the current monitor maybe (just describing changes in the scene). Keyframes with interpolation might be too crude for detailed frame by frame analysis I'm afraid. Cheers, Joschka |
|
From: Oliver O. <Oli...@ne...> - 2007-02-06 02:01:53
|
>> mmh, yeah, but maybe I'm wrong. At least if we only store the >> data close to the object they belong to, that shouldn't affect >> the performance. We have this graphics-engine part inside the >> project (kerosin), which was really cool stuff when it was >> created. But as nobody is really using and maintaining it, we >> should think of using 3rd party graphic libs, and they will >> handle this kind of data internally. So in the simulator core, >> the graphics stuff would be mainly needed for initialisation, and >> then be passed to the graphics engine. Anyway, as long as >> additional data is only stored in the tree, we can put in >> anything we want. We'd have to think about an interface to >> possible graphics engines, though. > > Of course, you're right. Sorry, I forgot about the plan to change > to an external graphics lib for a moment there :-/ no worries... the thing is that a converting from our tree to the representation of the Graphics Engine (possibly also a tree) costs time that you can save if you don't have to do it. >> yep. Would be great to just pass a pointer to the graphics >> engine, saying "here's my scene", now please render it. Well, >> this was the initial idea of our approach with kerosin, and yes, >> it would be nice to continue this idea even with other graphic >> engines. Might work, as they will also use a tree internally. So >> we could use nodes of an external graphics engine inside our >> scene tree, but of course that would add a compile time >> dependency on a particular engine. I'm currently looking into this. > > Hmm, yeah, it would be nice not to have these dependencies. Maybe > having two different scene trees (one for the physics, one in the > rendering engine) is not a bad idea after all. it's more flexible, but you pay a price for that (see above). On the other hand, using the same tree means (as far as I see it now) that we have to change some of the fundamental classes in our framework (the node/leaf classes), so that we use the node class of an external scene graph. I'm not so sure if there's an easy way to do that (without breaking everything, that is). Something like 2 trees that share some nodes or so, but I haven't had much time to think about it. >> something smarter, maybe --- the logging takes also a lot of >> cputime. Logging keyframes and updates, maybe, or ... > > Yeah, something along the lines of the delta-scenes we have in the > current monitor maybe (just describing changes in the scene). > Keyframes with interpolation might be too crude for detailed frame > by frame analysis I'm afraid. wasn't hesham looking for a job? ;-) cheers Oliver -- Oliver Obst ES208 form follows function (Louis Sullivan). Fon: +61 2 492 16175 http://oliver.obst.eu/ Uni Newcastle School of Electrical Engineering and Computer Science |
|
From: Hesham <hes...@gm...> - 2007-02-06 02:52:07
|
On 2/6/07, Oliver Obst <Oli...@ne...> wrote: > > > wasn't hesham looking for a job? ;-) > > Yes, he was. Just could you please do me a favour and let me know what you expect from the logger. I have just a simple idea, maybe it works or maybe not. What's your opinion about LOD (level of detail)? IMHO when an object (agent) is not close to the ball logging its exact movement frame by frame isn't necessary. Cheers, Hesham |
|
From: Hesham <hes...@gm...> - 2007-02-06 03:24:56
|
Oops, the last sentence was a bit silly. I mean the closer to the ball the more precision. On 2/6/07, Hesham <hes...@gm...> wrote: > > > > On 2/6/07, Oliver Obst <Oli...@ne...> wrote: > > > > > > wasn't hesham looking for a job? ;-) > > > > > Yes, he was. Just could you please do me a favour and let me know what you > expect from the logger. I have just a simple idea, maybe it works or maybe > not. What's your opinion about LOD (level of detail)? IMHO when an object > (agent) is not close to the ball logging its exact movement frame by frame > isn't necessary. > Hesham |
|
From: Oliver O. <Oli...@ne...> - 2007-02-06 05:59:44
|
Hi Hesham ;-) On 06/02/2007, at 2:24 PM, Hesham wrote: > Yes, he was. Just could you please do me a favour and let me know > what you expect from the logger. I have just a simple idea, maybe > it works or maybe not. What's your opinion about LOD (level of > detail)? IMHO when an object (agent) is not close to the ball > logging its exact movement frame by frame isn't necessary. The created logfile should be useful for somebody developing robots, and (if possible) also useful to show a match just to see it. Reducing the LOD, when something is not so important, is of course possible, but at the moment I'm not so sure what kind of information you would discard when the LOD is not so high. For example, could be you don't update less interesting objects in between "keyframes". Have you been thinking of something like this? Also, when you do experiments at home, the focus might not alway be on the player close to the ball, so LOD could be difficult here. At least, it should be easy to disable it for research and debugging issues. right now, we're logging everything in text format. This is nice because it's still human readable, and it's not totally bad in terms of entropy (just using binary could be worse, especially if we don't need to have many (decimal) places after the dot). The format could also be better than text format, however, because in text format, we're using only a few characters out of all possible usable ones. So one approach would be to round the decimal numbers to, say, 2 places after the dot, multiply by 128 (or something which fits to the rounding), and transmit the number as 2 or 3 byte integer. By this it would be (maybe) possible to come up with a more compact format for logfiles. If you really want to do bitcounting, you can also use parts of a byte for smaller numbers (e.g. 12 bits for degrees or something like that), but that's maybe too much already. A more intelligent version of the keyframe idea would be to log only in between the keys when a body doesn't behave as expected, so that cases where you don't log an interpolation / extrapolation would do a good job. I guess that's a bit challenging, though. cheers Oliver -- Oliver Obst ES208 form follows function (Louis Sullivan). Fon: +61 2 492 16175 http://oliver.obst.eu/ Uni Newcastle School of Electrical Engineering and Computer Science |
|
From: Yuan X. <xuy...@gm...> - 2007-02-08 16:17:57
|
Hi Joschka, Oliver and All
2007/2/5, Oliver Obst <Oli...@ne...>:
> Hi,
>
> On 04/02/2007, at 3:50 PM, Yuan Xu wrote:
>
> Well, one direction to approach that would be (1) to start using
> threads anyway:
> 1.a) We decide to care about inconsistencies in sensor readings.
> We could start this by using no buffer, and for the beginning, we
> could use locks so that no 2 threads operate on the scene graph.
> Later on, if the threads are working, we can think about something to
> get rid of the big locks (like the proposed buffer).
I have done the 1.a) test in an individual program,
I attached the source file.
In my test program, I try to use three threads which Joschka mentioned:
physics-thread, agent-management-thread and the monitor-agent.
Although the test is simple, it contains what we want, I think.
There are some values be operated by only one thread at the same time :
`simTime', `nextTime', `nextRenderTime',
they are the `scene tree' in the test program.
The function doSomething(t) is just a delay function,
just like the program need something to do.
I assume some time ( the function with * operates the `scene tree' ):
a *simstep* needs 2ms,
parse the received msg needs 2ms,
*prepare the send msg* needs 2ms,
*save the actions to scene tree* needs 2ms,
send the msg through net needs 2ms,
*the monitor render* needs 2ms
and
physics step is 10ms,
agent step is 200ms,
monitor step is 150ms.
the format of stdout is
< [ real_start_time - wait_time ] function( simTime ) real_end_time >
I test it in a Pentium D 2.8G , 1G RAM computer,
you can compile the source by
> g++ threads1.cpp -lSDL -lboost_thread-mt -Wall
run the a.out
and then do
> gnuplot threads1.plt
to generate the test result in you own computer.
I think we can guarantee the correct order of events.
see the png I attached.
In the plotting,
the x-axis is the real time, which get from SDL,
the y-axis have different meanings:
the `x' is just a line y=x, it is a base line
the `physics.log' is the sim time in physics thread,
the `agent.log' is the sim time in agent thread,
and the `monitor.log' is the sim time in monitor thread;
the 'scene.log' denotes which thread is operating the `scene tree':
0 - no thread
100 - the physics thread
200 - the agent thread
300 - the monitor thread
lastly, the `stepWait.log' denotes which thread is locking the physics thread:
400 - no thread
500 - the agent thread
600 - the monitor thread
>From the plotting, we can see the simulation running smoothly.
Is everything right?
Should we implement the plan 1.a) in simspark, or do more testing ?
--
Best wishes!
Xu Yuan
School of Automation
Southeast University, Nanjing, China
mail: xuy...@gm...
xy...@ya...
web: http://xuyuan.cn.googlepages.com
--------------------------------------------------
|
|
From: Joschka B. <jbo...@un...> - 2007-02-24 07:14:18
|
Hi Yuan, first of: thanks a lot for doing these tests! Yuan Xu wrote: > Hi Joschka, Oliver and All > > 2007/2/5, Oliver Obst <Oli...@ne...>: >> Hi, >> >> On 04/02/2007, at 3:50 PM, Yuan Xu wrote: >> > >> Well, one direction to approach that would be (1) to start using >> threads anyway: >> 1.a) We decide to care about inconsistencies in sensor readings. >> We could start this by using no buffer, and for the beginning, we >> could use locks so that no 2 threads operate on the scene graph. >> Later on, if the threads are working, we can think about something to >> get rid of the big locks (like the proposed buffer). > > I have done the 1.a) test in an individual program, > I attached the source file. > > In my test program, I try to use three threads which Joschka mentioned: > physics-thread, agent-management-thread and the monitor-agent. > [...] > > I test it in a Pentium D 2.8G , 1G RAM computer, > you can compile the source by >> g++ threads1.cpp -lSDL -lboost_thread-mt -Wall On my machine (Ubuntu 6.10), I used "g++ threads1.cpp -lSDL -lboost_thread-gcc-mt-1_33_1 -Wall" to make it work. > run the a.out > and then do >> gnuplot threads1.plt > to generate the test result in you own computer. > > I think we can guarantee the correct order of events. > see the png I attached. > >> From the plotting, we can see the simulation running smoothly. > > Is everything right? I looks very good, indeed. > > Should we implement the plan 1.a) in simspark, or do more testing ? > It would be great if you could go ahead and work on the implementation of these ideas for the simspark simulator, using the three threads which you mentioned above. To do this, please create a new branch in the CVS. Once everything is finished and tested, we'll incorporate it into the head. Please let us know in case there are any problems or you would like to get some feedback. By the way, just so that I can plan a little, could you please let me know when you think you could have a first version ready for test? I know this is hard to estimate, just try to give me a rough estimate (like Tom Howard mentioned before, estimating is an impossible task, don't worry about having to correct it later). Thanks a lot! Cheers, Joschka |
|
From: Yuan X. <xuy...@gm...> - 2007-03-01 05:18:47
|
Hi Joschka and all, I am working on my team now. I tried to draw the model specification of soccerbot, I doubt about (setLocalRotation 0 0 180) the line 273 in soccerbot.rsg in rcssserver3d-0.5.3 or line 249 in http://www.uni-koblenz.de/~murray/robocup/soccerbot.rsg I want to know is there need this rotation? Because other right joints are the same direction with the left joints. And do you have the model specification graphic of soccerbot? And, in app/agentspark/main.cpp "bool GetMessage(string& msg)" function, I think there is another bug which caused the segment fault: while (msgRead < msgLen) { if (! SelectInput()) { return false; } msgRead += read(gSocket.getFD(), offset, sizeof(buffer) - msgRead); //cerr << "msgRead = |" << msgRead << "|\n"; offset += msgRead; <-------------BUG????? } Hope helps. -- Best wishes! Xu Yuan School of Automation Southeast University, Nanjing, China mail: xuy...@gm... xy...@ya... web: http://xuyuan.cn.googlepages.com -------------------------------------------------- |
|
From: Joschka B. <jbo...@un...> - 2007-03-02 09:59:48
|
Hi Yuan, Yuan Xu wrote: > > I am working on my team now. > I tried to draw the model specification of soccerbot, > I doubt about (setLocalRotation 0 0 180) > the line 273 in soccerbot.rsg in rcssserver3d-0.5.3 > or line 249 in http://www.uni-koblenz.de/~murray/robocup/soccerbot.rsg > > I want to know is there need this rotation? > Because other right joints are the same direction with the left joints. After having a quick look, I think you're right. This rotation is not needed. I can't test reliably test though right now, because I kind of messed up my SimSpark installation. I'll try again later with a fresh version from the CVS. > And do you have the model specification graphic of soccerbot? > > I'm working on it :-) > And, in app/agentspark/main.cpp "bool GetMessage(string& msg)" function, > I think there is another bug which caused the segment fault: > > > while (msgRead < msgLen) > { > if (! SelectInput()) > { > return false; > } > > msgRead += read(gSocket.getFD(), offset, sizeof(buffer) - > msgRead); > //cerr << "msgRead = |" << msgRead << "|\n"; > offset += msgRead; <-------------BUG????? > } I think you're right again about the bug, but I think it is 2 lines above. In my oppinion, it should be: msgRead += read(gSocket.getFD(), offset, sizeof(buffer) - bytesRead); Example: Say we got a message of 20kB, but our buffer is only 16kB. After the first read in that function, bytesRead will be 16384 which is the maximum. msgLen will be 20000. The first 4 Bytes are the length prefix which is subtracted from bytesRead and stored in msgRead, so it will be 16380. Since msgRead is less than msgLen, we will enter the while loop. Offset was set to the beginning of the buffer + bytesRead which means it's at the end of the buffer. The read inside the loop will, however, still read 4 Bytes if sizeof(buffer) - msgRead is used for the length. This will result in a segfault. Right? Cheers, Joschka |
|
From: Yuan X. <xuy...@gm...> - 2007-03-02 11:20:59
Attachments:
soccerbotModel.png
|
Hi Joschka,
>
> > And do you have the model specification graphic of soccerbot?
> >
> >
>
> I'm working on it :-)
>
I have one, and attached it. (the right shoulder not be rotated)
hope helps ;-)
--
Best wishes!
Xu Yuan
School of Automation
Southeast University, Nanjing, China
mail: xuy...@gm...
xy...@ya...
web: http://xuyuan.cn.googlepages.com
--------------------------------------------------
|
|
From: Joschka B. <jbo...@un...> - 2007-03-02 11:29:33
|
Hi Yuan, Yuan Xu wrote: > Hi Joschka, > > >> >> > And do you have the model specification graphic of soccerbot? >> > >> > >> >> I'm working on it :-) >> > > I have one, and attached it. (the right shoulder not be rotated) > hope helps ;-) Awesome! Much better than mine :-) I'm finally going to work on some documentation tomorrow and I'd like to put your figure in the wiki. Is that okay? Cheers, Joschka |
|
From: Oliver O. <fr...@ro...> - 2007-03-15 21:50:36
|
Hi, On 15/03/2007, at 11:19 PM, Yuan Xu wrote: > when I let the agent control in the main thread, > and other loops in the new thread, > it works! > It seems that the ruby need the initialization in the new thread, > is it? Yeah, this might be the problem. I hadn't much time to try so far, but if it works for you, it's hopefully also the solution... cheers Oliver -- Oliver Obst ES208 form follows function (Louis Sullivan). Fon: +61 2 492 16175 http://oliver.obst.eu/ Uni Newcastle School of Electrical Engineering and Computer Science |
|
From: Markus R. <rol...@un...> - 2007-03-15 21:53:48
|
Hi, Yuan Xu wrote: > Firstly, I create a global mutex that all ruby functions should call > before doing anything. But it will cause dead lock, because there are > recursive calls between Ruby and C++. [...] You could use a recursive mutex to avoid this. This kind of mutex allows the owning thread to lock it repeatedly without deadlocking. The boost library contains a boost/thread/recursive_mutex.hpp file for this purpose. regards. Markus |
|
From: Yuan X. <xuy...@gm...> - 2007-03-16 01:37:08
|
Hi,
> You could use a recursive mutex to avoid this. This kind of mutex allows
> the owning thread to lock it repeatedly without deadlocking. The boost
> library contains a boost/thread/recursive_mutex.hpp file for this purpose.
I have tried the recursive mutex,
but the ruby still can not be called in the new thread ;-(
I'll do more try.
--
Best wishes!
Xu Yuan
School of Automation
Southeast University, Nanjing, China
mail: xuy...@gm...
xy...@ya...
web: http://xuyuan.cn.googlepages.com
--------------------------------------------------
|
|
From: Yuan X. <xuy...@gm...> - 2007-02-04 04:50:19
|
2007/2/3, Oliver Obst <Oli...@ne...>: > sounds all quite good. > I've also found this hints for timing the physics loop (in a computer > game) here: [1], it's an interesting read, at least. From this page, > there are also more interesting articles. > > I'm also re-directing this thread to the simspark-devel mailing list > (I know you're all subscribed :-), because the advantage of this list > is that everybody interested can read what's going on and the emails > get archived automatically. Please, let's continue our discussions > there. > > cheers > Oliver > > [1] http://www.gaffer.org/game-physics/fix-your-timestep/ > The article is great! There is a similar implementation in the simspark ( See void SimulationServer::Step() ). Set the mSimStep to 0.01, then the physics will run in 10ms step. I face a problem when try introduce the threads: there is only one scene information in the simulator, then, different threads can not operate the scene information at the same time. For example, when the agent-management-thread encodes the perception messages, the scene information should not be changed, so the physics-thread should be hang up. As a result, this kind multi-threads is meaningless, I think. Maybe we need a buffer, like the frame buffer in OpenGL, saving the scene information which will be handled by agent-management-thread to the buffer. But it is not a straight-forward work, for the scene information is stored in different objects. If there is a class or struct represent the scene information, the work will be easier. But the plug-in mechanism makes the scene changes, so build such a scene class is not simple. Any ideas? -- Best wishes! Xu Yuan School of Automation Southeast University, Nanjing, China mail: xuy...@gm... xy...@ya... web: http://xuyuan.cn.googlepages.com -------------------------------------------------- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X