Let's Make Robots!

Uno - My first robot.

My first attempt at a robot, this is mostly just the Arduino robot kit that is a combination of an arduino and pololu kit components.My goal with this was to have a platform for teaching myself some electronics (for some reason I did German instead of physics at A-Level). I intend to play around with room mapping so have added an IR range finding sensor.

After assembling the arduino and motors and playing around for a bit I decided that the motors were not sufficiently similar to allow me to know my position based on how hard and long I had driven the motors. So I have also added a pair of quadrature encoders which will let me sense the position of the wheels.

All the hardware is now assembled (hence the picture) and seems to work (getting sensible looking feedback from encoders and IR sensor, motors do what I tell them). So now need to start some proper coding. First task will be some utility functions for controlling movement using feedback from the encoders.

This will require 

a) Controlling the speed of the motors (probably using PI techniques). As the motors need to go at the same speed to allow the vehicle to go in a straight line, simply driving them until each wheel has covered the same distance will not work.

b) Control the distance, not sure if I need to get too technical here. Can I stack one PI feedback loop with another (i.e. one control loop contols speed by adjusting voltage, the one controls distance by adjusting speed.

Controlling rotation will be tricky, I will be rotating the robot by driving it's pair of wheels in opposing directions and on the face of it, it should be easy to calculate the distance required to drive the wheels to turn a certain amount. However the problem I can see is where to measure the radius of the turning circle to. The wheels are quite wide and the difference between measuring from the inside and outside edge could be quite large. I guess I will start using the middle of the wheels and see where that gets me.

The interesting part will come when I actually start trying to do the room mapping. There are some interesting looking algorithms about, which use an occupancy map, however the Arduinos 1K of ram means that if I tried to do a simple array the best I could manage would be about 30x30 cells which isn't an especially high resolution. So I am thinking some form of sparse representation will be in order. Alternatively grouping of points into lines etc would allow more efficient storage.

Thanks for reading this far! If you have any comments/suggestions please let me know.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hey there Captainchickenpants.
You can nest PID loops, but it's not really necessary in this case - much easier to create a simple trapezoidal speed profile that envelops the required distance, and have your speed PID loop just track the speed profile.
The Arduino's RAM is really just meant to be working space; if you want storage then you should look into some external EEPROM ICs, or possibly some removable storage like an SD flash card module.

Good luck with the development =)

Hey telefox, The point about trapezoidal speed profile really caught my attention. As you know im part working on a micromouse and ive read that people have used that. Do u have any info on how its done in c? Also for pid loop. If I am using digital sensors, for line following like the 3pi, how is it possible for me to do a pid loop when i am only able to get fixed values 0 or 1.? 

First you need to be able to get a solid reading for your robot's forward speed, using encoders/whatever and a little math conversion. Then you need to do a little testing to find the maximum speed and acceleration your bot can perform - if your speed profile exceeds these limits then obviously your PID loop won't be able to match the desired values.

The trapezoidal ramp is made up of 3 parts: ramp-up, constant speed (often roughly the max speed), and ramp-down. The total distance travelled during the move is equal to the integral of the speed profile, which is the same as the area contained within the speed-time graph.
Usually I make the ramp-down a mirror image of the ramp-up, which makes the calculations easier. If you're performing a short move, the constant speed part of the move may shrink down to zero, and the ramp parts may be cut short. Mirroring the profile at the point where the bot has travelled half the required distance is a convenient way to make the profile work in a range of situations.

Now there are two main ways to calc the speed profile:
• take the desired distance, max accel and max speed values, and work out the whole thing in advance, then store the speed profile in a matrix or similar. From the beginning, ramp the speed profile up to the desired max (below max acceleration rate), then hold constant until the calculated travel distance is half the desired distance. Then just mirror the first half of the profile to create the second half. When it comes to executing the move, you just feed the values from the speed profile into the PID loop, along with the encoder feedback.
• an alternative is to calc the speed profile on the fly, which may be a better idea if your PID loop is not so finely tuned. When the move is executed, you start by ramping up the desired speed value and feeding those values into the PID loop. You can have the desired speed increase every couple of ms if you want good control resolution, just make sure to keep the acceleration below the max possible values. When the max desired speed is reached, start a timer or counter to measure how long the bot travels at constant speed before reaching half the desired distance.
Have the bot travel along at the max desired speed value until the measurements from your encoder tell you that you're halfway there. Stop the timer/counter, and start using it as a countdown instead, to ensure that the constant speed part before the halfway point and the constant speed part after the halfway point are of equal length. Naturally when the countdown finishes you want to switch from constant speed to ramp-down, which is exactly the same as ramp-up, but in reverse =)

You can do some other fancier stuff too, but these two methods are a good combination of simple and robust.

As to the question of using digital sensors with a PID loop - you can do it, but it's kinda pointless. You can use the digital inputs to construct an analog profile, but once again it's not really going to do anything useful.
Before you start designing a PID loop, or any other control method for that matter, you really need to have a good think about what inputs you're feeding into it, what outputs you'll be driving, and how you want the outputs to behave relative to those inputs.

That sure was informative. I get the main Idea of this. As for your response to the PID loop question. I was going along the lines of a line follower liek the 3pi in which it uses 3 sensors to follow the line. For the 3pi though the sensors are digital, it is said that their sensor values range from 0 - 2000 which really makes me wonder how that is done with digital sensors. Do you know how?

To get an analog reading from the reflectance sensors they've used an RC timing circuit, the details of which can be found here.

Thanks that sounds simple enough. I was a little concerned that nesting PID loops might produce some nasty feedback issues.

Yeah, been considering some serial flash of some kind. I will see how I go with what I have first (as well as the 1K working memory the arduino has 1K EEPROM I can use as well).