I have (that is relative because I have not yet ordered my first parts from Robotshop) a PING ultrasonic sensor. I'll be having an arduino mini - though I'll no doubt buy something bigger after - and I wonder if I can efficiently make my upcoming rover (differentially driven, nothing special really) map it's surrounding area using a grid. Is it possible or will I run short on memory with the arduino mini? And more importantly, I need help with the code (I have 0 experience with code, though I have enough theory I guess...). Any suggestions are appreciated. Oh, and of course I will be using encoders, or maybe rough timing might do the job if the encoders are too big. Now that's another question :P; can I rely on time to effeiciently calculate the distance travelled?
A lot of guys have done this, it is possible and any memory you would need could be added with an EEPROM chip. That being said, this is a bit ambitious for a start. If you have 0 code experience, then doing what you describe above will be impossible. Instead, I would focus on learning how to code. Theory is great and you are going to need a lot of it but in the end, it has to be written in a very specific way, in a specific order, with proper spelling and punctuation in code. There is no work-around here, you just gotta put in the time.
Get your parts, then get a LED blinking. Then make it blink faster, then slower. Then learn how to fade it. Then learn how to fade it using an ADC and a pot. Then hook up a motor or two. Make it go forward and backward. Now, vary it’s speed. Then vary the speed with a pot. Hook up your servo --figure out what position numbers make it point in which direction. Write these numbers down. Hook up your ping and get numbers from it --use the serial.print to send numbers to the terminal.
Now put all these things together to make a robot that will drive around by itself. Next, you will need to figure out some kinda encoders on your wheels to know how far you are going and in which direction. Get a EEPROM chip, learn i2c communication, and figure out how to write data to this chip.
Now all you gotta do is figure out how the actual mapping will work.
Yeah, I went through the arduino examples a long time ago. I mean I’ve been learning a lot by myself now and I only lack the parts. I already have my quadruped planned and stuff (I know the kinematics are going to be a nightmare though). I maybe under-estimated myself there. I know how to blink a LED all right. I meant I knew the code but never applied it yet on a robot.
Mapping is a pretty tough subject. I’ve messed around with it on hobby robots some, but haven’t had any good results. If you have lots of money it’s another story. Anyways, if you just use time to calculate distance…or even encoder counts, your resulting map is going to be useless because of inaccuracies. One way of getting around this is called scan matching, where you calculate distance traveled by determining the offset between two scans, but this is pretty advanced stuff and usually requires a laser scanner to produce usable results. But anyways, here is a node to some work I did about mapping with a IR sensor, I ended up giving up on it though.
I’m working on the same type of project, and yes I would keep the encoders. As Chris suggests, learning to code the different features of your system one at a time will help you keep your sanity. I just finished writing the code for my GPS unit, now I’m trying to learn the i2c protocol. I’m planning to use a grid system for navigation as well. Good luck!
