You said that you haven't this problem before.
Do you mean that you were using the same control program, upgrading to
Gazebo make the problem appears and downgrading it don't make it disappear?
If the camera is really falling from the object it should be a problem with
the physics, something have being changed, for instance the friction
parameter mu1 now is taken into account for the friction. You can try
changing that.
Also the rendering method of the system can be configured in the .gazeborc
file now.
I can not remember of any other big change that may be affecting you.
Do you have the original file of the gazelle? It may be a good addition to
the sets.
On Mon, Mar 3, 2008 at 7:57 PM, Domenico Leonello <[EMAIL PROTECTED]>
wrote:
> Thank you for the advice.
>
> I attached the .world file (I tried some other configuration and the
> result is the same, so...) and here the C code
>
>
> /******************************************************************************************/
> Initialization ....
>
> /******************************************************************************************/
>
> /// Connect to the libgazebo server
> try
> {
> client->ConnectWait(ServerID, ClientID);
> //client->Connect(ServerID);
> }
> catch (gazebo::GazeboError e)
> {
> std::cout << "Gazebo error: Unable to connect\n" << e << "\n";
> return;
> }
> /// Open the Left Camera interface
> try
> {
> cam_leftIface->Open(client, "left_iface-name");
> }
> catch (gazebo::GazeboError e)
> {
> std::cout << "Gazebo error: Unable to connect to the left camera
> interface\n"
> << e << "\n";
> return;
> }
>
> /// Open the Right Camera interface
> try
> {
> cam_rightIface->Open(client, "right_iface-name");
> }
> catch (gazebo::GazeboError e)
> {
> std::cout << "Gazebo error: Unable to connect to the right camera
> interface\n"
> << e << "\n";
> return;
> }
>
> /// Open the Simulation Interface
> try
> {
> simIface->Open(client, "default");
> }
> catch (gazebo::GazeboError e)
> {
> std::cout << "Gazebo error: Unable to connect to the sim
> interface\n" << e << "\n";
> return;
> }
>
> /** Pausing simulation... (maybe not needed!!) **/
> simIface->Lock(1);
> simIface->data->pause = 1;
>
> /// Setting command name for imposing 3D position
> uint8_t model_req[32] = "set_pose3d";
> memcpy(simIface->data->model_req, model_req, 32);
>
> /// Setting model name for imposing new Pose in Simulation Interface
> uint8_t model_name[512] = "helicopter";
> memcpy(simIface->data->model_name, model_name, 512);
>
> /** Writing the current odometric position... **/
> simIface->data->model_pose.pos.x = cmd_pos_change[0];
> simIface->data->model_pose.pos.y = cmd_pos_change[1];
> simIface->data->model_pose.pos.z = cmd_pos_change[2];
>
> simIface->data->model_pose.roll = cmd_rot_change[0];
> simIface->data->model_pose.pitch = cmd_rot_change[1];
> simIface->data->model_pose.yaw = cmd_rot_change[2];
>
> /** Unlock simulation interface ... **/
> simIface->Unlock();
>
>
>
>
> /******************************************************************************************/
> The cycle (called by matlab-simulink recursively)
>
> /******************************************************************************************/
>
> /** Lock simulation interface ... **/
> simIface->Lock(1);
>
> uint8_t model_name[512] = "helicopter";
> memcpy(simIface->data->model_name, model_name, 512);
>
> /** Writing the current odometric position... **/
> simIface->data->model_pose.pos.x = cmd_pos_change[0];
> simIface->data->model_pose.pos.y = cmd_pos_change[1];
> simIface->data->model_pose.pos.z = cmd_pos_change[2];
>
> simIface->data->model_pose.roll = cmd_rot_change[0];
> simIface->data->model_pose.pitch = cmd_rot_change[1];
> simIface->data->model_pose.yaw = cmd_rot_change[2];
>
> /** Unlock simulation interface ... **/
> simIface->Unlock();
>
>
> /******************************************************************************************/
>
> /******************************************************************************************/
>
>
> Here two screenshot of the left camera view: the first (left_frame_0001)
> during a normal call, the last (left_frame_0059) when already the
> simulation starts crashing after 50-60 calls.
>
> Any idea? Is it possible that any system update (using aptitude) created
> any problem, for example to the ode or ogre libraries?
> Note that before I haven't encountered this problem! But now I have it
> also downgrading the SVN version of Gazebo!
>
> I'm using Kubuntu (both Gusty and Feisty).
>
> Tell me if I post any other usefull information!
>
> Thank you
>
>
> Jordi ha scritto:
> >
> > Send me as much info as you can.
> > If you can not send me the code or the world file for whatever reason,
> > send me a screenshot.
> > Also send this mail to the ML so Nate and others can give some advise.
> > Lately I have not much time for Gazebo but I'll try to help
> >
> >
> > On Fri, Feb 29, 2008 at 10:21 PM, Domenico Leonello
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Hi,
> >
> > maybe I found a bug in libgazebo. The situation is the following.
> >
> > Using MATLAB S-function I impose recursively position and attitude
> > to an
> > object (with an helicopter mesh) with 2 cameras mounted on (like a
> > stereo pair).
> >
> > I observed a strange behaviour during the calls to libgazebo. If I
> > impose an attitude (also constant) different from (0, 0, 0), after a
> > variable number of calls (it depends on the entity of the imposed
> > angles) the cameras seem to fall from the helicopter and give
> deformed
> > images (and then normally the simulation crashes). Sometimes it
> > happens
> > also that the trimesh attached to the helicopter body stretches
> > and deforms.
> >
> > If the imposed attitude is (0, 0, 0), I can move the cameras around
> > with no problem.
> >
> > I didn't find any explanation to this behaviour.
> > A memory error is unlikely (otherwise I can't explain why with (0,
> > 0, 0)
> > values all goes ok!).
> >
> > Maybe it is a sort of conversion error between euler and
> quaternions.
> > This can explain why the mesh stretches, if the quaternion is not
> > normalized to1! But why it happens only after 50-60 calls of
> libgazebo
> > and not immediatly? And wht it doesn't happen when euler angles
> > are (0,
> > 0, 0)?
> >
> > If you need, I can send you pictured of the deformed helicopter and
> > camera sight. And I can also send any information about the C code
> > that
> > calls libgazebo.
> >
> > Thank you
> >
> > Domenico
> >
> >
> >
> >
> > --
> > Jordi Polo Carres
> > NLP laboratory - NAIST
> > http://www.bahasara.org
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Playerstage-gazebo mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
>
>
--
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Playerstage-gazebo mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
