NEED HELP with multiple servo motor

[ckielstra]

I find it difficult to give you advice on which route to go. It depends on all other tasks you have left to do for the project. 40 days isn't a lot, especially when you have to order new components.

dsPIC are great processors and with all the hardware peripherals they can offload a lot of work from software to the hardware. Your program will be smaller and run smoother but the large number of configuration options will make it more difficult to figure out the right settings.

The dsPIC is less used on this forum as it requires another compiler than the PIC16, making it expensive. Are you free to choose any dsPIC you want? For example the dsPIC30F2020?

[asmboy]

the 18f46k22 will be a pin for pin replacement for your older 16f pic.
use a 16mhz crystal with the PLL x4 and you are in 64mhz clock land.
this rate will divide nicely to give a clean 2 or 4 usec output resolution in a 1:16 prescaled timer based state machine core. should be fast enough for what you are doing.

with the above hardware setup you are running at 16 I-cycles/micro-second.

more important - if you use DIGITAL hobby servos - they typically do NOT need the oft quoted 50hz "refresh" - thus enabling set and forget ONLY when a sensor input changes.

the 18f46k80 is also pin for pin but has a 12 bit A/D which could benefit the ultimate resolution of your device - since with 1 part in 4096 position sensing and 2 usec servo resolution - "smooth" might just become possible :;-)):

you need to rework your circuitry to have a pic output pin per servo you wish to control - ideally all on port B or D . Port D would might be best-- while leaving enough of your A/D capable inputs free - OR use an external analog multiplexer with ONE analog in pin on the pic.
P O S T your present schematic so you can be helped along ok ??

[gaugeguy]

The 18F46K80 is not quite pin-pin compatible. RA4 is lost for a VDDcore/Vcap pin that requires a capacitor as described in the data sheet.
Care must also be taken with the A/D in the K80 due to the significant errata.

[ckielstra]

You will have to make a decision on the processor you are going to use.

Thing is, we still have no clue as to what your resources are. Some people on this forum come from large companies and can order any PIC processor they want to. Other people come from poor countries where no processor can be ordered and they have to do with the ancient 16F877a the school is providing.

The 16F877a is an old workhorse. Simple but limited. New processors are better in all respects and cheaper as well. But if you have to, it is possible to use some tricks and squeeze a few software PWM's at low resolution into it.

Doing PWM in hardware is the easiest software solution and would be my recommendation for any professional project, then the mentioned dsPIC is a good option. The earlier mentioned PIC16 with PWM is also an option but PIC16 have some hardware limitations that I'm not happy with.

For software PWM I recommend choosing a high performance PIC18 if possible. Choose the mentioned PIC18 if pin compatibility is an issue but otherwise you are free to choose any other model.

[temtronic]

I like the 18F46K22, kind of a Swiss army knife in PIC form !! It will handle the task of 8 RC servos without any problems.

Jay

[BLDD]

[Ttelmah]

Here's a rather large 'hint'. You'll have fun working out what I'm doing though....

[BLDD]

Hello,

Tomorrow i'll get my dspic, it seems the best solution at the moment! i'll get dsPIC33FJ128GP706 and the pickit3, so my project will work with the adc/pwm like i sayd before. to this i need to use the math to adapt my adc scale to the servo delays scale!
but after i present my project i'll stay here to learn more and more :D
my goal will be make it work with only software to improve my knowledges

Regards

[ckielstra]

I'm just wondering if we are not overcomplicating things.
You've got a program working for one servo that you are happy with.

The more complicated setups are required when you have to do asynchronous tasks next to the PWM creation. For example, many application require a serial port communication which has to be handled quick or otherwise received characters will get lost.

If you don't have these asynchronous requirements then there is another easy setup possible by just multiplying your original program for as many motors as you need (maximum about 10).

[Ttelmah]

I think it might be worth explaining a little.

Historically the 'RC servo' standard came about quite a while ago, with the earliest (post escapement) 'proportional' radio systems.
The way these worked, was that there was just a tone, sent over an AM radio. It was done a bit like Morse. There was a pause in the tone, then a sequence of bursts of tone. The receiver looked for the 'pause', and reset a counter when this was seen. Then on the first burst of tone after the pause, it sent a '1' to the first servo output, whose duration matched the tone. When the tone again stopped, it advanced a counter, and a pulse for the second burst, was sent to the second servo. This was repeated for all the servos involved. Then there was the long pause to start the whole sequence again.

Each servo, just receives a single logic pulse, whose duration controls the position it moves to. This comes at an interval depending on how many channels the radio has, and the total gaps between the pulses.

Now at the start there were several vaguely similar standards, with different tone durations, and different pause lengths, but manufacturers eventually standardised on 1.5mSec +/- 0.5mSec for the pulse period. The '50Hz' (often quoted), was never actually part of the standard. This corresponded to how often a servo would receive a new pulse, and typically the sequence was 2.5mSec for each servo (allowing a maximum 2mSec pulse with a 0.5mSec pause for the radio to detect the end of this), times the number of channels (typically 4 to 6), and then the longer pause to allow the counting to restart. This gave a total around 20mSec (hence 50Hz). However early radios that implemented more channels, then had longer frames. Some systems offered up to 10 channels, and with a 5mSec pause between the frames, the actual repetition rate to the servos, was down at around 30Hz. On early servos, a 'minimum' of around 25Hz, was typically suggested, with some units tending to creep/jitter if the rate went very much lower (also a few implement 'fail safe' operations if a gap over a second or two is met - while not common, things like sail winches, sometimes do this). Now with the creation of digital radios, with faster links, exactly the same pulse, was repeated ASAP to the servos, and the repetition rate climbed to 400Hz. Still exactly the same actual pulse.
Very low repetition rates slow down how quickly the 'position' can be updated. This is why multi-copters in particular typically run the update at the 400Hz rate, since the actual update is being done based on local calculations by the navigation system, and needs to be able to correct quickly.
Anyway, the key point is that the actual repetition rate, doesn't matter at all. Modern servos will typically accept rates reliably, anywhere between 1Hz, and 400Hz, without a murmur. It is the pulse width that matters.

So the point being made by Ckielstra, is to not worry about the repetition rate at all. Simply use your existing approach, and repeat it *8.

So read first ADC.
Calculate time.
Generate pulse for servo 1.
Read next ADC.
Calculate time for this one.
Generate pulse for servo 2.
Repeat for as many servos as needed.

Since you have the code already working for one channel, this should work fine for you, and is simple to code. The timings will vary as ADC readings change, but this doesn't matter at all.

The approach I posted, shows instead how to approach the problem, if the pulses must be synchronous, but other operations need to be carrying on with their own timings. As posted, it does not care whether positions are changed every 10 mSec, or every 10 minutes. It'll merrily carry on generating a stable pulse train whatever the main code is doing. Ideal for something like BLDC control.

[BLDD]

Thank you, it really helps me!! But I'm a little ambitious and i always want more and more, so its possible, using maths or something to create the scales? My math formula to define the servo delay gives us a little random position. Can i define my min adc value = min servo delay value and the same with the max values? i want to make the adc read more proportional with the delay assigned!

Regards

[Ttelmah]

Yes.

However this is where skill is really needed. You can calculate the output position (generally), as:

With values
ADC_minimum, ADC_maximum, Output_minimum, Output_maximum
and ADC_reading.

ADC_span= ADC_maximum-ADC_minimum

ADC_position = (ADC_reading-ADC_Minimum)/(ADC_span)

Output_span=Output_maximum-Output_minimum

output_value = (ADC_position*Output_span)+Output_minimum

Now the two 'span' values can be calculated in advance when you have calibrated the system.

However the 'ingenious' users, then realise that the values all depend on how you have the system setup. For instance on my servo code, the number of 'steps' over the range, depends on the clock rate being fed to the timer. You can select a different crystal, a different pre-scaler value, or even use a PWM output, to feed the timer input, to give you programmability of the number range involved. Similarly the values from the ADC, depend on what you choose for Vref- and Vref+. Now adjusting the values could (for instance) allow you to have a 'span' in the first calculation, that is a binary value (256, 512 etc.). Division by these values is faster than division by a normal number.
There are also some more ingenious ways to save time (binary scaled integer arithmetic in particular). However one solution on a PIC that has a reasonable amount of RAM, is simply to pre-calculate. Once you have your calibration points for ADC_minimum, ADC_maximum, and the required Output_minimum, and Output_maximum values, simply calculate the output that needs to be generated for every ADC input value between the minimum and maximum. The calculation can be done using float (slow), but then once you have the numbers, stored in an int16 array. The calculation for something like 1000 points, will still only take perhaps a second. Then in future for every ADC value a single lookup in the array gives the output required. Faster and simpler than doing the calculations as needed.....