The lidar was facing as i discussed because I do it that way. The mount that jonnyv supplied details on is really very nice but I had already modified my Magni.
So what this amounts to is that everything will be ok if you use the mount jonnyv has designed BUT you must then properly set the RPLIDAR translation that is in my map maker and maprunner launch files as a static transform. In sort you must change the line that says ‘lidar_translation’. I will not lie to you, spacial translations make anyones head spin. They are confusing. I cannot work out what johnnyv has done but I suspect he has modified his urdf file, yet another compex thing.
I do plan on supplying a picture and details on exact location because text description of making center of lidar between wheels only is good to a certain point. Different people thing in spacial descriptions differently. If you mount or even tape your lidar to start with as I have described AND plan on putting out a picture very soon it will be ‘close enough’. So I’ll make and post a picture and some more info soon.
My goal now that this has been pushed to kinetic-devel branch (main branch) is to copy over this documentation in the README over to our learn pages and there is it far easier to show pictures so that is my goal.
I am doing 17.38 thousand things right now so please be patient, this will happen.
I’m not sure if you know this but i am the lead hardware architect on magni so I do this Nav stuff ‘for fun’ and don’t get paid for it. Just for fun.
ok alright, yes that would be great if you can put up pictures and or diagrams (worth a thousand words). I’m looking forward to see it, well done! much appreciated that you are providing more on top of Magni! (because my environment ceilings are so high and also outdoors as well, I will need this to work on Magni) now I will just have to guess the position of how Im going to tape the lidar on and also setting the RPLIDAR translation (once I get to it, I will ask you more…)
I have used the 3D mount and mounted the RPLIDAR, so what do I need to change in the map maker and map runner launch file please? in order to run your demo smoothly,
I am going to ‘give your question my best guess’.
This guess will not be accurate to cm or so but will be ‘close enough’ for experiments.
I think he put the lidar off to one side. So that off to the side error will not be covered in this ‘cheap fix’.
What I would suggest is you have my scripts say the lidar is rotate around 180 degrees which is 3.14 radians.
Current Existing Line in both my map_maker and map_runner launches:
Rotate the Z rotation (4th value) by changing the 3.14 to 0. Like this:
Again, I am ‘winging this’ and am not trying it myself, just best guess.
Well for a formating issue the last post did NOT show what I wanted it to show. It cleared key lines. Let me try again.
IT was:
arg name=“lidar_translation” default="-0.03 0 0.20 0 3.14 3.14"
So change that part of the line that cannot print right here to this:
arg name=“lidar_translation” default="-0.03 0 0.20 0 3.14 0.0"
What you are doing is changing the rotation around the ‘Z’ axis from 3.14 to 0.0.
Z points straight up. If you say rotate 0.0 instead of 3.14 you are saying the lidar is 180 degree rotated.
Please move your questions for the rplidar demo to a brand new forum entry that I have just created. See the Magni Demo Using RPLidar entry.
We do not want to interrupt too badly the fine progress reports being posted by johnnyv here as that would be ‘hijacking’ as it is said. I thank you and I bet so will jonnyv.
Extra bonus point for removing your prior post with so many pictures from this thread as a help to johnnyv. We can then discuss it over there.
I’m pretty excited by this one because this post is celebrating the coffee shop owner turning on KRYTN and use of the KRYTN while I wasn’t even aware of it. So yeah, this is a pretty big milestone I think.
We are working on a nylon bumper skirt to surround the Magni base. It will be printed in 20 ~ 30 pieces on an Ender 3 Pro or similar. The pieces will be connected with screws and nuts.
We are upgrading our Ender 3 to Mosquito Hot End, Direct Drive, and Duet 3 which will take a few weeks. Then we plan to begin printing.
The skirt will have portals all around for 10 ~ 12 sonar modules. We do not plan to use the Magni modules. You could move those to the portals (with extension wiring), or redesign the skirt model to allow for the existing Magni sonar. Or, as we plan on doing, you can add support for a lot of sonar modules and install them in all the ports.
Based on our experience in printing Nylon, we believe the result will be durable and attractive…certainly attractive enough for a bumper skirt. Other than learning paper mache or fiberglass construction, we have no other economical option.
We will make the STL files available for free. The design will be available for free on OnShape if you use that program (it runs in your browser)…that would allow you to make easy mods.
If nothing else, we can offer proof of concept (or the opposite).
FYI: I have been following your progress on LinkedIn
Wow, @FolsomMike thats really cool!
I’d love to see some videos when its ready.
Krytn’s currently using Lidar for obstacle avoidance, but 360 deg sonar could be good enough given that we already have a lidar map and are navigating off roof fiducials anyway!
Yeah, I haven’t kept this thread alive very well. There have been a few updates and hardware upgrades to Krytn since I last posted.
Here’s a quick sneak peak of an up and coming post for KRYTN robot. Its been operating for quite a while now as you can see. Thanks for all your support everyone!
Looks good! since you are using Lidar as well, are you also using Magni’s move base for path planning and obstacle avoidance ? I’m currently struggling to get it to navigate around corners also at the same time avoiding obstacles…,
Yep, it’s able to navigate around obstacles, but tuning your nav stack is the tricky thing. Note there aren’t any corners in the coffee shop, so I haven’t tested that, but in my house it was able to navigate around corners. The hardest past was the tuning the move_base config files which can get quite complex. I’m using the standard Ros move_base with the lidar, not the move_basic that comes with krytn for sonar based movement.
@johnnyv , thank you for your generous sharing, it is very helpful. I was actually wanting to search out the standard ROS move_base and you have it great, I tried to tune the move base inside the Magni_Robot package (for weeks…) and the results are very inconsistent (the map either drift offs or it just goes half way around the obstacle and it stops or in Noetic, it wouldnt even move…in simulation mode.)
I’m looking at your settings now, do these settings work for every different environments and maps? (saves me some time because I assume you may have tested it with different environments and obstacles…)
Also I see that you had set the size to 12 by 12 metres in the global costmap, did you have any issues when you have a map larger than this size?
I have tested your settings and they are great! (Alot better at where I was before) But Magni still failed on some sharp corners and bigger wall obstacles or round obstacles…, do you know how to make a custom global planner/local planner path and get Magni just to follow it?
hey @inmoov, my settings are really tuned to my specific environment. I can’t vouch for its usefulness outside of the coffee shop environment. I used 12 x 12 because it worked for me, you could go larger, but be careful as it scales quadratically, i.e. 24x24 will have 4x more memory requirements than 12x12. The 12x12 m map comfortably covers KRYTNs operating area, so I didn’t explore going bigger. However, you should be ok as long as the global update frequency is low.
In terms of making your own customer planner, I haven’t tried that. I think that you will have better luck trying to tune the existing planners in ROS rather than attempting to write your own, but “the power is yours!” as someone famous once said.
interesting, it seems it indicate that you don’t have a map frame being published, although you did receive a map.
Do you have a localisation system like acml running? You need something thats going to publish a transformation between what the lidar is seeing and the map. The key idea is that the lidar is rigidly bolted to the robot, the robot is rigidly bolted to its wheels and all of that is rigidly fixed to the “base_footprint” frame, but how can the robot know where it is in the map? Well, you need a system (like acml) to try and estimate where in the map the lidar is by aligning the current scan to best fit what the map sees. Then the system can say, see a box in the lidar scan, align that lidar scan to where that box is in the map and then transform the lidar’s location to the robots location to get a robot pose.
