Menu
▾
▴
simspark-devel
|
From: Yuan X. <xuy...@gm...> - 2008-05-16 02:36:51
|
Hi Joschka, > from the messages on the mailing lists, I've compiled a short list of todo > items that (if possible) should be addressed for the final release of > rcssserver3d for RC08. Could you please have a look at them and try to find > people that take of them? Thanks for getting them together. I think we may finished them in rcssserver3d-0.5.9. @All: If you are interesting with some task, please go down to it and let us know ;-) > * crash of simspark when started outside of local directory I have not encounter this problem, is there anyone who want to trace the problem? > * InitEffector: needs to deal with several materials We have discussed it already. I think I can work on this. > * usemtl null in torso .obj file of Nao Sorry, I will check what wrong with the .blender file. > * no camera error (maybe just on my own machine?) The output is the same here, but it seems no problem to run the simulation. @Sander, do you know what does it mean? > * read camera positions for the monitor from configuration file I think we may add variables in the .rb files, right? > * restricted vision perceptor and changes in the vision message (see my last > mail to simspark-devel) It is very important, let's discuss in that mail. > * 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) Yes, I will deal it. > Later, we'll also need: > > * integrate Soccerbot meshes (as soon as I get them from Heni) Great! > * 3D model of the goal for the Nao simulation (I'll try to model this in > Blender, but I'm too busy right now) Do not hurry. > * adjust field size (right now, it seems we'll have 12mx8m field size), > including colliders, etc. What kind of size should we have, the size of Humanoid League ? > * 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 ;-) Nice idea. > * ball parameters (do we need to change them?) @Feng, I think you have already to adjust them, would try to make it better? > Can you think of anything else that needs to be addressed? There are some ODE parameters about robot are need to adjust, such as joint motor max force, etc. @Feng, would you take this? I hope we can have the preview of rcssserver3d-0.5.9 in the next weekend. What do you think about it? -- 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: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 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: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: 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: 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-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-17 21:43:20
|
Hey everybody, Due to my notebook being away for repair (and the task of getting my master thesis finally finished) I am not able to do much MC work at the moment, but I'll comment anyway :) > * no camera error (maybe just on my own machine?) > > The output is the same here, but it seems no problem to run the simulation. > @Sander, do you know what does it mean? Sorry, this was meant as debug output. I will remove it. If anybody hasn't seen it yet, it is now possible to put a camera in an agent's head and rotate through the cameras in the monitor using the , and . keys. It's fun to watch the game from an agent's perspective :-) I was planning to use this to make a CustomRender which displays first person view as a picture-in-picture, like the webots simulator does, but haven't come to it yet. And perhaps there are more urgent things to focus on. > > * read camera positions for the monitor from configuration file > > I think we may add variables in the .rb files, right? Ran in that too, should indeed be in [nao]soccersim.rb. > * adjust field size (right now, it seems we'll have 12mx8m field size), > > including colliders, etc. > > What kind of size should we have, the size of Humanoid League ? 12x8 looks good, nice and big to promote team play > Can you think of anything else that needs to be addressed? > > There are some ODE parameters about robot are need to adjust, such as > joint motor max force, etc. > @Feng, would you take this? This is high priority I think. The agent's power should be toned down greatly. Teams are already working on gaits/kicks/strategy based on the current settings, getting to the absurd ways of getting up/walking/kicking as seen with soccerbot. Strategies like scoring straight from a goal kick, on which most teams seemed to focus in recent competitions, though legal according to current rules and the official FIFA rules, should be beatable. For this the agent's power must be decreased significantly and this should be done soon, so teams can adapt to it. So if anybody has the official Nao motor specs available.. Cheers, Sander |
×
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