Arduino Uno Question

Added info: servos 1 and 3 are continuous rotation. Second is normal. I suspect that nos. one and three will be stopped by a limit switch of some kind.

Tell us more about where you are. Do you have the Arduino IDE on your computer? Have you looked through the example sketches? Do you need to know more about the servos in particular? Do you have any code written yet? We need details.

This guy does a pretty good job explaining about servos in this video. Note that servo.write does not wait for the servo to complete its movement before other programming commands may be issued.

The ticked is as mentioned, you have to start an operation and then go on to the next one, etc.  Then you just loop around and keep tabs on how your processes are proceeding, and do any necessary processing as they proceed and complete.

Most little real-time applications will simply have a processing loop that is continually running, and you just bop out to start and terminate processes as you go.  You'll also likely want to set up a timer block so you can have timers of various resolutions for process control.  Stuff like serial data input is typically handled using an interrupt routine unless your process loop is very small and fast.

GRJ: The Arduino has a setup routine that happens before anything else in your program and a loop that runs repeatedly just as you have described for a real-time system. Interrupts are being used in the belly of the beast but are rarely used at the surface.

Unfortunately, it doesn't appear that the Servo library has a mechanism to sync-up when the servo movement has completed. Your program can issue a command to move to a particular point (say 90 degrees) but there is nothing to say when that movement has actually been accomplished.

As shown in the video, you can issue back to back Servo.write commands in opposite directions and before the first movement is complete, the second command overrides the first.

The only way to ensure that a movement has completed is to estimate a time interval for that to happen. The published interface does not allow for interrupts or other synchronization methods.

...
myServo.write(90);
delay(100);
...

I think that what the OP wants to do is start a number of things going on simultaneously. In that sense, the way the Servo library works suits that purpose. You can start the continuous servos running and they will continue until you get a signal from the proximity switches; and then turn them off.

Are there any servos made that include feedback? Like an analog output or something? I have never used one and know very little about what is available in that department, but they do look interesting.

RTR12: I'm not sure how these things work either. They have 3 leads; power, ground, and signal. I think it uses PWM through the signal wire. But they don't have to be hooked up to the PWM pins of the Arduino (just the regular Digital I/O pins). There is a circuit board inside the servo and a potentiometer to feed position information to the unit. I'm still learning about these, too.

You can read about how the Arduino uses them in the Servo library.

Consolidated Leo posted:

GRJ: The Arduino has a setup routine that happens before anything else in your program and a loop that runs repeatedly just as you have described for a real-time system. Interrupts are being used in the belly of the beast but are rarely used at the surface.
...

Sure, any uP application needs an initialization procedure that initializes the hardware, etc.

I'm used to writing all the code, including the interrupt routines for various functions.  I'm getting spoiled by the new PIC MPLAB X with all the canned functions for generating code for timers, serial data, etc.

I did some work with the Arduino, and it's very easy to crank out an application with it.  I generally am using the PIC as I'm building stuff that's much smaller than any Arduino processor board, and it includes all the other interface parts as well.

The PWM servos use feedback internally for positioning, typically a pot, but you don't have visibility to the position.  It's assumed that you know the pulse width you're feeding it, so you should know the position.

That makes sense, GRJ. Again, all of that is buried in the library code so we don't have to deal with that. But it helps explain how these things work. If I would have had access to servos when I was about 10 years old, I'd have been all over this. 

I understand wanting to go with the smaller footprint for engines and rolling stock. You've got to adjust with working in close quarters.

The Arduino started out as a way to get young people interested in the engineering and science fields of endeavor. They will need to have an understanding of the machines that we develop.

In model railroading, the Arduino is in that sweet spot between technical and simple with a lot of motivation to drive things along. I'm sure that there are a lot of modelers here that would be using them for all sorts of things if they only knew how. After all, these are electric trains.

True, the Arduino has tons of plug-in modules so that the hardware side is more picking the correct interface module than actually building hardware.  That certainly does lower the bar for entry to using a processor.

Consolidated Leo posted:

RTR12: I'm not sure how these things work either. They have 3 leads; power, ground, and signal. I think it uses PWM through the signal wire. But they don't have to be hooked up to the PWM pins of the Arduino (just the regular Digital I/O pins). There is a circuit board inside the servo and a potentiometer to feed position information to the unit. I'm still learning about these, too.

You can read about how the Arduino uses them in the Servo library.

Thanks, I will check out the library. I think after that I might order a couple to play with and experiment with the software for feedback as GRJ indicates below.

gunrunnerjohn posted:

The PWM servos use feedback internally for positioning, typically a pot, but you don't have visibility to the position.  It's assumed that you know the pulse width you're feeding it, so you should know the position.

I gotta look at the library above, but from your post there must be a way to keep track of position in software then. Maybe the library will explain further about software workings. Feedback seems nice, but maybe not needed like I thought it would be? Gotta read up on servos too!

I wish I knew what they are talking about.

If the sample they use for a typical Arduino sample library is to be believed, they simply feed it a value from 0 to 179 and wait a spell for the servo to slew to the value.  Most model servos have 180 degrees of travel, so it's obviously assumed that the number you feed it is where the servo ends up.

It is my understanding that there are all kinds of servos available with lots of different features including feedback from the internal potentiometer. This would be one way to determine what the actual position of the servo is. Then the program could react acordingly.

The price range goes from about $3 for a hobby servo from Asia, to astronomical. The cost for the feedback seems excessive for anything that I would want to try for a switch machine on a model railroad.

In GRJ's sample code, they are using an external potentiometer connected to one of the analog input pins to determine the position for the servo. As I said before, there is no synchronization method for the program to use to determine when the servo has completed its movement. A suitable time interval is the only way to be sure when it's done.

It's funny that the hobby servos are all advertised as being really fast. I guess in the RC (radio control) world of racing cars, airplanes, and quad-copters, that's an important issue. Speeds are touted as being about 0.12 seconds to move 60 degrees.

In the railroad world, switch machines are meant to run slowly to achieve a more realistic look and operation. But I think that by giving the servo small increments in succession, a slower movement can be accomplished. That's a good thing.

If you buy a servo that has feedback, I suspect you'll be paying more than you might imagine.  I worked with a lot of servo driven aircraft instruments in the 1970's and 1980's, and providing external angle feedback was a big deal.

As you correctly observe, you can simply change the PWM code slowly to achieve the result you desire, that doesn't preclude using the inexpensive model servos.

I've never tried it, but you can program the 8-pin Attiny chips with a modified Arduino core, if you want a really small size.

But the Arduino Pro Mini series is only 18 x 33 mm and gives you all the features of the 328.

It all looks easy enough, I think. Guess I should go look for some servos to order for some fiddling.

From what I gather, small hobby servos are all made in China or Taiwan. There are name brands like HiTec, Futaba, Tower Pro, and countless others. Some are Chinese brand names. Others are US brand names. There are clones that look very much like the real thing and come with a corresponding lower price; probably went in the reject bin for the name brand models.

It's difficult to know which ones are reliable enough to spend money on when your project is counting on a narrow price range. If I want to beat the price for a switch machine, it has to be around $10 or less.

The failure rate seems to be higher than usual on units of this size. People who fly model aircraft hate it when they fail in their $3000 model planes and come to a crashing realization that they should have bought the more expensive servo. It's good that model railroads don't leave the ground; at least not on purpose.

I'm tending toward the Tower Pro MG996R for about $8. Some ebay claims don't add up to the real thing. The pictures show things like "TowardPro" on the label. I may have to lower my expectations and just order some.

I have no experience in this area so recommendations are welcome? Please include make and model. Thanks!

Gee! I wonder what happened to our OP (original poster). Jay, are you out there? Hello...

I'm alive and well despite the sub zero weather. Been hibernating inside trying to come up with some code that actually works for parts of my project. Close on some things but no cigar. Been a long time (50+ years) since I did any computer programming. Then it was 80 column punch cards and hope the computer opp didn't drop your deck of cards.

trainman129 posted:

Then it was 80 column punch cards and hope the computer opp didn't drop your deck of cards.

Those were the days. "You skipped a comma" was a major undertaking.

If there's anything you need help with let me know. Programming was my career. You'll get it. Just take one thing at a time.

One thing that I found out about the Arduino 328P models, including the UNO, is that there's not a lot of dynamic memory space. What that means is that too many diagnostic Serial.println statements can corrupt the stack. So I advise that you use them sparingly. Don't leave them in your code once you've ironed out a particular section. They'll take up too much space. It's sometimes easier to leave them where they are but comment them out with the leading double slashes. Also, keep the messages you print short. Once the stack becomes corrupted, the processor will get lost and your program will crash. The only symptom is that everything stops.

You can prevent string literals in print statements from being copied into RAM by using the F() macro.

Professor Chaos posted:

You can prevent string literals in print statements from being copied into RAM by using the F() macro.

That's correct. It puts the strings into program memory instead. I don't use the P macro directly but I do use that technique to store and retrieve immutable strings as keywords. Still a valid way to make use of program memory for unchanging data.

Trying to run a cont. rot. servo in one direction multiple rotations then stop it. Later , run it in the opposite direction the same number of revs.  Servo wants to stop and chance direction by itself. Must have a bug in the code somewhere.

While looking for servos I found this. Might be of interest, tons of servo info.  Servo Database

trainman129 posted:

Added info: servos 1 and 3 are continuous rotation. Second is normal. I suspect that nos. one and three will be stopped by a limit switch of some kind.

What exact  part # or model # are you using as a continuous rotation "servo".  There are servo mechanisms that have been modified to allow continuous rotation - but the modification renders the standard servo library functions useless.  Most if not all hobby servo mechanisms have a limited range of motion - maybe 3/4 of a rotation at most.  There are mechanical stops to prevent it from continuous rotation.  Some servos even use the limited range of a 3/4-turn sensor potentiometer as the limiting mechanism.  You can remove these mechanical stops and/or sensor potentiometer yourself, or just buy modified servos. Now you basically have just a DC gearmotor - or 2-wires directly connected to a DC motor plus gearbox.

Positive DC voltage spins it one way, negative DC voltage spins it the other way.  You will need some kind of sensor (lever switch, optical or magnetic sensor, etc.) to detect when the output shaft makes a revolution.  Then count 3 and stop the voltage.  Apply the reverse voltage and again count 3 revolutions and stop the voltage. 

Control the speed of rotation using standard pulse-width-modulation PWM functions.  Applying 5V direct to the motor of a modified servo will make 1 revolution in a fraction of a second; hence use PWM to slow it down.  Servo library functions also use PWM to communicate with servo mechanism but it's a different protocol and hence not relevant to control continuous rotation DC gearmotors. 

I'm sure there are exceptions to my blanket statements.

The Servo library does work with continuous rotating servos as well as the standard types. 

Standard servos allow the shaft to be positioned at various angles, usually between 0 and 180 degrees. Continuous rotation servos allow the rotation of the shaft to be set to various speeds.

The Servo.write function then takes a parameter to set the speed of rotation.

Writes a value to the servo, controlling the shaft accordingly. On a standard servo, this will set the angle of the shaft (in degrees), moving the shaft to that orientation. On a continuous rotation servo, this will set the speed of the servo (with 0 being full-speed in one direction, 180 being full speed in the other, and a value near 90 being no movement).

trainman129 posted:

Trying to run a cont. rot. servo in one direction multiple rotations then stop it. Later , run it in the opposite direction the same number of revs.  Servo wants to stop and chance direction by itself. Must have a bug in the code somewhere.

If you would like me to look over your program, you could attach it here as a file (add attachments; below). Sometimes it just takes another set of eyeballs to spot a problem.

That's a good summary of how the standard servo.write functions can control the speed and direction of a 3-wire "continuous rotation servo".   Just want to be sure you have such a widget rather than a standard servo mechanism that has been modified for continuous rotation. 

Sorry for any confusion.  I didn't realize how far things have progressed.  Just a few years ago, hobbyists were lucky to find standard servos that were mechanically modified for continuous rotation.  For minimal additional cost now there are versions that are additionally electrically modified to re-interpret the servo.write position commands as speed/direction.  Very useful! 

Some of the continuous rotation servos have a hole where a screw driver can turn the internal potentiometer for calibration purposes. Thus a servo.write(90) can be adjusted to stop rotation in either direction and set the mid-point.

rtr12 posted:

While looking for servos I found this. Might be of interest, tons of servo info.  Servo Database

This database is interesting for a number of reasons. It shows what a wide variety of models are available for servo motors. The big stuff, the industrial size servo "systems", can run into hundreds of thousands of dollars. And they're all over the internet. My searches have led me to places where they want you to ask for a quote. Then you know that it's time to move on.

I finally got one part of my program working. Relief is at hand. At least until I start to work on the second part.

Been a strange day in upstate NY. Started out at 60 deg this morning. Now we are in a major winter snowstorm. Who says the weather isn't changing???

Seems like I started something with my question. The world of servos is wide open for all kinds of animations on a layout. Be interesting to watch and see where this thread goes.

From what I can tell, most (all?) "Continuous Rotation Servo" are modified standard servos.  The operative term being "modified" - done so by the hobbyist (plenty of online instructions) or by paying the distributor a few extra bucks to do so.  If the objective is to use the existing Arduino servo library commands then why not modify a standard servo or even a CRS to use a, say, 5-turn or 10-turn sensor potentiometer instead of the standard 1-turn?  This potentiometer would mount outside the servo box - the use of external components (limit switches) was already put on the table.

So with a, say, 5-turn potentiometer, the standard servo write commands would move the servo between 0-900 degrees (rather than 0-180 degrees) more than covering 3 revolutions.  In this way, you don't need to develop software to count 3 revolutions with an external rotation sensor/limit-switch.  It's not clear if your application is sensitive to cumulative angle error.  Since using a CRS using the standard library functions is not calibrated in speed, it seems you will drift over time from the original starting position if 3 revolutions is done by running the gearmotor for a fixed period of time without feedback.  Of course your application may not care about this in which case never mind!

Separately, if the discussion is about Arduino control for layout animations what's neat about the CRS approach is you can take the circuit board out and drive your own DC gearmotor CW and CCW using Arduino library commands.  So you still have the 1-wire control signal from the Arduino module to the servo board, and 2 wires from the servo board to your DC gearmotor.  Very simple hookup.  eBay and others have inexpensive DC gearmotors that may be easier to mount or with a more suitable speed range than what you get in a standard servo.

Would be interesting to know the application and whether a 'servo' is the right drive for whatever is being done. A lot of good cheap stepper motors that have tons of torque out there. Cheap cog belts too. (Parts used in 3D printers - good and plenty.). When you send so many steps to the motor in either direction, it pretty much goes there unless there is a major major bind in your mechanism. Repeatable, doesn't need position or rotational feedback (although you can use 'limit switches' to drive into a fixed stopping point, also facilitated with the Arduino programs and I/O

Can we say stepper motor? There are many direct drive and geared steppers, those you can actually determine zero, step at any rate you desire, and have it rotate as many times as you like under program control.  Tons of stepper motor drivers for Arduino as well as libraries to control stepper motors.

For cockpit panel instruments, before everything went digital, we used stepper motors to replace DC servos.  We actually had real angle feedback on them, but it was still more cost effective and reliable than the DC servos with the pot.