Thanks, Yes, I anticipated the controller solution...but that seemed awkward
to me. In effect I would be adding a series of (albeit simple)
constraint/controller equations to the system of equations rather than
supplying data directly to ODE's integrator. I haven't written controllers
for Gazebo before, but I would assume that they have to exploit existing
joint types rather than (for example) a generic 6DOF joint and controller
that simply assigns 6 position/velocity values.

If I have to use existing joint types, I suppose I will have to build (an
invisible) a serial manipulator to move the object around the world (a
3-prismatic, 3-revolute joint for example) and accompanying controllers. 

Comments?


Nate Koenig wrote:
> 
> If you want to pass 3D poses to Gazebo, and have Gazebo move the model
> to each of these points then you will get snapping - unless the
> relative differences between the 3D poses is small. You could write a
> controller that interpolates between 3D poses, kind of like
> keyframing. This will produce a smooth motion.
> 
> -nate
> 
> On Tue, Jan 13, 2009 at 3:30 PM, smonckton
> <[email protected]> wrote:
>>
>> Well, after being away from this for awhile I'm back at this project
>> trying
>> to get an aircraft (driven by an external simulator) to render in gazebo
>> (svn version). Of course everything has changed so I'm trying to figure
>> out
>> the best way of doing this. I can see how a custom (invisible) controller
>> could be used to move an aircraft model around the 'world' ...is there a
>> better way? If I use simIface, I can only set modelPose and thus get the
>> snapping effect I encountered in my earlier experience in 0.7.0.
>>
>> Suggestions?
>>
>>
>> smonckton wrote:
>>>
>>> Hmmm, I tried this before (and I tried it again just to be sure). Using
>>> only SetPose (or the other Sets) snaps the model from point to point.
>>> Ok,
>>> I can understand that, I'm only updating the model at 3 Hz and no
>>> velocities are set. So if I then add the velocities put out by the
>>> external simulator the results are smoother...but still odd. I think I
>>> may
>>> have some coordinate transform issues here! In any case tracking the
>>> results is hard since the UAV moves out of the rendered area very
>>> quickly.
>>> Is there a way to enlarge the rendered volume w.r.t. the ObserverCam?
>>>
>>> Simon
>>>
>>> Nathan Michael wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> Try:
>>>>
>>>> this->body->SetPose(GzPose pose)
>>>>
>>>> or
>>>>
>>>> this->body->SetPosition(GzVector pos)
>>>> this->body->SetRotation(GzQuatern rot)
>>>>
>>>> See:
>>>>
>>>> http://playerstage.sourceforge.net/doc/Gazebo-manual-0.7.0-html/
>>>> classBody.html#a6d32b9b81d5e09ebaec8bc852184837
>>>>
>>>> Nate
>>>>
>>>> On Aug 27, 2007, at 3:24 PM, smonckton wrote:
>>>>
>>>>>
>>>>> Hello All,
>>>>>
>>>>> I'm a newbie to libgazebo and trying to figure out the best way of
>>>>> driving
>>>>> an aircraft model in gazebo through an external aviation simulator.
>>>>> I'm not
>>>>> using player, since we use (IMHO) a more flexible device server
>>>>> (MIRO, for
>>>>> those that are interested), so I'm talking directly to libgazebo.
>>>>> I've tried
>>>>> a few experiments setting positions, which works...sort of. If I set
>>>>> position directly, I get odd results that makes me think I'm
>>>>> fighting ODE.
>>>>> Basically, I just want to feed the aircraft state directly to a plugin
>>>>> model. I noticed that in the AvatarHeli model, the following
>>>>> approach is
>>>>> used in AvatarHeli::PositionGetCmd():
>>>>> void AvatarHeli::PositionGetCmd()
>>>>> {
>>>>>   gz_position_lock(this->position, 1);
>>>>>
>>>>>   this->cmdLinVel = GzVectorSet(this->position->data->cmd_vel_pos[0],
>>>>>                              this->position->data->cmd_vel_pos[1],
>>>>>                              this->position->data->cmd_vel_pos[2]);
>>>>>
>>>>>   this->cmdAngVel = GzVectorSet(this->position->data->cmd_vel_rot[0],
>>>>>                                 this->position->data->cmd_vel_rot[1],
>>>>>                                 this->position->data->cmd_vel_rot[2]);
>>>>>
>>>>>   gz_position_unlock(this->position);
>>>>>
>>>>>   return;
>>>>> }
>>>>>
>>>>> and then in Update():
>>>>>       this->PositionGetCmd();
>>>>>   // Rotate velocities into global cs
>>>>>     pose = this->GetPose();
>>>>>     lv = GzCoordPositionAdd(this->cmdLinVel, GzVectorSet(0, 0, 0),
>>>>> pose.rot);
>>>>>     av = GzCoordPositionAdd(this->cmdAngVel, GzVectorSet(0, 0, 0),
>>>>> pose.rot);
>>>>>
>>>>>     // Dumb controller
>>>>>     this->body->SetLinearVel(lv);
>>>>>     this->body->SetAngularVel(av);
>>>>>
>>>>>
>>>>> ...which is a 'back door' method of setting the state. Over the
>>>>> long haul
>>>>> the position within the external simulator and gazebo would diverge
>>>>> using
>>>>> this method. A similar technique is used in Blimp. So the question
>>>>> is: " Is
>>>>> there a way of directly setting the state of an actor in libgazebo
>>>>> other
>>>>> than through derivative terms?"
>>>>>
>>>>> Simon
>>>>> --
>>>>> View this message in context: http://www.nabble.com/External-
>>>>> simulators-and-Gazebo-tf4337753.html#a12355928
>>>>> Sent from the playerstage-gazebo mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> ---
>>>>> This SF.net email is sponsored by: Splunk Inc.
>>>>> Still grepping through log files to find problems?  Stop.
>>>>> Now Search log events and configuration files using AJAX and a
>>>>> browser.
>>>>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>>>> _______________________________________________
>>>>> Playerstage-gazebo mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Splunk Inc.
>>>> Still grepping through log files to find problems?  Stop.
>>>> Now Search log events and configuration files using AJAX and a browser.
>>>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>>> _______________________________________________
>>>> Playerstage-gazebo mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/External-simulators-and-Gazebo-tp12355928p21446949.html
>> Sent from the playerstage-gazebo mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Playerstage-gazebo mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
>>
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Playerstage-gazebo mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
> 
> 

-- 
View this message in context: 
http://www.nabble.com/External-simulators-and-Gazebo-tp12355928p21671265.html
Sent from the playerstage-gazebo mailing list archive at Nabble.com.


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Playerstage-gazebo mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo

Reply via email to