Menu
▾
▴
simspark-devel — Discussion about Spark development
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2007 |
Jan
|
Feb
(24) |
Mar
(19) |
Apr
(2) |
May
(45) |
Jun
(80) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(13) |
Feb
(57) |
Mar
(48) |
Apr
(71) |
May
(22) |
Jun
(26) |
Jul
(10) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(21) |
Dec
(15) |
| 2009 |
Jan
(33) |
Feb
(36) |
Mar
(30) |
Apr
(8) |
May
(5) |
Jun
(29) |
Jul
(21) |
Aug
(4) |
Sep
(3) |
Oct
(9) |
Nov
(38) |
Dec
(17) |
| 2010 |
Jan
(13) |
Feb
(24) |
Mar
(18) |
Apr
(16) |
May
(13) |
Jun
(25) |
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
(18) |
Dec
(2) |
| 2011 |
Jan
(2) |
Feb
(15) |
Mar
(15) |
Apr
(7) |
May
(16) |
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(4) |
Dec
(1) |
| 2012 |
Jan
(6) |
Feb
|
Mar
(9) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2013 |
Jan
(4) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(8) |
Jun
(15) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Markus R. <rol...@un...> - 2008-06-16 16:46:17
|
Hi, Hedayat Vatankhah wrote: [...] > It seems that voidmeshimporter is not used currently right?! So in the > worst case I should be able to remove this plugin from the package (?). yes the VoidMeshImporter is currently unused and I don't know how to create applicable files. I think it was a custom file format to demonstrate the fancy lighting part of the OpenGLServer. So I think we could remove it safely. cheers, Markus |
|
From: Hedayat V. <hed...@ai...> - 2008-06-16 07:47:38
|
Hi Markus, Thanks for your answer. I've tried removing these files from server, but they are used by voidmeshimporter plug-in. Anyway, I think the license should be acceptable as a free license. It seems that voidmeshimporter is not used currently right?! So in the worst case I should be able to remove this plugin from the package (?). Thanks again, Hedayat /*Markus Rollmann <rol...@un...>*/ wrote on 06/16/2008 12:59:38 AM: > Hi, > > Hedayat Vatankhah wrote: >> A little question: please let me know about the license of the files >> at lib/kerosin/sceneserver/helper/. >> It seems that they are from NVidia SDK right? > > Yes these are from the NVDIA SDK [1]. > >> It would be nice if someone could send the information. I should >> clarify their license status for my rcssserver3d package to be >> accepted in Fedora. > > I think the applicable license is found at [2]. > > The NVIDIA MeshMender is a helper tool for per pixel lightning that > was part of the original fancy lighting implementation that is > currently unused or commented out completely in the OpenGLServer. > > Therefore I think we could also remove the NVIDIA files from the CVS > if necessary. > > cheers, > Markus > > [1] http://developer.nvidia.com/object/NVMeshMender.html > [2] http://developer.download.nvidia.com/licenses/general_license.txt > |
|
From: Markus R. <rol...@un...> - 2008-06-15 20:30:05
|
Hi, Hedayat Vatankhah wrote: > A little question: please let me know about the license of the files at > lib/kerosin/sceneserver/helper/. > It seems that they are from NVidia SDK right? Yes these are from the NVDIA SDK [1]. > It would be nice if someone could send the information. I should clarify > their license status for my rcssserver3d package to be accepted in Fedora. I think the applicable license is found at [2]. The NVIDIA MeshMender is a helper tool for per pixel lightning that was part of the original fancy lighting implementation that is currently unused or commented out completely in the OpenGLServer. Therefore I think we could also remove the NVIDIA files from the CVS if necessary. cheers, Markus [1] http://developer.nvidia.com/object/NVMeshMender.html [2] http://developer.download.nvidia.com/licenses/general_license.txt |
|
From: Hedayat V. <hed...@ai...> - 2008-06-15 18:50:44
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi all,<br> A little question: please let me know about the license of the files at lib/kerosin/sceneserver/helper/.<br> It seems that they are from NVidia SDK right? <br> <br> It would be nice if someone could send the information. I should clarify their license status for my rcssserver3d package to be accepted in Fedora.<br> <br> Thanks a lot,<br> Hedayat<br> </body> </html> |
|
From: Hedayat V. <hed...@ai...> - 2008-06-13 21:12:05
|
Hi, Thanks anyway. It seems that the only way to fix is to change the permissions of the files in the repository directly (using chmod command on the host) which is impossible in sf.net (I think!). The file permissions are the same as the permissions of the files when they are added to the repository. So, these files have executable permission when they were added to the repository. We should check the permission of the files before adding new files to CVS. (http://alexandria.wiki.sourceforge.net/CVS+-+Version+Control+for+Source+Code#tocCVS%20-%20Version%20Control%20for%20Source%20Code16) It seems that the only way (which might work!) to correct these permissions is to remove these files from CVS, correct the local file permissions and re-add them to CVS. :( Thanks anyway, Hedayat /*Markus Rollmann <rol...@un...>*/ wrote on 06/13/2008 01:53:07 PM: > Hi, > > Hedayat Vatankhah wrote: >> Some of the CVS files have wrong permissions (executable permission). >> Is there any way to fix them? > > Yes you're right. > > If you check out the skybox textures again from a linux box the 'x' > flag is set. I don't know why this happens. Maybe the binary flag > implies this? But it's not true for all textures in the CVS (the all > have to binary flag set) > > I did not find any hint in the CVS manuals [1] > > cheers, > Markus > > [1] http://ximbiot.com/cvs/manual/ |
|
From: Yuan X. <xuy...@gm...> - 2008-06-13 09:24:39
|
Hi, Thanks for your instruction. ;-) 2008/6/13 Markus Rollmann <rol...@un...>: > Hi, > > Xu Yuan wrote: >> Update of /cvsroot/sserver/rcsoccersim/rcssserver3D/app/simspark/rsg/agent/nao >> In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv12781/rsg/agent/nao > [...] >> Log Message: >> * app/simspark/materials/skybox.mtl: >> * app/simspark/models/skybox.obj: >> * app/simspark/rsg/agent/nao/soccer.rsg: >> * app/simspark/textures/skyrender0001.jpg: >> * app/simspark/textures/skyrender0002.jpg: >> * app/simspark/textures/skyrender0003.jpg: >> * app/simspark/textures/skyrender0004.jpg: >> * app/simspark/textures/skyrender0005.jpg: >> * app/simspark/textures/skyrender0006.jpg: >> - add skybox for the soccer field > > nice skybox ;-) > > There is one problem though. If you add binary files to the CVS please > use the CVS flag -kb to mark them as binary, i.e. use > > cvs add -kb skyrender0006.jpg > > otherwise CVS treats them as text files and replaces newlines when they > are checked out on a windows box. I fixed this already. This is possible > with the CVS admin command, e.g. > > cvs admin -kb skyrender0006.jpg > > cheers, > Markus > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > -- Best wishes! Xu Yuan School of Automation Southeast University, Nanjing, China mail: xuy...@gm... xy...@ya... web: http://xuyuan.cn.googlepages.com -------------------------------------------------- |
|
From: Markus R. <rol...@un...> - 2008-06-13 09:23:30
|
Hi, Hedayat Vatankhah wrote: > Some of the CVS files have wrong permissions (executable permission). Is > there any way to fix them? Yes you're right. If you check out the skybox textures again from a linux box the 'x' flag is set. I don't know why this happens. Maybe the binary flag implies this? But it's not true for all textures in the CVS (the all have to binary flag set) I did not find any hint in the CVS manuals [1] cheers, Markus [1] http://ximbiot.com/cvs/manual/ |
|
From: Hedayat V. <hed...@ai...> - 2008-06-13 09:10:24
|
Hi Markus, Some of the CVS files have wrong permissions (executable permission). Is there any way to fix them? Thanks, Hedayat /*Markus Rollmann <rol...@un...>*/ wrote on 06/13/2008 01:16:18 PM: > Hi, > > Xu Yuan wrote: > >> Update of /cvsroot/sserver/rcsoccersim/rcssserver3D/app/simspark/rsg/agent/nao >> In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv12781/rsg/agent/nao >> > [...] > >> Log Message: >> * app/simspark/materials/skybox.mtl: >> * app/simspark/models/skybox.obj: >> * app/simspark/rsg/agent/nao/soccer.rsg: >> * app/simspark/textures/skyrender0001.jpg: >> * app/simspark/textures/skyrender0002.jpg: >> * app/simspark/textures/skyrender0003.jpg: >> * app/simspark/textures/skyrender0004.jpg: >> * app/simspark/textures/skyrender0005.jpg: >> * app/simspark/textures/skyrender0006.jpg: >> - add skybox for the soccer field >> > > nice skybox ;-) > > There is one problem though. If you add binary files to the CVS please > use the CVS flag -kb to mark them as binary, i.e. use > > cvs add -kb skyrender0006.jpg > > otherwise CVS treats them as text files and replaces newlines when they > are checked out on a windows box. I fixed this already. This is possible > with the CVS admin command, e.g. > > cvs admin -kb skyrender0006.jpg > > cheers, > Markus > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > |
|
From: Markus R. <rol...@un...> - 2008-06-13 08:46:46
|
Hi, Xu Yuan wrote: > Update of /cvsroot/sserver/rcsoccersim/rcssserver3D/app/simspark/rsg/agent/nao > In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv12781/rsg/agent/nao [...] > Log Message: > * app/simspark/materials/skybox.mtl: > * app/simspark/models/skybox.obj: > * app/simspark/rsg/agent/nao/soccer.rsg: > * app/simspark/textures/skyrender0001.jpg: > * app/simspark/textures/skyrender0002.jpg: > * app/simspark/textures/skyrender0003.jpg: > * app/simspark/textures/skyrender0004.jpg: > * app/simspark/textures/skyrender0005.jpg: > * app/simspark/textures/skyrender0006.jpg: > - add skybox for the soccer field nice skybox ;-) There is one problem though. If you add binary files to the CVS please use the CVS flag -kb to mark them as binary, i.e. use cvs add -kb skyrender0006.jpg otherwise CVS treats them as text files and replaces newlines when they are checked out on a windows box. I fixed this already. This is possible with the CVS admin command, e.g. cvs admin -kb skyrender0006.jpg cheers, Markus |
|
From: Sander v. D. <sgv...@gm...> - 2008-06-11 10:31:34
|
Hey, You are right.. I could have sworn I tried all joints.. :( I indeed meant the soccerbot058 model and yeah it uses the same hinge joint as Nao. I don't understand why one explodes and the other doesn't either. Looking at nao/universaljoint.rsg however seems to indicate that the stop CFM and ERP values are only set for the first axis of the joint, not the second. This might explain some of it. Sander On Wed, Jun 11, 2008 at 11:00 AM, Feng Xue <hen...@ma...> wrote: > Hey, > > Thank you for your quick reply > > Please try the first joint in the arm of Nao. It happens every time > for me. :-( > > BTW: does "058" mean soccerbot058? Yuan told me he uses the > joint SPEC from the rsg/agent/Nao directory. So, why didn't Nao > explode? > > ------------------------------ > Best Regards, > Feng Xue > 2008-06-11 > ------------------------------ > *Sent By：* Sander van Dijk > *Sent At：* 2008-06-11 16:50:15 > *Sent To：* Feng Xue > *CC To：* Joschka Boedecker; simspark-devel > *Topic：* Re: [simspark-devel] status of development > > Hey, > > The current 058 has a more important bug: it explodes everytime when you > try to move the joint away from the max/min angle. Setting both the fudge > factor and the bounce to 0 solves this for me, it also solves the shaking > problem for the Nao. I have tried it many times and couldn't get the joints > 'stuck' at their min or max value, like you report. I will test on some more > machines though. If it does occur it's a bigger problem then the shaking and > then I think your solution is good. > > Sander > > On Wed, Jun 11, 2008 at 10:00 AM, Feng Xue <hen...@ma...> > wrote: > >> Dear all, >> >> As the Email below said, there is a shake bug if the joint >> reaches its max/min angle and is set positive/negative >> speed. >> >> According to team's reports(the explosion problem), I think >> maybe this shake bug contributes something, so I decide to >> disable the shake in hingeffector.cpp and universaleffector.cpp >> by: >> If in min angle, negative speed will be rejected. >> If in max angle, positive speed will be rejected. >> >> These codes will change the physic performance a tiny little. >> But since we will only change the vision in the next release, >> I ask for an authorization :-) >> >> ------------------------------ >> Best Regards, >> Feng Xue >> 2008-06-11 >> ------------------------------ >> *Sent By：* Feng Xue >> *Sent At：* 2008-05-30 22:18:45 >> *Sent To：* Joschka Boedecker >> *CC To：* Yuan Xu; Mosalam Ebrahimi; Ben >> *Topic：* Re: status of development >> >> Hi all, >> >> I have refined the physics parameters now. It seems good >> according to my test. I hope it can be a RC version. >> >> >> And, I came across a small problem. To make the joint move >> smoothly, I have to set dFudgeParameter to a small value orelse >> there will be a jitter problem. But, if this one is too small and >> the joint reaches/overruns its min/max value, it will never work( >> never come back again) So I have to set the dBounce to 1 to make >> it work. And, this will make the joint shake on the max/min >> position if the agent keeps sending positive/negative joint speed. >> I set the maxforce to 10 and is much better. At least, >> teams might not use this "bug" to make some strange movements :-) >> >> >> I believe soccerbot has the same problems too. Talked about the >> soccerbot, here is my opinion. I think we'd better make a stable, >> robust RC version because it is 44 days left now. Adjusting soccerbot >> will cost lots of extra energy. Allowing different robots playing >> on the same field at the same time is very great feature, but again, >> we don't have lots of time to make the match be fairly enough to both >> soccerbot and Nao. >> >> >> And, here is my test report of how many robots can it sim. I only >> do the test with the intergrated monitor for our Nao has reached and >> lots of things are on board now... >> Machine: >> CPU: Intel E8200 2.66GHZ >> Mem: 2G >> Graphic Card: Nvidia 8600GT >> Type 1: Single Thread: >> Type 1.1: disable inner collision: can sim 7 robots smoothly >> Type 1.2: add inner collision: 3 too near robots make game unstable... >> Type 2: Multi Thread: >> Type 2.1: disable inner collision: can sim 7 robots smoothly >> Type 2.2: add inner collision: can sim 7 robots smoothly >> I have send this report to Yuan and he will do the outside monitor test. >> And the result seems not good because our target is 5 vs 5 :-( >> >> >> And, another thing, with the joint limit and the max joint speed feature, >> the robot is much more like the real Nao or humanoid robot. And getup is >> a >> very difficult action. So we'd better implement an extra command like >> 'beam' if all the teams failed to realize getup action :-) But no hurry, >> we need feedback from teams. >> >> >> ------------------------------ >> Best Regards, >> Feng Xue >> 2008-05-30 >> ------------------------------ >> *Sent By：* Joschka Boedecker >> *Sent At：* 2008-05-30 00:20:34 >> *Sent To：* Yuan Xu; Ben; Feng Xue >> *CC To：* Mosalam Ebrahimi >> *Topic：* status of development >> >> Hi all, >> I'm sorry that I've not been able to follow the server development too >> closely recently :-( I know that some of you have been working on the >> restricted vision perceptor, and some TC members have been asking >> about the status of its development. Could you please give me an >> update on that, and what features were implemented? Also: how about >> testing, does it work reliably? >> @Yuan: Sahar has asked whether it would be possible to make the final >> release for RC08 at the end of this week. Concerning the changes that >> affect the game play, I think we have implemented everything we >> planned for, right? We can still improve the visuals until middle of >> July since they don't affect the game... Do you think you could make >> the release this weekend or early next week? >> Thanks to everybody in advance for the information, and big thanks for >> your great work with the development this year! >> Best regards, >> Joschka >> >> ------------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> Simspark Generic Physical MAS Simulator >> simspark-devel mailing list >> sim...@li... >> https://lists.sourceforge.net/lists/listinfo/simspark-devel >> >> > |
|
From: Sander v. D. <sgv...@gm...> - 2008-06-11 08:49:35
|
Hey, The current 058 has a more important bug: it explodes everytime when you try to move the joint away from the max/min angle. Setting both the fudge factor and the bounce to 0 solves this for me, it also solves the shaking problem for the Nao. I have tried it many times and couldn't get the joints 'stuck' at their min or max value, like you report. I will test on some more machines though. If it does occur it's a bigger problem then the shaking and then I think your solution is good. Sander On Wed, Jun 11, 2008 at 10:00 AM, Feng Xue <hen...@ma...> wrote: > Dear all, > > As the Email below said, there is a shake bug if the joint > reaches its max/min angle and is set positive/negative > speed. > > According to team's reports(the explosion problem), I think > maybe this shake bug contributes something, so I decide to > disable the shake in hingeffector.cpp and universaleffector.cpp > by: > If in min angle, negative speed will be rejected. > If in max angle, positive speed will be rejected. > > These codes will change the physic performance a tiny little. > But since we will only change the vision in the next release, > I ask for an authorization :-) > > ------------------------------ > Best Regards, > Feng Xue > 2008-06-11 > ------------------------------ > *Sent By：* Feng Xue > *Sent At：* 2008-05-30 22:18:45 > *Sent To：* Joschka Boedecker > *CC To：* Yuan Xu; Mosalam Ebrahimi; Ben > *Topic：* Re: status of development > > Hi all, > > I have refined the physics parameters now. It seems good > according to my test. I hope it can be a RC version. > > > And, I came across a small problem. To make the joint move > smoothly, I have to set dFudgeParameter to a small value orelse > there will be a jitter problem. But, if this one is too small and > the joint reaches/overruns its min/max value, it will never work( > never come back again) So I have to set the dBounce to 1 to make > it work. And, this will make the joint shake on the max/min > position if the agent keeps sending positive/negative joint speed. > I set the maxforce to 10 and is much better. At least, > teams might not use this "bug" to make some strange movements :-) > > > I believe soccerbot has the same problems too. Talked about the > soccerbot, here is my opinion. I think we'd better make a stable, > robust RC version because it is 44 days left now. Adjusting soccerbot > will cost lots of extra energy. Allowing different robots playing > on the same field at the same time is very great feature, but again, > we don't have lots of time to make the match be fairly enough to both > soccerbot and Nao. > > > And, here is my test report of how many robots can it sim. I only > do the test with the intergrated monitor for our Nao has reached and > lots of things are on board now... > Machine: > CPU: Intel E8200 2.66GHZ > Mem: 2G > Graphic Card: Nvidia 8600GT > Type 1: Single Thread: > Type 1.1: disable inner collision: can sim 7 robots smoothly > Type 1.2: add inner collision: 3 too near robots make game unstable... > Type 2: Multi Thread: > Type 2.1: disable inner collision: can sim 7 robots smoothly > Type 2.2: add inner collision: can sim 7 robots smoothly > I have send this report to Yuan and he will do the outside monitor test. > And the result seems not good because our target is 5 vs 5 :-( > > > And, another thing, with the joint limit and the max joint speed feature, > the robot is much more like the real Nao or humanoid robot. And getup is a > very difficult action. So we'd better implement an extra command like > 'beam' if all the teams failed to realize getup action :-) But no hurry, > we need feedback from teams. > > > ------------------------------ > Best Regards, > Feng Xue > 2008-05-30 > ------------------------------ > *Sent By：* Joschka Boedecker > *Sent At：* 2008-05-30 00:20:34 > *Sent To：* Yuan Xu; Ben; Feng Xue > *CC To：* Mosalam Ebrahimi > *Topic：* status of development > > Hi all, > I'm sorry that I've not been able to follow the server development too > closely recently :-( I know that some of you have been working on the > restricted vision perceptor, and some TC members have been asking > about the status of its development. Could you please give me an > update on that, and what features were implemented? Also: how about > testing, does it work reliably? > @Yuan: Sahar has asked whether it would be possible to make the final > release for RC08 at the end of this week. Concerning the changes that > affect the game play, I think we have implemented everything we > planned for, right? We can still improve the visuals until middle of > July since they don't affect the game... Do you think you could make > the release this weekend or early next week? > Thanks to everybody in advance for the information, and big thanks for > your great work with the development this year! > Best regards, > Joschka > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > |
|
From: Feng X. <hen...@ma...> - 2008-06-11 08:01:15
|
Dear all,
As the Email below said, there is a shake bug if the joint
reaches its max/min angle and is set positive/negative
speed.
According to team's reports(the explosion problem), I think
maybe this shake bug contributes something, so I decide to
disable the shake in hingeffector.cpp and universaleffector.cpp
by:
If in min angle, negative speed will be rejected.
If in max angle, positive speed will be rejected.
These codes will change the physic performance a tiny little.
But since we will only change the vision in the next release,
I ask for an authorization :-)
Best Regards,
Feng Xue
2008-06-11
Sent By： Feng Xue
Sent At： 2008-05-30 22:18:45
Sent To： Joschka Boedecker
CC To： Yuan Xu; Mosalam Ebrahimi; Ben
Topic： Re: status of development
Hi all,
I have refined the physics parameters now. It seems good
according to my test. I hope it can be a RC version.
And, I came across a small problem. To make the joint move
smoothly, I have to set dFudgeParameter to a small value orelse
there will be a jitter problem. But, if this one is too small and
the joint reaches/overruns its min/max value, it will never work(
never come back again) So I have to set the dBounce to 1 to make
it work. And, this will make the joint shake on the max/min
position if the agent keeps sending positive/negative joint speed.
I set the maxforce to 10 and is much better. At least,
teams might not use this "bug" to make some strange movements :-)
I believe soccerbot has the same problems too. Talked about the
soccerbot, here is my opinion. I think we'd better make a stable,
robust RC version because it is 44 days left now. Adjusting soccerbot
will cost lots of extra energy. Allowing different robots playing
on the same field at the same time is very great feature, but again,
we don't have lots of time to make the match be fairly enough to both
soccerbot and Nao.
And, here is my test report of how many robots can it sim. I only
do the test with the intergrated monitor for our Nao has reached and
lots of things are on board now...
Machine:
CPU: Intel E8200 2.66GHZ
Mem: 2G
Graphic Card: Nvidia 8600GT
Type 1: Single Thread:
Type 1.1: disable inner collision: can sim 7 robots smoothly
Type 1.2: add inner collision: 3 too near robots make game unstable...
Type 2: Multi Thread:
Type 2.1: disable inner collision: can sim 7 robots smoothly
Type 2.2: add inner collision: can sim 7 robots smoothly
I have send this report to Yuan and he will do the outside monitor test.
And the result seems not good because our target is 5 vs 5 :-(
And, another thing, with the joint limit and the max joint speed feature,
the robot is much more like the real Nao or humanoid robot. And getup is a
very difficult action. So we'd better implement an extra command like
'beam' if all the teams failed to realize getup action :-) But no hurry,
we need feedback from teams.
Best Regards,
Feng Xue
2008-05-30
Sent By： Joschka Boedecker
Sent At： 2008-05-30 00:20:34
Sent To： Yuan Xu; Ben; Feng Xue
CC To： Mosalam Ebrahimi
Topic： status of development
Hi all,
I'm sorry that I've not been able to follow the server development too
closely recently :-( I know that some of you have been working on the
restricted vision perceptor, and some TC members have been asking
about the status of its development. Could you please give me an
update on that, and what features were implemented? Also: how about
testing, does it work reliably?
@Yuan: Sahar has asked whether it would be possible to make the final
release for RC08 at the end of this week. Concerning the changes that
affect the game play, I think we have implemented everything we
planned for, right? We can still improve the visuals until middle of
July since they don't affect the game... Do you think you could make
the release this weekend or early next week?
Thanks to everybody in advance for the information, and big thanks for
your great work with the development this year!
Best regards,
Joschka
|
|
From: Feng X. <hen...@ma...> - 2008-06-07 10:57:03
|
Hi Joschka,
I don't know why nao explodes when touching the ball and why
it will not explode if disabled the inner collision.
I heard the same explosion thing of Soccerbot. Do you think
they are because of the same bug?
Best Regards,
Feng Xue
2008-06-07
Sent By： Feng Xue
Sent At： 2008-06-07 18:41:01
Sent To： kam...@ya...
CC： Sse...@li...urceforg
Topic： Re: [Sserver-three-d] Nao explodes when touching the ball inserver0.5.9
Dear CB,
I observed this too. And I think it is an old bug since the soccerbot model.
The soccerbot was scaled 10 times because the original size is not stable.
There is a solution for this problem.
Please go to /usr/local/share/rcssserver3D/rsg/agent/nao/
And open "nao.rsg". There is a line "(disableInnerCollision false)". Please
set "false" to "true" to disable the inner collision of Nao. And the explosion
should never happen :-)
Thanks for your fast test!
Best Regards,
Feng Xue
2008-06-07
Sent By： C B
Sent At： 2008-06-07 18:20:20
Sent To： sse...@li...
CC To：
Topic： [Sserver-three-d] Nao explodes when touching the ball in server0.5.9
Hello,
The Nao robot always explodes when trying to touch the ball in server 0.5.9!!
I wonder why not even one team has reported this behavior before.
Is anyone even trying to use this model?
Does the soccerbot058 explodes too? We have not tested it yet.
We really want to hear comments on this.
Best regards,
Carlos Bustamante
Borregos3D
____________________________________________________________________________________
Yahoo! Deportes Beta
o te pierdas lo timo sobre el torneo clausura 2008! Entate aqu?http://deportes.yahoo.com
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Sserver-three-d mailing list
Sse...@li...
https://lists.sourceforge.net/lists/listinfo/sserver-three-d
|
|
From: Yuan X. <xuy...@gm...> - 2008-05-31 16:05:45
|
Hi all, The preview of rcssserver3d-0.5.9, please test it. You can get it from http://www.live-share.com/files/324810/rcssserver3d-0.5.9-preview.tar.gz.html And we plan to release the rcssserver-0.5.9 in next Monday. This release is the candidate of RoboCup 2008. There are some important improvements. Firstly, the physics parameters are well adjusted to make the simulation more real and stabler. Secondly, the restrict vision perceptor is used, with which the vision range is limited, but more details will be seen, i.e. the head, hands and feet of robots can be seen. Furthermore, the soccer rule and visual features are improved. * Physics Parameters: Some physics parameters are adjusted to make the simulation more real and stabler. - Joint parameters: the max force and max speed of the joint are restricted, and some other parameters are modified. - Ball parameters: the parameters of drag are modified. * Restrict Vision: The restrict vision perceptor is installed both in nao and soccerbot058. This perceptor have some restriction compared with original vision perceptor. Firstly, the robots can only see object in the limited angle range (both horizontal and vertical angle ranges are [-60, 60] in degree). Secondly, the frequent is restricted, the robot can get one vision message every 3 cycles. Furthermore, note that the noise is added to the vision information. However, the information is richer: the robot's torso, head, hands and feet can be seen. The flags placed in the field can also be seen (They are no visual in the screen now, but the robot can see them). Four flags are placed at the field corners (the height is 0), and the four flags are placed at the goal posts (the corner of the goal). * Visual: - The Nao robot can be identified by team colors and numbers. You can play a match with Nao robots ;-) - the monitor camera can be controlled by number keys (from 1 to 7) * Soccer Rule: - Field Size: the field size is 12mx8m, the center circle radius is 1.3m, the penalty size is 1.2mx4m. More information please see naosoccersim.rb. - Kick Off: the kicking off team can enter the center circle, and the opponents will be moved away from the center circle. -- 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...> - 2008-05-30 02:38:26
|
Hi all, I just use this to make sure what will be contained in the rcssserver3d-0.5.9. Please correct me, if there is anything wrong. > * crash of simspark when started outside of local directory Fined by Hedayat. > * InitEffector: needs to deal with several materials Finished, the Nao robot is identified with team colors and numbers. > * usemtl null in torso .obj file of Nao Fixed. > * no camera error (maybe just on my own machine?) Need to do. > * read camera positions for the monitor from configuration file Need to do. > * restricted vision perceptor and changes in the vision message (see my last > mail to simspark-devel) Draft. Need test? > * unify material names used in the different .blend files (e.g. naowhite, > naoblue, naoread, etc., maybe this is fixed already, but a while ago I > noticed that there were many different names resulting in many different > materials being created unnecessarily) Finished, all Nao .obj files use one materials file(nao.mtl) now. > > Later, we'll also need: > > * integrate Soccerbot meshes (as soon as I get them from Heni) Waiting... > * 3D model of the goal for the Nao simulation (I'll try to model this in > Blender, but I'm too busy right now) No hurry. > * adjust field size (right now, it seems we'll have 12mx8m field size), > including colliders, etc. I will do it. > * try to get a model of either: a skybox around the pitch, or a kind of hall > (like in RoboCup ;-) ), but this is just for having nice visuals ;-) No hurry. > * ball parameters (do we need to change them?) Done by Feng. -- Best wishes! Xu Yuan School of Automation Southeast University, Nanjing, China mail: xuy...@gm... xy...@ya... web: http://xuyuan.cn.googlepages.com -------------------------------------------------- |
|
From: Sander v. D. <sgv...@gm...> - 2008-05-26 08:20:35
|
Hey, On Mon, May 26, 2008 at 5:13 AM, Feng Xue <hen...@ma...> wrote: > Considering the two points, here is a draft solution: > 1. Not add collider to the body that is in another body. > This idea is from Joschka and has finished. > I think is is a good idea, perhaps this also solves the problem when two agents get beamed into each other? Though have to take care when bodies penetrate each other due to sponginess of one of the bodies. > 3. Add the pairs that should not collide. In the current > nao model, we need to add these pairs: > (1) torso and left thigh > (2) torso and right thigh > (3) left shank and left foot > (4) right shank and right foot > > (5) torso and left shoulder > (6) torso and right shoulder > > If I understand Space::HandleCollide correctly (lib/oxygen/physicsserver/space.cpp, lines 97-103) it is already default in a Space that two bodies that are directly linked to each other do not collide. This can make 3 and 4 work if a universal joint is used, 5 and 6 are already directly connected. For 1 and 2 this won't help I guess, since there are 3 DOFs in them and only 2 fit in a universal joint. For now explicitly setting which things can't touch each other will work, however I'm still for using better collider shapes in the end. Beside this, but related to the joints: I have noticed a lot of drift in joint positions with the Nao model. If a limb is pushed against another part of the body, it's joint moves significantly. For instance if the right leg is pushed to the left, the hip joint moves to the right. There is an ODE parameter to control this, I tried to find it quickly now but haven't found it. I hope you know what I mean :) Sander |
|
From: Feng X. <hen...@ma...> - 2008-05-26 03:14:15
|
Hi all,
In the previous Email, I've said that it is hard to
change hingejoint to universaljoint. And now I find
another reason. The torso and the thigh should not
collide in the Nao model. And however, uniting any two
of the three joints(in the hip) will let them collide.
However, disable the inner collision is good for
performance but is bad for looking.(some robot state
looks quite strange)
Considering the two points, here is a draft solution:
1. Not add collider to the body that is in another body.
This idea is from Joschka and has finished.
2. Remove "disableInnerCollision"
3. Add the pairs that should not collide. In the current
nao model, we need to add these pairs:
(1) torso and left thigh
(2) torso and right thigh
(3) left shank and left foot
(4) right shank and right foot
(5) torso and left shoulder
(6) torso and right shoulder
Any comments?
Best Regards,
Feng Xue
2008-05-26
|
|
From: Markus R. <rol...@un...> - 2008-05-24 12:50:45
|
Hi Ben, Ben schrieb: > Currently I'm working on restricted vision perceptor(rvp). Though it > can be used now, but I get puzzled about 'AgentAspect'. In > 'GameControlServer::AgentConnect', a new 'AgentAspect' is created, > and in the rsg file, there is another one. As I read the code of > 'plugin/soccer', I found that they are dependent on the rsg one. Why > should there be two 'AgentAspect'? I can only think out one usage. In > 'MoveAgent', there should have a part to be referenced. There should be only one AgentAspect per agent instance. The AgentAspects are created from the GameControlServer that uses them to manage the agents. If there is an AgentAspect created from an .rsg file it is an error, as the GameControlServer uses it's AgentAspect but if you search from within the SceneGraph for the right AgentAspect you might first find the one from the .rsg file. cheers, Markus |
|
From: Ben <lgp...@16...> - 2008-05-24 08:46:54
|
Hi, all: Currently I'm working on restricted vision perceptor(rvp). Though it can be used now, but I get puzzled about 'AgentAspect'. In 'GameControlServer::AgentConnect', a new 'AgentAspect' is created, and in the rsg file, there is another one. As I read the code of 'plugin/soccer', I found that they are dependent on the rsg one. Why should there be two 'AgentAspect'? I can only think out one usage. In 'MoveAgent', there should have a part to be referenced. Any other usage? Best wishes! Ben |
|
From: Hedayat V. <hed...@ai...> - 2008-05-19 19:10:47
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi Yuan,<br>
<br>
<": <br>
<br>
Thanks a lot!<br>
Hedayat<br>
<span><br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;} blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important} blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important} blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important} blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>"Yuan
Xu" <a class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm..."><xuy...@gm...></a></b></i> wrote on 05/19/2008 07:00:29 PM:</span><br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" cite="mid:18a...@ma..." type="cite">
<pre wrap="">Hi Hedayat,
</pre>
<blockquote type="cite">
<pre wrap="">We (our team) still don't know if we can
register and participate in the competitions, and we are struggling about
some issues... :(. That's too bad, we hoped to be able to participate this
year. Anyway, I'm just a bit tired and it takes me some time to refresh.
I've fixed this problem.
</pre>
</blockquote>
<pre wrap=""><!---->
I am sorry to hear that. You have done great work!
</pre>
<blockquote type="cite">
<pre wrap="">(And something off topic:
Recently I saw this: <a class="moz-txt-link-freetext" href="http://fedoraproject.org/wiki/SIGs/Robotics">http://fedoraproject.org/wiki/SIGs/Robotics</a>. They are
interested in our server, so I decided to go for it. Hopefully (if
everything goes well), rcssserver3d will become a part of Fedora - an
official Fedora package :) )
</pre>
</blockquote>
<pre wrap=""><!---->
That's great!
This would make the installation easily.
And we can use Fedora in the competition ;-)
</pre>
</blockquote>
</body>
</html>
|
|
From: Yuan X. <xuy...@gm...> - 2008-05-19 14:30:52
|
Hi Hedayat, > We (our team) still don't know if we can > register and participate in the competitions, and we are struggling about > some issues... :(. That's too bad, we hoped to be able to participate this > year. Anyway, I'm just a bit tired and it takes me some time to refresh. > I've fixed this problem. I am sorry to hear that. You have done great work! > > (And something off topic: > Recently I saw this: http://fedoraproject.org/wiki/SIGs/Robotics. They are > interested in our server, so I decided to go for it. Hopefully (if > everything goes well), rcssserver3d will become a part of Fedora - an > official Fedora package :) ) That's great! This would make the installation easily. And we can use Fedora in the competition ;-) -- Best wishes! Xu Yuan School of Automation Southeast University, Nanjing, China mail: xuy...@gm... xy...@ya... web: http://xuyuan.cn.googlepages.com -------------------------------------------------- |
|
From: Feng X. <hen...@ma...> - 2008-05-18 14:19:10
|
Hey,
Thanks for your quick reply!
It is not because of the contact joint thing because I didn't handle any collision...
And, one more thing, can you give a manual of how to use the Camera perceptor?
It seems that it didn't work according to the msg received by the agent.
Best Regards,
Feng Xue
2008-05-18
Sent By： Sander van Dijk
Sent At： 2008-05-18 22:09:29
Sent To： Feng Xue
CC To： Joschka Boedecker; Yuan Xu; simspark-devel
Topic： Re: Re: Re: [simspark-devel] Simspark Todo
Hey,
2008/5/18 Feng Xue <hen...@ma...>:
Hey,
About the motors, I think setting them as correct as described in the document is not necessary. Besides, the motors in the leg has stronger force compared to that in the arm. But it is hard to represent it via setting dParamMaxForce because ODE is taking this parameter as a reference, not strictly accuracy according to my experiments. I logged the feedback of body1 and body2, and the torque added to body1 and body2 is larger than the value set via dParamMaxForce. This is particularly strange.
Were these much larger? Maybe these extra torques are due to contact forces on the two bodies? Again, I don't know yet if this is necesary, we will have to see what behaviors people come up with. It might just make it even a bit more realistic.
About the universaljoint, here is my reasons that I abandon the universaljoint that time:
1. It is not as good as hingejoint in the joint limit aspect.
2. The two axises of universaljoint has orders. Which axis goes first depends on the parameter sequence passed to dJoitnAttach. It is not as clearly as two hingejoint.
OK sounds fair, I was just wondering about it :-)
Anyway, I'll try to test universal joint since universal joint is used in soccerbot now.
OK. you're doing great work! hopefully I can actually do some work soon again too, instead of just talk ;-)
Sander
|
|
From: Sander v. D. <sgv...@gm...> - 2008-05-18 14:08:54
|
Hey, 2008/5/18 Feng Xue <hen...@ma...>: > Hey, > > About the motors, I think setting them as correct as described in the > document is not necessary. Besides, the motors in the leg has stronger > force compared to that in the arm. But it is hard to represent it via > setting dParamMaxForce because ODE is taking this parameter as a reference, > not strictly accuracy according to my experiments. I logged the feedback of > body1 and body2, and the torque added to body1 and body2 is larger than the > value set via dParamMaxForce. This is particularly strange. > Were these much larger? Maybe these extra torques are due to contact forces on the two bodies? Again, I don't know yet if this is necesary, we will have to see what behaviors people come up with. It might just make it even a bit more realistic. About the universaljoint, here is my reasons that I abandon the > universaljoint that time: > 1. It is not as good as hingejoint in the joint limit aspect. > 2. The two axises of universaljoint has orders. Which axis goes > first depends on the parameter sequence passed to dJoitnAttach. It is not as > clearly as two hingejoint. > OK sounds fair, I was just wondering about it :-) Anyway, I'll try to test universal joint since universal joint is used in > soccerbot now. > OK. you're doing great work! hopefully I can actually do some work soon again too, instead of just talk ;-) Sander |
|
From: Feng X. <hen...@ma...> - 2008-05-18 14:00:57
|
Hey,
About the motors, I think setting them as correct as described in the document is not necessary. Besides, the motors in the leg has stronger force compared to that in the arm. But it is hard to represent it via setting dParamMaxForce because ODE is taking this parameter as a reference, not strictly accuracy according to my experiments. I logged the feedback of body1 and body2, and the torque added to body1 and body2 is larger than the value set via dParamMaxForce. This is particularly strange.
About the universaljoint, here is my reasons that I abandon the universaljoint that time:
1. It is not as good as hingejoint in the joint limit aspect.
2. The two axises of universaljoint has orders. Which axis goes first depends on the parameter sequence passed to dJoitnAttach. It is not as clearly as two hingejoint.
Anyway, I'll try to test universal joint since universal joint is used in soccerbot now.
Best Regards,
Feng Xue
2008-05-18
Sent By： Sander van Dijk
Sent At： 2008-05-18 21:16:43
Sent To： Feng Xue
CC To： Joschka Boedecker; Yuan Xu; simspark-devel
Topic： Re: Re: [simspark-devel] Simspark Todo
Hey,
2008/5/18 Feng Xue <hen...@ma...>:
I'm not familiar with the motor parameters described in
NaoHardWareSpec.zip. So please check rsg/agent/nao/hingejoint.rsg,
is the new joint speed limit reasonable?
These look good (beware: I have not been able to actually test them yet, I just looked at the numbers :) ), though to be complete, why not set the correct max velocity on each joint as described in the documentation instead of using the maximum for each? Besides that, maybe setting these maximum velocities are enough for now, but we can also set the setMaxMotorForce. Since ODE tries to achieve the motor velocities as fast as possible, without reasonable torque values there can still be unnatural accelerations. As far as I can tell from ODE documentation you can use the stall/nominal torque in Nm directly from the documentation as arguments for setMaxMotorForce now our model's size is in actual meters.
And, I think there is another thing todo now. The collision
between the two thighs, and the collision between the torso and the
lower arm. With joint angle limit, we also have some bug state.
About the collisions, I think the disableInnerCollision parameter is a hack that works now, but we shouldn't need it. The problem is that the geometries/colliders in the bodyparts overlap in valid positions, because the primitive boxes and spheres don't match the more complex visuals. Also the double hip construction means two bodies at the same position.. why is chosen for this instead of a universal joint in the hip?
It is possible in ODE to have mesh geometries. In theory it should be possible to use the mesh data in the .obj files to create this. Though for now it might be possible to try to use multiple smaller colliders and TransformColliders to more closely match the body parts.
Sander
|
|
From: Sander v. D. <sgv...@gm...> - 2008-05-18 13:16:10
|
Hey,
2008/5/18 Feng Xue <hen...@ma...>:
> I'm not familiar with the motor parameters described in
> NaoHardWareSpec.zip. So please check rsg/agent/nao/hingejoint.rsg,
> is the new joint speed limit reasonable?
>
These look good (beware: I have not been able to actually test them yet, I
just looked at the numbers :) ), though to be complete, why not set the
correct max velocity on each joint as described in the documentation instead
of using the maximum for each? Besides that, maybe setting these maximum
velocities are enough for now, but we can also set the setMaxMotorForce.
Since ODE tries to achieve the motor velocities as fast as possible, without
reasonable torque values there can still be unnatural accelerations. As far
as I can tell from ODE documentation you can use the stall/nominal torque in
Nm directly from the documentation as arguments for setMaxMotorForce now our
model's size is in actual meters.
And, I think there is another thing todo now. The collision
> between the two thighs, and the collision between the torso and the
> lower arm. With joint angle limit, we also have some bug state.
>
About the collisions, I think the disableInnerCollision parameter is a hack
that works now, but we shouldn't need it. The problem is that the
geometries/colliders in the bodyparts overlap in valid positions, because
the primitive boxes and spheres don't match the more complex visuals. Also
the double hip construction means two bodies at the same position.. why is
chosen for this instead of a universal joint in the hip?
It is possible in ODE to have mesh geometries. In theory it should be
possible to use the mesh data in the .obj files to create this. Though for
now it might be possible to try to use multiple smaller colliders and
TransformColliders to more closely match the body parts.
Sander
|
45 messages has been excluded from this view by a project administrator.
