Gmapping for Magni

[mjstn2011]

What I said about move_base was at a time we were trying to figure out why you could not find move_base. It was only to see if move_base could be found, not to explain how to start the navigation stack and actually use move base. Move base is of no value without the rest of the code that determines where the robot is at a given time. We then found that you were on the laptop. The book and chapters I mention would explain the navigation stack and as such would be valuable.

My advice is that reading a couple chapters of that book is in fact EXACTLY the best thing for you at this time and would be a valuable thing and would greatly assist you in your efforts to learn more about ROS based robots.

I told you I have not done point cloud system and have told you I am getting ready to publish an example that will directly walk people through use of a Lidar on the Magni.

The example I publish for Lidar may offer tips that may assist your efforts in a conceptual way.

[inmoov]

@mjstn2011,

ok I’m now just trying to visualize Magni from the below instructions

I have done the installation on my VM, but I dont see magni_viz for launch , very not sure why…

So I went ahead and roslaunch magni_viz view_robot.launch in the actual Magni Robot

and I could see this , my question is there a way that I can view Magni the 3D model (the dae file linked in the URDF) in RVIZ ? (not in gazebo simulation though) , I want in real life in RVIZ, a live Magni Robot,

Please reply as soon as you can ,

Thanks

Roger

[mjstn2011]

On my own robots I use a different (less complex) robot_description scheme. On Magni when I run I usually just look at the joints and axis like you have shown. When I drive around or navigate those ‘joints’ move around and turn like the robot turns.

I asked somebody about it not showing the ‘rendered Magni’ and they have said that as long as your linux box has our magni_robot repository and you have done the catkin_make on that linux workstation and it looks like you did that, the robot rendering should show up.

This may be a bug and I will report it.

Complicated things like this are supposed to all be ok on our own virtual image. If it is not working
on our VirtualBox image then it is a bug. I will have to ask somebody else to verify and look into this.

Mark

[inmoov]

@mjstn2011 @davecrawley

Well, I’m using your VirtualBox image, downloaded from your website , so I reckon its a bug too, do you have a incident number for this?

And my eyes dont feel comfortable looking at the joints because they stretches here and there in RVIZ…, its just confusing for me, I’m more used to seeing an actual robot model in RVIZ that moves rather than all the joints and axis …

I notice in the magni.urdf.xacro file has the Robot base_link of the DAE files (3D model files) which are located below which I found:

And I tried to open these DAE files in Blender, freecad and sketchup but I’m unable to open them,

or do you have a more simplier model such as STL?

Please advise as soon as you can,
Thanks
Roger

[mjstn2011]

You have found all the correct components. I feel you may have found a real bug and I thank you.

I have seen the model within rviz so something ‘broke’ (that may be the virtual image, the launch files or something else within magni_robot. I think you are starting the rviz correctly but again, I just live with the x,y,z axis and that works for me. Yes it looks really silly, agreed but it tells ‘all’.

The most active work in rviz by our team is all in Gazebo so likely that something changed and was not ported back into the real Magni usage. Again, it is likely a bug.

I once worked with 3 STL files to do 3d printed Magni robots about 6 months back. There was a main body, a large drive wheel and a caster. They are no ‘assembled’ together nor do they offer any coloring data. If you want to mess with those I can offer them to you if you are good with combining STL format images into a single STL.

Let me know and I’ll try to locate them.

[UPDATE] Actually I see the .dae files for the very same 3 parts already in magni_description/meshes so you are better off with the .dae files anyway.
I converted the .dae files to form my stl files for 3d printing.

I know of no fully ‘assembled’ CAD file for this purpose.

[inmoov]

@mjstn2011,

ok, Im surprised that there are no assembled CAD file for this…,

I’m very struggling to get the .dae files to display in RVIZ (during real time) , so meanwhile since it is another bug as you said can you please please send me all the STL files of Magni Robot or if you have the .dae files (that can actually open in CAD softwares such as Blender, that would be good too)? so that I can try it that way,

I tried to convert the DAE files to STL and failed also, …
but I can open other DAE files like below but just those once in github, I cannot open and view at all…

Please reply back as soon as you can

Thanks
Roger

[mjstn2011]

I don’t think I mentioned that in RViz you have to do an ‘Add’ in the display panel and add a ‘RobotModel’. This may solve your problem if you have not done that.

[inmoov]

@mjstn2011

Yes I have tried that, it’s in my screenshots of RVIZ , I added in Robot Model as you said, it shows all ticks on the left bar under Robot Model but no Magni Robot model show up , … confused

Please help to rectify as I had tried so many times

Or let’s me know which launch app I need to launch in Magni Robot?

I even tried roslaunch magni_description description.launch directly to Magni (which links the magni.urdf.xacro). And then RVIZ on the VM, added Robot Model… nothing shows up …

Thanks
Roger

[mjstn2011]

I have posted this to our resident ‘expert’ and he and I are discussing it.
It will not become an ‘issue’ as you requested until they determine it is really broken.
I suggest you work on other things because this will get fixed but this is the weekend.

[inmoov]

Ok @mjstn2011 , I will wait and if you have the STLs meanwhile for me to download, that would be good

[inmoov]

@mjstn2011 @rohbotics

why is the map in pieces below? … and the odom flew all the way to the right…

Please help !!!

thanks
Roger

[mjstn2011]

The map can be in pieces for a few reasons. There are exceptions to what I am going to say but I am saying this so you keep your tests as repeatable as possible until you get comfortable that everythng is working great.

It helps to start with a fresh map and always start your robot from a full power-up with it’s wheels in a known location and a clean map.txt file. I put two pieces of tape on floor for where my right and left wheel will be to start. Then start up all the gmapping sort of things from a known place.

For gmapping with an unknown robot configuration you are best off to always clear the map.txt file typically located in .ros/slam for each new gmapping run. If you do not clear that map file you must remember that gmapping is ADDITIVE so it will start to generate and modify what you have and all sorts of crazy patterns can result. It is likely what you show above may be from not clearing the map.txt file prior to more than one gmapping run.

Remember that if you pick up the robot and move it or rotate it the wheel odometry does not know you have perhaps moved a LOT so that shows up in your map as you continue to map.

Another reason is that your sensor did not have a chance to get gmapping to calculate and update parts of that map that may not have been seen. This would leave ‘blank spots’ not mapped yet. If you drive by some big object the robot may not see behind the object so that area is unmapped till it is seen when the robot knows where it is located and where the camera is pointing.

One thing that I do for ‘sanity’ that works well with a Lidar or our ceiling fiducials is start with the robot in an enclosed area of known dimensions and maybe put a box in one spot so you know what the simple map should turn out to be. Then do the gmapping

[inmoov]

ok @mjstn2011, it makes sense but I only found this map.txt file and it is not located at .ros/slam

but is this the map.txt you are talking about? it seems a bunch of instructions in there for mapping… and so what should I clear here, or is it a special command to clear map ? for gmapping

Also , I had another issue is that , is that I started from a start here point in the map below, the wall is labelled , I use commander app to control Magni, when I move Magni from the start point to the wall, it seems correct but when the second time, I go back to the start point , it ends up at a different spot on the map (labelled “ended up here” but in reality , I had just moved Magni back to the start point…,) and now if I move Magni to the wall again, it goes to a complete different direction (not corresponding to the wall labelled on the map below…) …please advise…

Global options > fixed frame > map

Also , I find that in RVIZ, I have no map received under LocalCostmap ( please advise…)

but map is received in Global costmap:

Also, in the URDF file, I have kinect and camera_link , linked to the base_link , kinect joint is type “fixed” (because I believe that it never moves , situated on top of Magni) and camera_link joint , I configured to type “continuous” …, can you please let me know if this configuration is right or not?

I look forward to your reply,

Thank you,
Roger