Capelare's profile - activity

Hi! I'll be blunt...

I used LDD and lxf2urdf to build a robot and I want to change the parent of some of the links because I need certain parts to be independent of the rest of the robot (e.g. the back wheel) if I intend to make some of the joints continuous.

I tried using rviz to select the links and see their relative position, but I found that those numbers aren't precise enough. So how do I know the relative position between two links with the maximum possible precision?

I didn't find any questions regarding this, excuse me if I just couldn't find them! :(

Update:

For example, let's take a random joint from my .urdf file:

<joint name="ref_70_joint" type="fixed">
  <parent link="ref_58_link_hub"/>
  <child link="ref_60_link"/>
  <origin xyz="-0.0135999953902 6.27180865763e-08 0.00020025516928" rpy="3.14159265343 1.5396542947e-05 -1.04458704296e-05" />
  <axis xyz="0 0 0" />
</joint>

Now let's see what rosrun tf tf_echo /ref_58_link_hub /ref_60_link returns:

At time 1332949971.511
- Translation: [0.014, 0.000, -0.000]
- Rotation: in Quaternion [0.000, -0.000, 1.000, -0.000]
            in RPY [-3.142, -0.000, -0.000]

As you can see I only get three decimal digits, just like rviz.

Today I've downloaded the Lego Digital Designer from the Lego website and then generated some designs. When I exported the .lxf and .ldr files and proceeded to convert them to .urdf using the lxf2urdf converter I got this message:

Unable to handle 'robot.lxf': 89

I also tried re-generating the urdf files with the lxf/ldf files that come with the nxt_robots_* packages and everything went fine, but if I open and save/export them with LDD (without making any changes) then I also have a similar error message.

Note that in the example above #89 is the link that the converter can't handle, but I noticed that that link doesn't seem to exist, and I checked that the latest (... 86, 87, 88) links generated match with the latest lines at the .ldr file and also with the latest bricks I added with the designer.

So I think it's just that the folks at Lego have updated the .lxf format and the lxf2urdf parser just can't understand the ending of the file... This is really a problem because the urdf generated doesn't have any joints, just links :(

Until someone updates it, anyone knows which version of the LDD works (if any)?

I'd try to upload tomorrow the .lxf file that I've designed in case someone wants to try it (and maybe give me the proper .urdf file :P)

Thanks!
Miguel.

Update: Here are the files! Could anyone try them?
robot.lxf
robot.ldr
robot.urdf

Update: I think now I know what's wrong. When I use the wide rims to build a robot they are not exported to the .ldr file. Actually, if I build a robot with these wide rims LDD will generate an empty (WTF!?) .ldr file... Because of this, lxf2urdf doesn't recognize the bricks and fails to convert the model. I don't know why this happens, but I'm out of ideas. I tried with the latest LDD version (4.2.something), with 4.0 and with 3.1.

Hi there,

I have just installed Ubuntu and ROS and gazebo-1.0.0-RC2 but when I run the gzserver command this is what I get:

Gazebo multi-robot simulator, version 1.0.0-RC2
Copyright (C) 2011 Nate Koenig, John Hsu, Andrew Howard, and contributors.
Released under the Apache 2 License.
http://gazebosim.org

Warning: no world filename specified, using default world
Msg Waiting for master
Msg Connected to gazebo master @ http://localhost:11345
Segmentation fault

Is there any log or anything else where I can try and figure out what's causing the Segmentation fault?

Previous to this I was having problems, gzserver repeated this message several times:

Xlib: extension “GLX” missing on display “:0.0″. Insufficient GL support

I solved it by installing OpenGL... and that's when the Segfault appeared. So now I don't know if this introduced the current error or it has nothing to do.

Thanks for your time! Miguel.

-------------------------------------------------------------------------------

Update: My Ubuntu installation died and I had to reinstall everything... Now I'm not getting any Xlib errors or segfaults, but instead this is what's happening:

Gazebo multi-robot simulator, version 1.0.0-RC2
Copyright (C) 2011 Nate Koenig, John Hsu, Andrew Howard, and contributors.
Released under the Apache 2 License.
http://gazebosim.org

Warning: no world filename specified, using default world
Msg Waiting for master
Msg Connected to gazebo master @ http://localhost:11345
Exception [RenderEngine.cc:473] unable to find rendering system

Error [Rendering.cc:37] Failed to load the Rendering engine subsystem
unable to find rendering system
Exception [RenderEngine.cc:473] unable to find rendering system

Exception [RenderEngine.cc:473] unable to find rendering system

Exception [Sensors.cc:38] Unable to load the rendering engine

terminate called after throwing an instance of 'gazebo::common::Exception'
Aborted

I'm going to investigate, but I wanted to post it here first.

Thanks again! Miguel.

-------------------------------------------------------------------------------

Update 2:

I tried everything that I could think of, and I'm still getting those errors about the rendering system... Any ideas? :(

Thanks, Miguel.

Hi, I'll try and be blunt:

My goal is to code what is left to build a simulator using ROS and Gazebo for the Lego NXT. Over the last weeks months I've been trying to learn as much as I could of how does ROS work, focusing on the tutorials that are available on the wiki.

Right now I'm trying to understand how gazebo plugins work, but I'm trying to achieve that by following the PR2 tutorials (and the plugins that are behind them), and they (plugins, not tutorials) seem to be too complex for me to understand them and write my own.

Back on September Tully Foote gave me a link with an example plugin (create_plugin) that I'm looking into right now, but I don't really know what does it actually do, so it's difficult for me to understand it.

Of course, I've tried (without luck) to find answers to my questions on this pages first, so any help will be welcome. Meanwhile I'll keep trying by myself :)

Thanks, Miguel.

Hi, I'm trying to visualize the URDF models of the nxt_robots (robot.urdf files on each package) with the display.launch program from the urdf_tutorials stack, but I don't seem to be able to do so, it keeps crashing all the time:

started core service [/rosout]
process[joint_state_publisher-2]: started with pid [2754]
process[robot_state_publisher-3]: started with pid [2759]
process[rviz-4]: started with pid [2762]
Traceback (most recent call last):
  File "/home/capelare/ros/urdf_tools/joint_state_publisher/joint_state_publisher", line 208, in <module>
    jsp = JointStatePublisher()
  File "/home/capelare/ros/urdf_tools/joint_state_publisher/joint_state_publisher", line 25, in __init__
    robot = URDF().parse(description)
  File "/home/capelare/ros/urdf_tools/urdf_python/src/urdf_python/urdf.py", line 506, in parse
    base = xml.dom.minidom.parseString(xml_string)
  File "/usr/lib/python2.7/xml/dom/minidom.py", line 1924, in parseString
    return expatbuilder.parseString(string)
  File "/usr/lib/python2.7/xml/dom/expatbuilder.py", line 940, in parseString
    return builder.parseString(string)
  File "/usr/lib/python2.7/xml/dom/expatbuilder.py", line 223, in parseString
    parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 2, column 12
[joint_state_publisher-2] process has died [pid 2754, exit code 1].
log files: /home/capelare/.ros/log/b0629bba-0bad-11e1-93ed-001d4ffc607c/joint_state_publisher-2*.log

That's what I get on the Terminal. Then rviz opens and displays all the meshes on the origin. Any ideas? Too many joints, maybe? The robot.urdf file passes the check_urdf tool, so I guess the syntax is OK. BTW, display.launch works fine with the urdf files I made following the urdf_tutorials, if you're wondering.

I'm still getting used to ros, urdf, rviz... and I tried to make this work by myself, so maybe this is the stupidest problem ever, but I'm totally lost.

Also, as requested by David Lu, here you have the first few lines of the URDF file:

<!--this file was autogenerated from sensor_car.lxf -->
<robot name=sensor_car>

    <link name="base_link"/>
    <joint name="base_joint" type="fixed">
      <parent link="base_link"/>
      <child link="ref_0_link"/>
      <origin xyz="0.024 0 0.016" rpy="0 0 -1.57079632679" />
      <axis xyz="0 0 1" />
    </joint>
...

Thanks for your time, Miguel :)

Hi, I'm writing plugins for NXT and Gazebo and I was having trouble with the one I'm currently working...

After some time I realized that UpdateChild is never executed, or so I think. I have some ROS_INFO("WTF"); calls that I use to follow the execution, and I can see the ones in LoadChild, InitChild and the callback node, but the one within UpdateChild is never shown.

This has not happened to me before, and I don't know what have I done differently...

BTW I'm using electric.

Here's the code for plugin that's not working, though you can also find it at my repository here, along with the rest of my packages.

This plugin takes the data from a camera and calculates the luminance of the image.

The launch file I'm executing is this one.

Thanks in advance,
Miguel.

Edit: I'm removing the code here for the sake of readability.

Also, I tried reducing the plugin to its minimal expression (removing all functionality) and still seems to ignore UpdateChild function. WTF is happening? Any hints? :S

Hi everyone:

You may be familiar with my robot and its problems by now... here comes a new one, yay!

I think that I'm going to let the problem self explain with a video. As you can see, on ~0:30 I turn the robot 90º and then, when I tell the robot to go straight forward again, the caster wheel oscillates instead of just following the main body of the robot, making the robot move more like a snake than a car.

Hints?

Thanks a lot,
Miguel.

Update: I've noticed that if I add a lot of weight to the caster, the oscillation tends to stabilize, but I don't think that's a solution, because I'm increasing the weight of the caster wheel by 300 times its original weight (3g to 0.9kg). Any other ideas?

Hi everyone, I was going to test the robot I just wrote in Gazebo when I realized that the robot spins around the joint of the caster instead of the other way around...

I mean, the continuous joint that simulates the axle of the caster spins, yes, but it's the wheel that stays in the same place (like if it were glued to the ground) while the robot does a backflip around it when I turn on the front wheels' motors, for example.

I have no clue about the reason of this. I think that everything is defined the way it has to be, but clearly I'm missing something.

The .xacro files can be found here. The caster can be found inside nxt_caster.xacro, but some things like <gazebo> parameters are inside nxt_base.xacro.

Anyway, if you want, you can test the problem yourselves if you have the nxt stack, clone the repository (or just download the code), compile it and then:

roslaunch nxt_gazebo nxt_ultrasonic_empty_world.launch

and (try to) drive it around with:

roslaunch nxt_teleop teleop_keyboard.launch

If you need me to explain anything else on my code just ask!

Thanks in advance,
Miguel.

Edit: I uploaded a video showing the problem, as you can see, the caster wheel sticks to the ground whenever it touches it.

Edit: I tried changing the mu1 and mu2 parameters, the transmission, the continuous joint parameters... Nothing seems to change the problem of the wheel sticking to the ground as if it was glued down.

Edit: I used my caster macro in another .urdf file (video, as you can see it spins correctly when I move around the robot, despite the bouncing.) with more satisfactory results, so it seems that the problem is not in the caster definition itself, but anywhere else. That leaves me even more confused and still without any clue about how to fix it.

Hi, I'm modeling a robot and using the meshes that are available at nxt_description. But I noticed that 3707.dae mesh is not centered (?) and I was wondering how could I modify it (and maybe push it to the repository).

Also, how should I make new meshes that use the same scale than those who are already made? And how do I get the textures from the .dat files of LDraw?

I'm sorry if this is already answered or documented somewhere, but the only thing I could find was this post and it didn't help me much :(

Thanks in advance,
Miguel.


Update:

I managed to get the COLLADA models, but some of them are inside out and don't show correctly on Gazebo or rviz. For example, look at this tire:

As you can see, the inside of the tire is shown instead of the outside. Any ideas on how to solve this?

Thanks! :)

Hi, I've been trying to find a robot with at least one ultrasonic range sensor that is already simulated in Gazebo so I can see how it is programmed, but I can't find any, and I see that there isn't a question about this (or I can't find it, of course...)

Thanks in advance! Miguel.

Hi everyone:

I just managed to spawn my NXT robot in a Gazebo empty world, but when I hit play it starts to oscillate around its center of mass (I guess). I recorded a video to show this behavior.

I think this has something to do with collision and/or mass values of the urdf file, but I don't really know, and I thought it would be great to have an answer to this question around here.

Also, if I change the collision parameters of the wheels to match exactly the geometry of the visual ones my robot takes the role of a rocket and disappears in the sky... I think the robot starts to collide with itself (?)

Any ideas?

Thank you very much! :)

Update: here are the robot that oscillates and the robot that flies.

Update 2: the new robot that flies.

Update 3: I was going to post a new question, but I think it's still the same... After I corrected the scale of the tire meshes (actually changed them for cylinder shapes for simplicity) my robot spawns correctly and stays on the ground as someone would expect. But when I tried to move the robot I realized that its center of gravity is misplaced (I think that this was the reason of the oscillation in the first place) because the robot gets knocked over to the left very easily. I don't know why does this happen nor how to correct it, in part because I couldn't find any info on how this CoG is calculated.

Here's the current xacro file of the model. As you can see the robot is built around a link in the very center of the model (ref_0_link).

I took a couple of screenshots showing the physics of my model. Why is that link (?) over there (the one with all those green strings coming out of it) instead of in the center of the model?

Thanks! :)

Update 4: Could anyone tell me how this center of gravity is calculated? Or if it's defined somewhere, or what... Maybe then I could fix it, I'm going nuts trying to find a solution. Thanks again!

Update 5: New photo: the blue arrow points to the root link (base_link, a small translucent box) and the grey arrow shows what I suppose is the COM of the robot, given the behavior of the simulation...