The boards have been pretty quiet so I thought I would share what I am working on now.
This is for robots using an on-board computer I have started making a plugin that is designed to use the xv-11 sensor, wheel radius and encoder counts per revolution of the wheels to make a map of the environment. It also uses the compass part of the 4-in-1 sensor sold on this site.
The map is currently stored in a SQLLite3 database. It is housed in the plugin directory. I don't know if this will be the final design or not but it is what I have working right now. There is a map table that is created by the user with the plugin. It contains the X coord, Y coord, tile and Counter fields. This will be used to store the map as it is being updated. The tile will be marked when the LIDAR recognizes something in that location of a certain intensity.
Quote:
The tile size is determined by the wheel diameter. If you have small wheels, you have small tiles. If you have large wheels, you have large tiles. The current environment that I am testing in has tiles that are about 4.19 inches by 4.19 inches. This is because I have wheels that are 4 inches in diameter and if you take the wheel diameter * pi / 3, you come up with 4.188790266.... I round this to 2 decimal places. If you had wheels that were 2 inches in diameter, you would have tiles that are 2.09 inches. If you had wheels that were 12 inches in diameter, the tiles would be 12.57 inches. The logic is that the wheels would be much smaller for robots in smaller environments and much larger for robots in larger environments. Larger wheels means faster moving robots and thus the updating of the environment would have to account for faster moving robots. The number of tiles in the map is determined by the configuration screen by setting the size you want your map to be. In the test, the map is 50 feet x 50 feet. Using a robot with 12 inch diameter wheels indoors in a 50x50 foot house could become problematic. These are all subject to change depending on testing.
Well the information quoted above has changed. I am in the US and as such am more comfortable using inches and feet, so I am making 1 inch tiles for everything. The wheel diameter is still important but not as important in laying out the grid. I am converting the mm readings from the LIDAR to inches and marking the squares. We will see how this works out and go from there. This, along with everything else is subject to change as I go through it all.
The map on the screen is loaded from the SQLLite3 database initially. As things are seen by the LIDAR, the map table is updated and the display is updated by marking the corresponding tile on the map.
Eventually my goal is to take this logic and use it in SLAM. I plan on starting with some simple SLAM using the RANSAC algorithm which is best used in indoor environments. This is because it estimates and creates landmarks based on straight lines. From there I will use the Extended Kalman Filter for data association. This allows the robot to recognize landmarks and then adjust its current position on the map based on these landmarks.
One of the reasons that I want to store this information in a SQLLite3 database is that this would allow me to have multiple maps housed in different tables. The configuration screen could be modified to allow the user to specify which environment the robot is in (office 1, Office 2, home, Mom's house for example). These maps would be stored in different tables and the user would just switch to the map that pertains to the current environment. Another thing that these multiple maps could be used for is to handle different floors of an office building, one for each floor.
The test map is about 13 meg in size. This isn't too large but is only based on a 50x50 foot house on a robot with 4 inch diameter wheels. If you were in a warehouse or large office building with a robot with small wheels, the size of the database could get really large I would imagine. The goal is to get this to work in a smaller environment, and then see what needs to be done to handle larger environments.
Eventually, I plan on incorporating a path finding algorithm. This shouldn't be too hard to do because it is done in video games like crazy. There is plenty of sample code to build from.
Anyway, that is what I am working on currently. I suspect it will take some time before I have something to share. This is a pretty ambitious project and I will post updates as I accomplish different things with it.
I am not sure if I will sell this plugin or make it freely available. This is something that I will decide after I know how it works in multiple environments. If it turns out to be simply amazing, I might sell it. If it just works, I will give it away for free and continue working on a final solution.
I don't mind paying for value, and I think Roborealm is a lot of value for the price. I would be happy if it was limited to two machines, one development and one production like the old license (or like Microsoft used to do with Office, one desktop and one laptop, with only one activity in use at a time. It wasn't enforceable, but was in the EULA.)
I have been spoiled by Android where the apps are based on the user id, not the device. I have the same apps on two tablets, two phones, and an emulator under Windows all with one purchase, but if someone else wants to use them, they need my Google credentials, which is NOT happening...
Alan
The encoders I use are about 20K per rev.
Ros slam is good but the goal here is to add slam to ARC. DJ allows plugins and I am working on one that uses specific sensors and allows customization with out programming. The plugin allows me to leverage what is already in ARC. Basically the gist is that the user would build scripts to move their bot a specific distance. They can specify which script to use to move the robot in any direction. This allows the plugin to work with a wide range of robots.
I'll write more when I'm not on a phone
My bad, the encoders/motor combo do 63500 pulses per rev. No, it is external to the motor driven off of the back shaft of the motor. RoboRealm has the ability to generate an image from an array of data, and then analyse that image using a lot of different filters. You can also update the image. It also has path finding built in. There isn't a SLAM module in there yet.
I am just not comfortable in their environment at all compared to C# and ARC. I understand what is going on in ARC. I get lost in RoboRealm but it is probably because I haven't spent the time trying to understand it like I have ARC.
There are some cool features in RoboRealm that could be leveraged, but their pricing model isn't free like ARC's.
I also just cant bring myself to write in vbscript. It is way too unstructured for me and I always have to go back and correct code to remove ; or other silly things. Old habits die hard. There are other scripting languages available in RoboRealm but I am far more comfortable with C#.
My problem right now is that the encoder has too many pulses for the kangaroo. I have to figure out how to make a flip flop circuit now. https://synthiam.com/Community/Questions/6225&page=3
Parts have been ordered to make this flip flop circuit. I will post the results when I have them.
I do have to say that I am a programmer. I try to look at the overall picture. If I jumped to a different platform every time that the one that I am on didn't have something that I wanted, I would have to question my first statement.
I could live off of what others have done, but then I wouldn't be a programmer.
I could leverage what is done and build onto it, then I would be a smart programmer.
I could build something open ended enough to allow others to use it in different configurations, which would make me a good programmer.
I could bang my head up against something that will never work, which would make me a dumb programmer.
I had started to go down the ROS path. It is a good path if that is what the rest of your stuff is built on. I decided that I didn't want everything built on ROS, and DJ opened up ARC to allow plugins to be developed to do anything you want it to do. ROS is the wild west of robot programming. There is a lot of half working code that only works in a specific configuration without ever considering that someone else might use it. It is good in that there are a lot of things being developed there, but nothing that I have found is a working solution outside of the specific config that it was designed for.
EZ-Builder's road map became whatever we want to make it as programmers when Plugins were added. This allows you to use the controls that someone else wrote, along with the controls that are in ARC by default. It allows you to write your own controls for things that are not there, and share them if you choose to with others. The real difference that I now see with ARC and ROS is ARC is more controlled and runs on Windows. ROS is more wild west and runs mainly on Linux. Either is a good option in my opinion, but I like to leverage controls that work for a wider audience than those that work only for a specific configuration.
@David... I would be willing to pay for your plugin... I haven't bought the lidar yet but I definitely plan to... Autonomous navigation is a big deal in my opinion and so I would be happy to pay to get it....
Cheers and thanks for your efforts in this,,, Richard
Thanks Richard. I think I can make this open ended enough to allow multiple configs. I don't want to say, you have to use this sensor with these motors spaced this distance apart and only use on this type of surface.
The key to SLAM is accurate movement. I cant control if someone has accurate movement in their robot nor do I want to. If I take the movement equation and place it on the user of the plugin, and assume that their movement is accurate, I then can focus on the mapping, landmark and path finding portions of the plugin. I would love to take this to the point that it could work with multiple sensor configurations at some point, but I have to start somewhere.
There is no reason that SLAM cant work with ping sensors, PIR sensors, IR sensors or really anything that can detect distances from an object. The difficult thing about using these types of sensors is that there is a very limited field of view, so figuring out if what the robot is seeing is a straight line or a point takes much more movement by the robot. The LIDAR can make this determination due to the data that is returned in a very quick time. This drastically reduces the movements required by the robot. By taking these measurements from mm to inches, I am able to reduce the map by 25.4 times in size and reduce the level of error from the LIDAR by taking all objects that are in the inch size to the pixel on the map.
By using a scale of 1 inch = 1 pixel as a standard, the calculations for how far to move become pretty easy to do. The concern that I have with this is the requirement to use Inches which is not the universal standard. I could go with 1 pixel = 1 cm but the issue there is that the map becomes too large to display reasonably inside of ARC, or on any application for that matter. This may need to be revisited after everything is working but I don't have a better unit of measure that isn't too large or too small at this time.
The compass would only be used to account for obvious wheel slippage. It has been pointed out that the compass may have interference and thus not produce accurate results. I do feel that this is still a valuable tool to have, but may also incorporate a camera to account for movement. For example, I can take a picture prior to a turn, and then one after a turn and compare them to each other to see how much variance that there is in the pictures. If a threshold has been met, then I could assume that there was no wheel slippage. This would have to be combined with the compass I would think as it would be possible to miscalculate this with walls. 2 walls in a house could look very similar in a corner situation if the environments decorations were not done by my lovely wife
Every wall has things on it so in this environment, it would be reasonable to use the camera. In an office environment this might not be the case.
The EZ-Robot 4-in-1 sensor also provides a gyroscope. This could be used I suppose but I would have to understand its readings more to make a call on if this should be used or not.
Another option is to use another sensor like a ping sensor or car bumper sensor and the known points on the map to know what you expect to see change with these sensors as the robot turns. The same could be done with the LIDAR I suppose, but I think I want to complete a move, then get the LIDAR data as timing between these two actions (and the resulting odometer data or grid estimation) is important in order to get an accurate results. The defusing of the data from mm to inches might make this not as big of an issue though. Also, this will become a non issue once the map is build and the landmarks are populated as the position and direction of the robot will be adjusted based on the previously seen landmarks...
Okay, done thinking about this right now. Work calls.
Hi David, I think a small list of reccomended components would be the best way to go. If anyone is serious about adding this function to a robot they would have to use the components that best suit the project. I know you want to have the option of using many different sensors, but trying to work them all in the project means a lot of work. List the optimal components and one or two options if they exist and that's it. The costs for this system will not be cheap and everyone is aware of it. I look forward to hearing more and seeing the end result of your project. I just wanted to present my opinion.!
Ron Rh
Thanks Ron. You are probably right.
What I do normally is spew ideas as they come into my head. They are quickly forgotten if I don't write them down due to other things getting in the way and confusing things. Its funny how age and my office moving from the spare bedroom to the living room cause this to happen. My son needed a place to stay while he was in College so I gave up my office. I do have a lot of distractions now that I didnt before, so when it is quiet and I can think, I like to document my thoughts. It helps me to go back and read them before I start the next day of working on things.
I also go back and update posts with newer information on these thoughts quite a lot. What is funny is that I could do this in notepad or winword or a pen and paper, but find myself much more likely to go read these if they are posted here. I guess this is my second home or something now.
I also think that seeing what other people are doing or think about my ideas is important to me and I get more motivated to figure out the next issue.
Thanks for your thoughts, they are appreciated.