Servo basics

Well exactly. But I thought that the Pi had some sort of 'set pwm value' and 'trigger pwm pulse' and even 'let it free run at that pwm'

It seems that it has:

And no code is required to maintain the thing in steady operation

AIUI that means driving two RC servos is trivial beyond belief

Se up the frequenciy to be say 30 Hz,set up the pulse widths and robert is a relative,

The onlyt delay would be in MOVING the servos

Not top say that a stepper motor is probably a better option with proper driver stuff

Steppers dont slew as fast as some servos though. Especially 'digital' ones which just need the odd pulse of a certain width and they are off to the new mark. IIRC no signal leaves them where they are.

--
Those who want slavery should have the grace to name it by its proper  
name. They must face the full meaning of that which they are advocating  
or condoning; the full, exact, specific meaning of collectivism, of its  
logical implications, of the principles upon which it is based, and of  
the ultimate consequences to which these principles will lead. They must  
face it, then decide whether this is what they want or not. 

Ayn Rand.

The Natural Philosopher wrote

Thats is nice, Pyhon I do not speak, some searching found this site in C++:

Enabling and contriolling the Pi PWM output boils down to just a few lines, in the link from that page:

C++ close to C, easily translated,

Maybe I will have a go later

You could select the SCHED_DEADLINE scheduler, standard in Linux since

3.14.x

Or apply the Prempt-RT patchset.

That's realy interesting but it's strongly NC oriented. I can control my

3d-printer via USB by sending S3G commands (sailfish fimrware) but that's too specific bound to the hardware and to the XYZ thinking.

What I'm dreaming of is a controller which allows defining a step input (including speed and maybe acceleration paramaters) and the motor moves to the position without any additional input. The final positition is sent back or confirmed on request via the used interface. Think of an axis contorl of a robot arm. The combination of several such modules can be controlled by a raspberry because the hardware part and the real time components are not important on that level. As example it I would be very simple add a GUI for programming, etc.

Is there a cheap solution known?

--
 Gerhard Reithofer - Techn. EDV Reithofer - http://www.tech-edv.co.at

On Fri, 21 Dec 2018 21:17:08 +0000, snipped-for-privacy@apple-juice.co.uk (D.M. Procida) declaimed the following:

Continuous rotation servos are basically ones in which the comparator (may have a different name) has been disabled. The comparator is the circuit that matches the integrated pulse (visualize charging a capacitor, the longer the pulse, the higher the voltage on the capacitor) to a voltage obtained from the position (visualize a potentiometer on the servo shaft). When the voltages match, the servo stops turning. Replacing the potentiometer side with a divider network (so it always reads "mid-point") means longer pulses move one direction, shorter pulses move the other way.

How many servos? For the most part, the RPi only has one readily accessible PWM output module. Any more and one has to program their own timing logic for digital GPIO (and mixing periods for multiple such is an even greater headache) -- and this logic will be subject to the OS tasking preemption.

""" If you want to control more than one servo, then the easiest way to do this is to use something like the Adafruit I2C 16 channel servo / pwm controller. This tutorial explains how to use it. """

Probably cheaper than using an Arduino UNO (I'm presuming you aren't going to be wiring up a bare AVR chip) to gain its 6 PWM outputs; not to mention you won't have to program a command protocol over the serial port.

Avoiding the Arduino, but also swapping out the RPi -- a Beaglebone Black has 7 pins that can be configured for PWM (two are normally the SPI pins) and runs Debian (on which Raspbian is based) -- so is a single board solution, and (if using Python) the code is practically the same (import a different IO package).

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Show how long it's been since I needed to look at the Linux scheduler. The default CFS scheme certainly does a good job for my normal workloads.

However, in this case running the low-level timing loop generating the servo control pulse train under the SHED_FIFO policy at high priority and using, say, aio_suspend() to synchronise it with the system clock looks like a reasonable plot. In pseudocode: repeat while run == true

pulse_width = convert_position_to_nanosecs(required_position); set the pin high; call aio_suspend(pulse_width);

set the pin low; call aio_suspend(50ms - pulse_width);

end-repeat

which would be run as a thread (preferably written in C to minimise its overheads) under the control of a scheduled process whose main task is to accept requests to change the servo's required position and use them to adjust the required_position variable.

Since this will use very little CPU time when running, it could be used to drive a whole shedload of servos and can potentially have pretty good servo position resolution. The resolution would mainly depend on how fast the system clock ticks.

--
Martin    | martin at 
Gregorie  | gregorie dot org

I wrote

hehe, and there is ready to go C code for RC servos by Frank Buss:

gcc -o pwm pwm.c ./pwm sends test sequences to GPIO18

I would be interested in that for an audio processing app..on a *86 machine...

can you point me at some more info?

likewise

--
There?s a mighty big difference between good, sound reasons and reasons  
that sound good. 

Burton Hillis (William Vaughn, American columnist)

With that spec I'd certainly be thinking 'arduino or picaxe and stepper motors'

--
There?s a mighty big difference between good, sound reasons and reasons  
that sound good. 

Burton Hillis (William Vaughn, American columnist)

mm0fmf wrote, on 22-12-2018 17:52:

Nice, it was a project wholly funded by the EU. What has the EU ever done for us? Given us realtime scheduling in the Linux kernel!

Old article:

Assorted pdfs of presentations. I know I've been to some of these presentations but my memory is dim of conferences I attended a few years back, they all merge into one.

For Preempt-RT, try the Real Time Linux Wiki

Of course, with all things real-time, YMMV. I know I experienced the difficulties of trying to get things to work the way we wanted when part of a team implementing SONAR processing on arrays of DSPs using a serious hard real time OS. The real time additions to Linux should (note should) make some tasks easier or maybe help reduce some of the worse effects of running on a OS with no real-time concepts. But real-time is real-hard. Still, it's something to play with.

It may still be both cost-effective and pragmatic to use Arduinos to do the RT stuff and control them with a Pi.

...

Yes, that would also definitely be my approach (I only know the Atmega world and have never used PICs). What astonisches me is the fact that there are many "simple analog servo controllers" but a relatively limited number of solutions for steppers. And the mature developmemts I've found are fully integrated into a specfic solutions and cannot be easy taken over into other requirements (examples are the NC and 3d-printer area).

THX to *

--
 Gerhard Reithofer - Techn. EDV Reithofer - http://www.tech-edv.co.at

That's what G-code does. For example:

G0 X99

will move to position 99 (in whatever units you've configured) on the X axis, leaving other axes unchanged.

M114

will read the current position.

Obviously there are G-codes for spindle control, coolant/material feed, etc, but if you aren't using CNC you can ignore those. While the axes are called X/Y/Z and possibly A/B/C depending on firmware, you can treat them as independent if you avoid commands like arc moves.

Theo

Something that seems to be coming more common in industry is a stepper combined with a precision absolute encoder. This combination is very good at staying *exactly* where you put it, with zero drift even when aged. Also, all the precision (hence cost) is only needed by the encoder.

For a dumb waiter type control the people I work for used this with a multi-turn absolute encoder at 4096 pulses per rev, and 4096 revs. In over 10 years, the only time it needed to be adjusted was when someone managed to jam it up but kept trying to make it run until the chains broke :(

--
W J G

There are a number of devices based on the PIC mpu and a some EEPROM. These are typically packaged as a single chip. The package size varies depending on how many i/o lines are provided and what they can be configured to do, but all of them have a thee line serial interface which is used for uploading programs and is usually available to applications as well.

These range in price from the Parallax Basic STAMP (24 pin, $49) to the

cross-compiler running on a PC which uploads the compiler program to the chip's EEPROM and provides some way of monitoring the program when its running (usually via the serial port. AFAICT all of these parre programmed in some form of integer BASIC.

I've used both STAMP and PICAXE.

IMO the STAMP has a considerably better and more capable BASIC and a decent IDE (combined editor/compiler/debugger) *but* has no PWM support and limited space for the program's variables though it does support 1, 4 and 8 bit variables and signed integers. However it was easy enough to control a servo with an explicit loop in the program while still monitoring other pins and implementing a timer that was accurate to within 0.5% of real time.

The PICAXE is also easy enough to use and provides both PWM output support and the ability to debounce button presses, but its BASIC is not nearly as capable (no signed integer support). There is an IDE but I haven't looked at it since it is simple enough to use a Makefile to control compilation and upload and to use your preferred editor to write programs. Debug is limited to writing trace messages to the serial port. The shop supplies a lot of useful support stuff including a USB-Serial adapter cable for connection to PICAXE chips, prototyping boards and decent plastic breadboards.

PICAXEs seem to be aimed at the education and 'maker' markets and their shop reflects this. Compilers are freely downloadable (both 32 bit and 64 bit) but are X86 only. However, the compilers do run on an RPi under qemu. Instructions for installing and running them on an RPi are here:

22547/

Other links. These are the main support sites and have shops:

PICAXE:

STAMP:

--
Martin    | martin at 
Gregorie  | gregorie dot org