PIC Program for Controlling Servo/Stepper Motors

Btw, the uC I will be using is PIC18F4520. But I am willing to change the PIC if others have advantages in respect to this project. Like PWM requirement for the Servo(s).

The nice thing about these types of RISC micro-controllers is that the instruction set is small and the learning curve is fairly short.

The Microchip application notes library should have all the information you need, including sample code listings. Since this is your project(?), it will be to your benefit to learn how to write most of the program code yourself. Knowing/understanding the code will be critical when you need to debug problems and/or re-code for new tasks.

Application_Notes

Not my project actually, but I thought it would be an opportunity/reason to work with the PIC for the first time. I was discussing this with a friend yesterday and came to understanding that it would be difficult to impliment a 3 motor "arm" - more so because the base motor has to carry the other two motors, and the elbow motor has to carry the top most motor.

I have now thought of a simplification, which I have posted below.

So let me get this straight, you want us to tell you what motors to use, what controller, how to program it, is that it? What not just buy a kit and modify it?

Go small... or go Big...

Thanks but we aren't allowed to use something so ready-made. At the same time even 31US$ is quiet an amount for me. This is a project meant for a few marks, after which it won't even remain with us.

Thanks for your suggestion though, I might try something that sophisticated some time later. But right now, no kits or ready-made robot arms like that. Thats why I decided to simplify the whole thing.*

There is a brand of smart servo motors built in Santa Clara CA USA which will monitor color sensors and do all you are asking, all without the use of a PLC. You will have to program the motors but that is relatively simple.

So, what class is this for?

In addition to specifying the motor types, some circuitry will need to be designed (motor driver/controller and feedback sensors), either by you, or someone else. Or you can purchase driving and feedback circuits. You maybe need to think this through a little more--your questions are too vague for anyone to provide a meaningful answer. Maybe look up some of the hobby robotics sites to give you some ideas for your project.

How will the position feedback be handled?

Okay, here is the simplification of the WHOLE thing. Im short on time, and like I said, we aren't going to get to keep this piece of work - so I thought "just make it working, and simple".

Here are the changes:

1. Just one motor - DC. The rotary shaft of the DC motor is connected by a rigid rod to the rotary shaft of a potentiometer. So at different points of rotation we will have different values of voltage across the potentiometer - which can be given to the PIC. So, rotation to the red box might be some value, that to the blue box another etc.

2. There is a small electro-magnet at the tip of the C shaped arm, and this is just behind the objects. This can be activated and deactivated when we want (program controlled). The objects (small, cuboid cardboard pieces have a small iron piece in them at the point close to the electro magnet. This will make sure the are attracted when the electro-magnet is activated.

3. The whole thing is kept on a stage. The camera is kept separately to read the hex codes. These hex codes are transmitted back to PIC through the RS-232 cable, MAX-232 IC.

4. When the command to pick is there, the electro-magnet is activated, then the motor moves the required length as per the hex codes arrived from the MATLAB. After that it deactivates the magnet.

5. The pick-up area is flat (i.e parallel to the ground). The slots for the object (Red, Blue, Green and Other) are sectors of circle, which slope radially inwards (like the slopping end of the roulette wheel). So when the electro-magnet is deactivated after reaching the required slot, the object falls into the slot going down the slope.

TOP VIEW:

SIDE VIEW:

OBJECT INTERIOR:

So I guess the only part of the program required now is to get the analog voltage value of the pot, and then the activation and deactivation of the E-magnet.

Btw, did anyone read the program outline in the first post? I made an error in that 8. should be Ascend_action (M2), not M1. Anyways, now the program is going to be much easier and less cost too (as there is just one motor).

The job of rotating to the particular slot remains the same.

The job of gripping/dropping as been given to the electro-magnet.

The job of descending has been given to Earth's gravitational pull.

I don't much like the use of a pot for position. You then have an AtoD conversion to contend with and dithering and such.

A rotary resolver has a digital output which makes the slew drive limiting easier to program without the need for conversion.

If a rotary resolver is not an option you could use a gang of proximity switches to provide position feedback via cams on the slew axle to provide a coarsely encoded digital signal.

eg

0000 is nowhere really keep slewing

1111 is the pickup bin

0001 is the red bin

0010 is the blue bin

0100 is the green bin

1000 is the other bin

Would that or something similar work for you? You could even do it with 3 bits (3 switches).

Nice job on simplifying the design by the way.

"If a rotary resolver is not an option you could use a gang of proximity switches to provide position feedback via cams on the slew axle to provide a coarsely encoded digital signal."

I didn't understand the arragement you are talking about exactly. I just have one cam (my webcam) and I am using it to get the pixel values (RGB) from the MATLAB code to the PIC.

I thought the pot would be a good idea because there is an A-to-D port in the PIC, which I thought I could make use of. And also, the degree of accuracy required is not much (as long as it comes into the required sector). The cost is highly reduced too.

"Cam" as in "camshaft"......

A cam is not a camera.

If you have an A-to-D port in the PIC then the pot is the easiest way to go.

You will have to reverse the slew to go back to the pickup bin if you use a pot. You will have to take into account the rotating limit of your pot too. Unless you use a multi turn pot which just changes the control complexity a bit.....

I am not sure whether this post will help anymore after the changes you have made, but here goes anyway.

1) a DC motor with feedback pot is basically a servo motor. as someone else said. Pots were used years ago, but as far as I am aware have fallen out of favour because of their relatively short life and possible other problems.

Also you need to have the pot in some sort of feedback electronics, we used to use a multi vibrator which produced a square wave variable between 1 and 3 Millisec. The controller produced the same style of signal, but 180° out of phase, they were added together and the difference was amplified and applied as a plus or minus voltage to the motor, driving it one way or the other until the two were cancelling each other out and the motor then stopped.

There are chips around to make this simple, you could simulate it in a PIC program as well.....

I believe servo will cost more and is less easy to implement.

2) My personal method would be stepper motors, almost every scrap printer or scanner has one or more, plus chips to control them. Even buying the chips will not break the bank.....

I personally would not program the PIC to control the motors (though many have done it and put their designs on the web), I would use the PIC to control the stepper motor driver chips. There are many to choose from, mostly cheap.

Learn how to differentiate between Bipolar and Unipolar stepper motors. Both of these types of steppers can be driven in a bipolar manner, even the Unipolar ones. But bipolar can only be driven with a bipolar circuit, but are considered to be slightly more powerful for the same physical size.

To move a stepper motor in either direction, basically you set one signal to the chip, active high or low to control the direction forward or backward, then pulse another signal to move/step the motor to where it needs to go. Its all very fast and easy to control speed and position....also very accurate. (depending upon the motor type (step size, down to 0.45°, 1.8° is common plus gearing if even more accuracy/power is needed.)

(There are some so called hybrid steppers which I have never used, and I believe they are a little more difficult to interface and find, plus more expensive)

Best of luck.

Hi Andy,

If you recall, we exchanged a messge on this a while ago on this - at that point I was planning to use a stepper motor. The unipolar stepper motor available here is small (12 V) one. I am not sure if it will be able to handle the load of the arm, which I am making out of wood.

Buying a servo is costlier than just attaching a pot. to a DC motor, which is why I thought that to be a good option. The reason I am doing a lot of cost cutting is because this whole thing is not going to stay with us following a demonstration of it - for a few minutes (max). And secondly, if it doesn't work out, I would have simply wasted a lot of money.

Pots wear, I don't like them personally. If you must do this, make sure that the pot is of excellent quality.......difficult to be sure nowadays.

I personally prefer optical encoders for servos, less problems.

Using gears to slow down the output increases the power available and makes any motor easier to control. There are plenty of cheap DC motors with an attached gearbox, some can break your arm!! Look on secondhand/ebay web sites.

Here is a prime example on ebay USA:-

http://www.ebay.com/itm/12V-DC-100RPM-High-Torque-Gear-Box-Electric-Motor-/320828856624?pt=LH_DefaultDomain_0&hash=item4ab2e3d930

POINTS 4, 5, 6 in PSUEDOCODE

Given that this is the software section we might be going off-topic here speaking so much of the hardware.

Coming back to the pseudocode*, I was thinking of points 4,5,6. The camera is always on in that position, but the PIC only has to read the data its sending when its about to pick up the object.

Till the time it drops the object and comes back to the original position, it should ignore any colored objects placed there (not keep them on pending!).

So what I mean is lets say I place a purple object, the camera gives the image to the MATLAB code, which generates RGB = 40 00 7F. Logic of the PIC says this goes into the "other slot".

Now between the time the object is placed in slot and brought back to original position, any number of objects may be brought to the camera. The background itself will be interpretted as an objects. These, should be ignored. So what would be the PIC instructions for this? My webcam is connected to the comp. and the DB-9 ic connected to the MAX-232 which is connected to the PIC at RC6/TX/CK and RC7/RX/DT.

-------------------------

*Given that I am not using 3 motors now the code changes too:

1. Initialize registers

2. Motor in original position (M1 - facing pick up box, electro-magnet EM - deactivated).

3. Activate_electro-magnet (EM)

4. Enable hex read of RGB codes through RS-232

5. Receive hex data

6. Disable hex read of RGB codes through RS-232

7. IF (red condition)

move M1 to face red box

ELSE

{

IF (blue condition)

move M1 to face blue box

ELSE

{

IF (green condition)

move M1 to face green box

ELSE

move M1 to face "other" box

}

}

}

8. IF (voltage at potentiometer pin as per color condition)

Deactivate electro-magnet (EM)

9. GOTO 2.

OBJECT DETECTION

Okay, I can't edit the previous comment now.

But I thought I could I can use an IR sensor placed in the pick up area to detect if an object has been placed.

Only if an object has been placed the EM should activate. That would seem more sensible. Otherwise it would move back to the original position, and in the absence of an object - it will detect "other", activate the EM and go to the "other" slot - doing this repeatedly !

No programming experts here?

Very well put indeed.

I would just like to add for the OP that making a working program is not really the hardest part of the job, its the "Human Proofing" that MUST be added before usage that really bumps up the size of the program and it's complexity......

In my limited experience, the HP side adds often between 30 and 66% more code, depending upon just how much human safety is actually needed.......even stopping illegal data entry requires a few extra lines of code......by not hitting/injuring someone will require even more.

@Wal

If I needed help with the mechanical design, I would ask separately. I would definitely not post here (Software & Programming section).

--------

I have an electro-magnet which will pick up the objects, and servo motor to move to the required slot, and after the magent is deactivated (at that point), the object just drops into the slot because its a slope.

I can't draw a flow chart, but the basic working is as follows>>>>

***

1. When the object is placed in position, an IR sensor connected to pin 34 (RB1) which is normally high becomes low.

2. IF (IR == 0 && servo == original position)

{

electromagnet connected to pin 16 (RC1/CCP2) becomes high.

}

3. WHILE (electro-magnet==1)

{

WHILE (IR==0 && servo==original position)

{

4. Webcam connected to USB of computer has to take a snap.

5. MATLAB code should generate RGB values of any pixel in the image (say center). Since I am using single colored objects (fully red,or blue or anything) the value of all pixels will be close.

6. PIC should enable communication through Rx and Tx through pins 26, 27.

7. Matlab code should send RGB values through DB-9 to MAX-232 which should go to PIC.

8. After PIC receives this data, it should disable communication through Rx and Tx.

9. I separate R, G, B values by ANDing the 3 byte code with FF0000 (then do right shifting 2 bytes), 00FF00 (then do right shifting 1 byte) and 0000FF respectively. Or I could do this in MATLAB itself, but I am afraid the data will get jumbled while transmittion.

If I can use MATLAB itself to separate R, G and B bytes and send them to separate registers in the PIC it would be most convenient.

} // End of IR while loop, electro-magnet is still high

10. Color Detection Logic (3 nested IF-ELSE loops, each loop checking with given ranges for R, G, B values for acceptance as Red, Blue, Green or "Other").

11A. WHILE (servo position != original position || electro-magnet==1)

{

ignore all interrupts of IR sensor (don't put in stack, just ignore!) //This means when an object is being placed, any objects being placed or removed from the pick up area will be ignored.

} // end of detection condition while loop

11B. As this color is detected (in 10.) the servo connected to RC2/CCP1 should do an action of position control of servo - i.e. bringing the object attached to the electro-magnet infront of the correct slot.

} // end of electromagnet while loop

12. IF (servo reaches required position based on color)

{

disable electromagnet. //Object falls into the slot.

}

13. Return position of servo to original position and wait for next IR interrupt.

***

Communication DISABLE and ENABLE requirements

As mentioned the PIC and MATLAB communication is disabled after point 6. It should only be enabled next when:

1. the electromagnet is switched on (after having been switched off) AND ..
2. when the the servo motor is in its original position AND ..
3. if the IR sensor has detected an object (i.e. low).

Regards,

Simply because the conversation has drifted into hardware concerns does not imply there are no programming experts here.

However, they are also experts in Process Control, Artificial Intelligence, Embedded Systems, Motion Control, etc.. So expect answers accordingly.

Just because technology is built into a toy, does not mean it's child's play.

As I see it, your project is basically:

When an object is detected, look at it, pick it up, rotate to the appropriate bin, put it down, return home.

The devil's in the details: What size motor do I need to rotate the turntable? When I turn the system on, how do I know what position the turntable is in? How do I program optimum acceleration and deceleration into my stepper motor driver? What do I do if the lights go out?

If you design top-down, you take that one sentence project description, and break it into sub-pieces and so on until you can an actionable piece, e.g.:

When an object is detected -> detection mechanisms -> universe of detectable objects -> where is it connected to my controller -> what does the software look for?

Or you could go bottom up, and build the subsystems and test/verify small pieces first:

hold a camera up to colored objects and have matlab categorize by color.

program a pic to turn on/off an led based on a switch input.

program a pic to flash at a rate selected by a serial command.

In fact, most projects are designed top-down and built bottom-up.

I didn't see you mention what kind of programming you've done prior to this project.

Basic C programming, never worked with a PIC though.

Thanks anyway guys, my work on this is done.