Has anyone used a rasberry pi or a picaxe board to control animations? I'm working on a rotary dumper and am stressed over having not been able to make the project work properly. Been using a Arduino and having problems with that. Any ideas?
Thanks
Jay
Replies sorted oldest to newest
We need a little help first.
Mike
Two model airplane servos, one regular the other continuous rotating. First is for the car clamping system. The other rotates the dumper.
It is all made by me.
IMO, you are fighting different problems. A microprocessor VS an actual computer based mini controller are about the programming side of it. A micro controller is really good at doing one thing over and over and over. A full blown computer is good at higher level networking and processing functions such as touch screen interfaces, USB based sensors and other devices.
Again, a Raspberry Pi is a computer, and yes, it has some microprocessor like IO pins, but you are writing an app that runs on top of the OS, and then can sense and manipulate IO. It takes time from power on for the OS to boot, and then your app to begin running before the machine can do any "work".
An Arduino or generic AVR microprocessor or the PIC processor family (Picaxe is just the firmware on a PIC processor) boots instantly and begins running your code nearly as soon as powered on.
Again, where the real problem lies is learning programming.
For a mini computer based setup, you might run Python or some other language as an application on top of the operating system to create your control function.
For Arduino/AVR, that's also the name of the Integration and Development Environment (IDE) where you write your program code and that in turn is linked or compiled to the machine language firmware that runs on the AVR microprocessor.
For PIC or PICAXE, you are using their respective IDE programming tools and learning that system.
Microcontrollers like PIC, PICAXE, AVR, "Arduino", they boot nearly instantly and take extremely low power to run. Mere milliamps at 5V.
A full blown mini computer like a Raspberry PI can take up to 2.5A of 5V power, take time to boot, and then your app runs on top of the operating system.
FWIW, I'm certain that the Arduino is more than capable of performing the functions required. As stated, no matter what intelligent platform you select, you still have to provide the custom code to perform the task. Quite truthfully, the Arduino is probably going to be the easiest platform to get up to speed on for something like this. I personally use the PIC processor for a number of my projects, but there is a steeper learning curve to get started with the development tools, not to mention buying the hardware debug platform. The Arduino is cheaper and easier to get up to speed for stuff like this. My main reason for using the PIC is I can build a board like this that is less than 1" square and do something useful with it.
@trainman129 posted:Two model airplane servos, one regular the other continuous rotating. First is for the car clamping system. The other rotates the dumper.
It is all made by me.
Cool.
Do you have hard stops for alignment at one ot more positions within the range of motion? If so, are there limit switches or other devices (perhaps encoders) to indicate position?
Mike
@trainman129 posted:Two model airplane servos, one regular the other continuous rotating. First is for the car clamping system. The other rotates the dumper.
It is all made by me.
OK, so given that detail, I might have some idea where you have problems. I am not saying I can fix them, but again, knowing microcontrollers and typical RC servos that require a very specific timed pulse control signal. The thing is, a microcontroller can "typically" ONLY do one thing at a time. So if you are sensing say an input as part of your main function loop, you stop sending an output. The trick is they then use interupt timers to generate the timed pulse signal to control the servo while the main function loop is circling around doing other things. All I'm getting at is, this is a common programming mistake, I'm not saying with any certainty this is your mistake, but as a guess, that's my first bet. While it sounds simple and there is the Arduino library for Servo function, it's really easy for a user to get the code wrong. I don't know that I'm the best person to help, but again, just having a good solid understanding of what does and commonly goes wrong, this is my guess why you might have issues. You probably would have to share both your Arduino code and your wiring and some other details for folks to troubleshoot all aspects of this. You also cannot ignore the power requirements for the servos themselves and since they may be in common with the processor power supply, I've seen people glitch themselves when the servos begin to move with inadequate supply or poor filtering.
As Mike pointed out, you may have input controls, and may have implemented sensor switches or other controls and end stops as well. I cannot lie, on one hand an RC servo builds out a lot of your control electronics and can even move the motor to relatively sane end points or limits, but the kicker is all about that timing pulse signal that is driving that position. Also, there are limits in how fast you want to move the servo and that is even more coding and function to change or adjust slew rates. Again, you are trying to output 2 continuous perfectly timed pulse streams that indicate position values to the servos constantly, meanwhile, your main program loop is trying to read and make decisions based on other inputs to then adjust the position values to new target positions. If you get it wrong, the pulse stream is not a constant value and the servo won't go or be in the position you want it. Worst case scenario, the servo rapidly jumps around and just goes crazy.
The best way I can describe it is servos is a good way of making the wiring and modules simple- the problem is, then the code to drive those servos, and what works and what doesn't is where the complexity begins as what sounds like what might possibly one of your first microcontroller projects.
As I said above, I'm using two servos so far in the project. I expect to use maby two more before the thing is done. I'm working on just the barrel right now. The rest can come later.
One servo works the clamping system to hold the car in position. The other needs to turn the dumper about 120 degrees to dump the load, then return to its start position. I'm using a flat timing belt around the "barrel", over some idler wheels and around a notched drive belt on the cont. rot. servo. I have'nt done a lot here; been concentrating on the clamp system.
Clamp needs to hold while the car is rotated/dumped,returned upright, then gets released. I have a program part that rotates the servo app. 45 deg. to work the clamp. Problem is when power is applied, the servo goes rapidly one direction and jams the clamp system. I haven't been able to find a way around this. Then I plan to use two photo interrupters for end stops on the barrel rotation.
Any suggestions here will be greatly appreciated.
Jay
@Vernon Barry posted:OK, so given that detail, I might have some idea where you have problems. I am not saying I can fix them, but again, knowing microcontrollers and typical RC servos that require a very specific timed pulse control signal. The thing is, a microcontroller can "typically" ONLY do one thing at a time.
Au Contrare, the Arduino (or pretty much any uP) can easily manage multiple PWM output trains. Even the smallest Arduino models like the Nano have at least six PWM outputs. I use a dirt simple 8-pin PIC processor in projects, even it handles multiple PWM outputs without raising a sweat, I have three of the six pins outputting PWM while other tasks are also handled. PWM is actually a dirt common control and it's very common for even very low end uP chips to be tasked with handling multiple PWM outputs.
While it's true that in a given microsecond the uP may only be doing one thing, it can actually keep many balls in the air. I've been programming microprocessors since the 1980's, and even ancient models like the 8080 were surprisingly capable of multi-tasking.
Jay: I agree that the Arduino is capable of handling this project; at least as far as you've described it. But the devils in the details. Show us your code. Add as an attachment. It doesn't have to be complete or pretty. That's how a problem like this can best be addressed.
@trainman129 posted:... Problem is when power is applied, the servo goes rapidly one direction and jams the clamp system. I haven't been able to find a way around this. ...
I don't know if this is what you're seeing but some low-cost ($1 on eBay from Asia) servos I've used exhibit an annoying startup behavior of jerking to a seemingly random location. See this 7 year old OGR discussion.
Also consider that at some point after your Arduino turns on, it must start sending the PWM command to instruct the servo what angle to go to. If your car turned off, lost power, or whatever in the middle of a dump cycle the servo itself will be at some arbitrary angle. Unless you were continuously saving (to non-volatile memory) the real-time angle of the servo, you will not know where the servo was when losing power. Your program likely assumes the servo is at the idle position on power up and would likely send the PWM command for the idle position. If the servo was turned off at other than the idle position there could be a violent startup jerk to the idle position since the servo is lightning fast in moving to a new position.
Separately, when I integrate servo mechanisms into animations, I've found a Servo Exerciser to be an invaluable tool before writing any software.
See this old OGR thread where there's even a video of the Exerciser in action. I find it useful to work out any kinks in the animation mechanism using the servo exerciser rather than wondering if there's some problem with the software contributing to any bad behavior.
I bought that Servo Exerciser when I was doing my Command Equipped Tie-Jector. It is a very useful tool, and dirt cheap as well.
I've done dozens of servo based accessory animation projects and have used that servo exerciser and at least four other servo control modules. One of the questions is whether the animation cycle is triggered automatically by train movement or is triggered manually by the layout operator. Nice to see another modeler using servos to animate accessories.
So apparently the servo power up twitch problem has been around for some time. It seems to be inherent to the design. Since the internal electronics are not yet awake when power is applied, the motor and positioning comparators are in an unknown state at power up resulting in some random behavior.
Or it could be random noise on the data input at initialization. But I've read that folks have tried both pull-up resistors and pull-down resistors on the data input with mixed results.
Some people claim that this is just in the nature of how a servo behaves. I doubt that all the R/C airplane enthusiasts can put up with a power up twitch that could cause damage to one of their models.
Maybe there are good servos that don't exhibit this behavior. I have come across nothing on the Internet (limited research) that lists which ones work without the starting twitch. Nor have I found any reliable work arounds for this problem. But almost everything that I've seen tells me that this is a persistent and difficult problem.
It has nothing to do with the processor that is being used to drive the PWM. The only thing that needs to be done is to hook up the power and ground wires and the twitch will occur.
@gunrunnerjohn posted:I personally use the PIC processor for a number of my projects, but there is a steeper learning curve to get started with the development tools, not to mention buying the hardware debug platform. The Arduino is cheaper and easier to get up to speed for stuff like this. My main reason for using the PIC is I can build a board like this that is less than 1" square and do something useful with it.
You can also use the Arduino platform with chips like the Attiny85, which is a comparably-sized AVR.
In all of my servo based animation projects, the servos are continuously connected to mating drivers which are triggered by some other action. This will avoid the twitch discussed here and seems to be the proper way to go to avoid such an issue.
@Consolidated Leo posted:Some people claim that this is just in the nature of how a servo behaves. I doubt that all the R/C airplane enthusiasts can put up with a power up twitch that could cause damage to one of their models.
Don't be too sure of that. I know I've seen the twitches when the airplane radios are turned on, my brother was a big RC fan.
@Professor Chaos posted:You can also use the Arduino platform with chips like the Attiny85, which is a comparably-sized AVR.
That came along well after I was vested in the PIC processors. 
A whole new learning curve how to use these...
@trainman129 posted:Two model airplane servos, one regular the other continuous rotating. First is for the car clamping system. The other rotates the dumper.
It is all made by me.
Is your rotary dumper based-on or modeled after an existing O-gauge animated coal, log, whatever accessory car?
What I'm getting at is these operating cars were made in many styles without servo mechanisms. What is the servo mechanism bringing to the party?
To achieve slow dumping/unloading action I think of a gearmotor slowly turning in one direction only driving an irregularly shaped cam to tilt or raise the load bed, then maybe a few bumps on the cam to "shake" the bed to insure all the coal is dropped, then lower the bed back to the idle position. A limit switch or similar sensor then detects the return to the idle position and stops the motor after, say, 1 revolution corresponding to 1 complete unload or dump cycle.
Could your mechanism use a CRS instead of a servo? A CRS will not twitch on power up. If for whatever reason it starts up in the middle of an incomplete cycle, the "worst" thing that can happen is it would continue on to complete the cycle and then stop.
Even for the clamping mechanism, I'd think something could be designed using a CRS. For example, the car would be clamped at 180 degrees and unclamped at 0 degrees. Limit switches could sense the two conditions of clamped or unclamped. If not practical to allow the CRS to spin a full 360 degrees (in one direction only), you could use the bidirectional capability of a CRS.
Having used servos coupled with programmable controllers on numerous projects to obtain controlled slow dumping actions, I have never encountered that twitch issue. I do plan to look further into it.
I used an arduino product to make a crossing gate with a servo for the gate and a DF Player sound board for the bell sounds. I needed two serial ports, and had a 'real' hardware port for the DF player and and a simulated software 'port' to run the servo. The 'software' simulated serial port conflicted with other interrupts in the Arduino and caused my servo to jitter horribly. I solved the problem by using another arduino that had multiple serial hardware ports. Just a suggestion.
For simulated serial ports, you need to use interrupts. Also, the interrupt routines shouldn't do a lot of processing, leave that in the mainline and minimize the amount of code running in the interrupt routines. If there is too much code in the interrupt routines, that will sometimes cause issues.
@CJ Meyers posted:I used an arduino product to make a crossing gate with a servo for the gate ...
Out of curiosity,
1) did you get a "twitch" when you initially apply power to the gate electronics?
2) and if for whatever reason you lost power or turned off power to the gate when the arm was down or partially down, when you next turned on power did it jerk up to the idle position?
Stan: If you apply power and ground to your servos, do they exhibit the power up twitch? I still can't say for sure if this is a common occurrence or if it only happens with some servo motors. Alas, I don't have any to test.
@Consolidated Leo posted:Stan: If you apply power and ground to your servos, do they exhibit the power up twitch? I still can't say for sure if this is a common occurrence or if it only happens with some servo motors. Alas, I don't have any to test.
It's been a few years since I've messed with servos but IIRC this was quite common in the inexpensive servos - remember we're talking hobby applications, no testing on animals, etc.
I think the point is I don't see how you get around it. In many applications, power can be lost or turned off at any time. The servo is then sitting at whatever angle. Then, when you turn on power again at some point you have to send a command to the servo to go to some angle. Unless you had saved away the last angle the chances are you will get a one-time jerk or twitch.
A typical inexpensive ($1-$2) servo has a so-called 60 degree spec of around 0.1 seconds. In other words, it can rotate 60 degrees in 0.1 seconds which is quite fast. That's a full 360 degree revolution (if it could fully rotate) in only 0.6 seconds...or about 100 RPM. Obviously there are some animations where you want to spin the servo arm rapidly...perhaps to eject a rail-tie like GRj's tie-jector. But consider a turnout animation like a Tortoise where you want to spin, say, 90 degrees in 3 seconds. That's 360 degrees in 12 seconds or "only" 5 RPM. Or if dumping a load of coal or logs I'd imagine a similar speed where the load bed rises to 90 degrees in 3 seconds or so...again about 5 RPM. So as I pondered in a previous post, if there is a way to use a CRS then you won't have the twitch or jerking problem. It is a one-time on power-up anomaly so it's a to-each-his-own.
@trainman129 posted:Clamp needs to hold while the car is rotated/dumped,returned upright, then gets released. I have a program part that rotates the servo app. 45 deg. to work the clamp. Problem is when power is applied, the servo goes rapidly one direction and jams the clamp system. I haven't been able to find a way around this. Then I plan to use two photo interrupters for end stops on the barrel rotation.
In this rare tidbit from the OP, it looks like he's got the twitch problem for sure.
One thing that I thought about is to get the data pulses going before the servo is powered up so that as soon as the electronics in the servo wake up, they would respond to something like return to midpoint or stop. So, you would have power to the servo controlled by the Arduino using a Relay/MOSFET or whatever. Then get the pulses going by calling the servo.write function before turning on the servo power. That might be worth a test.
Another idea is to reverse the order of the initial "write" and "attach" operations. Normally, you use "servo.attach" before you use "servo.write". Some recommendations that I have seen call for this to be done in reverse order:
Servo servo1;
setup () {
servo1.write(90);
servo1.attach(SERVO1_PIN);
I'm not sure how this would help, but I thought I should mention what I've come across from others pertaining to this problem.
It should also be noted that using the 5 volt power from the Arduino to power the servo motors is not recommended. A separate power supply may eliminate any noise on the line at startup.
Arduino for Dummies is a good book to help figure out writing code and how to use different functions.
Access to this requires an OGR Forum Supporting Membership
