Hardware ESC 8xSERVO CONTROL on PIC (Oshonsoft BASIC)

[rjenkinsgb]

If I'm correct, that the ENVELOPE is over 24ms,

That's because it is using a number of "channel" times, some real and some dummy ones, to get to the total time before it repeats.

The repeat time is not in any way critical; 20mS (50Hz) is a historical value, it's supposed to be somewhere around 40Hz to 200Hz repeat rate, so 5 - 25mS but that's not too critical with most servos.
Some do not like too high repeat rates and that can cause jitter.

If you want is slightly shorter, change this:

    If index > 15 Then
        //15 * average 1.5mS = 22.5mS, a reasonable frame repeat time

eg. changing 15 to 12 would reduce the cycle duration by 4.5mS

It will vary with total length of the servo pulses at that exact instant, though. That's the cost of not having any separate reset timing system.

Use 14 instead of 15 if you want it just slightly faster.

 

[camerart]

That's because it is using a number of "channel" times, some real and some dummy ones, to get to the total time before it repeats.

The repeat time is not in any way critical; 20mS (50Hz) is a historical value, it's supposed to be somewhere around 40Hz to 200Hz repeat rate, so 5 - 25mS but that's not too critical with most servos.
Some do not like to high repeat rates and that can cause jitter.

If you want is slightly shorter, change this:

    If index > 15 Then
        //15 * average 1.5mS = 22.5mS, a reasonable frame repeat time

eg. changing 15 to 12 would reduce the cycle duration by 4.5mS

It will vary with total length of the servo pulses at that exact instant, though. That's the cost of not having any separate reset timing system.

Use 14 instead of 15 if you want it just slightly faster.

Hi R,
I was just looking at that //15 calculation!
I need 6xCH, RB0-5. RB6+ are used by PICKIT3, do the dummy CH effect anything?

As it is now, it is slightly too long, but is that acceptable? (I want to avoid jitter) I don't know what the boundaries are.

At the moment, I only have 5xCH, and just tried a SERVO on all of the CH PINS. All moved, repeated and no jitter.
C.

 

[Nigel Goodwin]

Hi R,
I was just looking at that //15 calculation!
I need 6xCH, RB0-5. RB6+ are used by PICKIT3, do the dummy CH effect anything?

As it is now, it is slightly too long, but is that acceptable? (I want to avoid jitter) I don't know what the boundaries are.

As already explained above, it's EXTREMELY non-critical - double would be fine, five times could well be fine - slightly too long doesn't matter whatsoever.

 

[camerart]

As already explained above, it's EXTREMELY non-critical - double would be fine, five times could well be fine - slightly too long doesn't matter whatsoever.

Hi N,
Ok, thanks.
A lot has been said and often it is repeated, hopefully the repeats will not be needed eventually

I need 6xCH, RB0-5. RB6+ are used by PICKIT3, do the dummy CH effect anything?
C.

 

[camerart]

Hi,
The SERVO wasn't moving to it's full range, so I changed [ servo_times(x) = 0600 ] and the other side to [ servo_times(x) = 2400 ] This worked, so is this ok?

I've re-read #121 and now can see the range.

Sometimes the SERVO does a bit of jittering.

Does high repeat range mean longer or shorter length of time?
C

 

[rjenkinsgb]

do the dummy CH effect anything?

The dummy channels just pad out the overall sequence to give a reasonable delay before repeating.

For normal servos the repeat should not be less than 10mS, so with 6 x 0.8mS (4.8) you need four extra 1.5mS padding cycles (6mS) to guarantee you reach that. So, minimum total count of 10.

Experiment with different values - it won't hurt anything!

OK on widening the time range; if it works with the servos you have, it's fine.
Just be wary that different makes/types may hit the ends of the travel and stall or overload if you go outside the 1-2mS range.

 

[camerart]

The dummy channels just pad out the overall sequence to give a reasonable delay before repeating.

For normal servos the repeat should not be less than 10mS, so with 6 x 0.8mS (4.8) you need four extra 1.5mS padding cycles (6mS) to guarantee you reach that. So, minimum total count of 10.

Experiment with different values - it won't hurt anything!

OK on widening the time range; if it works with the servos you have, it's fine.
Just be wary that different makes/types may hit the ends of the travel and stall or overload if you go outside the 1-2mS range.

Hi R,
I think I've got it.
I've hit the buffers a couple of times.
I'll do some playing, then program some movement.
Interesting stuff, thanks.
C

 

[camerart]

Hi,
I'm sure I was advised to set TRISD to all OUT, can someone let me know if this is correct, and why, please?
I'm trying to add the SPI setting, and think they are clashing.
C

 

[Pommie]

This seems to be the relevant bit in the datasheet,

Mike.

 

[camerart]

This seems to be the relevant bit in the datasheet,
View attachment 137143

Mike.

Hi M,
I now remember that I set PORTB to '0' to see the 2x LED indicators (too lazy) I have set each BIT in PORTD, and it works as from 5mins ago, thanks.
C

 

[camerart]

Hi,
REMOTE:
PIC 1, 18F46K20 READS and send peripheral DATA to a computer screen for testing, including Altimeter and Compass, also control DATA to '2'.
PIC 2, 18F4431 receives SPI DATA from '1' and controls the MOTORS/SERVO.

While '2' is being programmed the compass outputs DATA. While '2' is running the Compass stops outputting.
What could cause this?
C

 

[Pommie]

While '2' is being programmed the compass outputs DATA. While '2' is running the Compass stops outputting.
What could cause this?

I would suggest a noisy power supply caused by the motors. Try disconnecting the motors and see if everything works ok.

Mike.

 

[camerart]

I would suggest a noisy power supply caused by the motors. Try disconnecting the motors and see if everything works ok.

Mike.

Hi M,
I'm testing with SERVOs, and have tried disconnecting, no difference.
In '1' I tried turning OFF the SPI to '2' no difference.
C

 

[Pommie]

If anything is using I²C then it can hang after a download as it can start in an unstable state. Could it be this?

Mike.

 

[camerart]

If anything is using I²C then it can hang after a download as it can start in an unstable state. Could it be this?

Mike.

Hi M,
All SPI! There is an Altimeter also wired the same, which always works?

One possibilty, is: I made my own Compass PCB from and iphone compass chip, which needs attention (more caps etc)

C

 

[camerart]

Hi,
Happy New Year.
I'm just coming back to the MOTOR/SERVO section of the project, and trying to catchup on the SERVO control (Servo used in place of motor for tests)
I've just leaded and tried this program:
At the moment there are only 5x outputs, and with a SERVO connected to 0, this is working but sometimes the pointer is fixed at an angle and sometimes it beats app 1/sec and jitters.
There's quite a lot to understand in the program and D/S.
Cheers, C.

 

[camerart]

Hi,
The SERVO is moving as it should, so the [ motor_servo(1) = 1500 ] seems correct.

There is quite a long gap 1/sec app between setting [motor_servo(1) = 1500] and the next [motor_servo(1) = 1500], so to me the LOOP is much too long.

Also in the D/S, there is a CPP for PWM, which uses TIMER2, here this sin't used, which is a puzzle. It looks as though the [motor_servo(1) = 1500] is set using TIMER1 timing.

I've changed [T1CON.TMR1CS = 0 '0 = Internal clock (F OSC/4)] in the posted program, but this is a puzzle too as the PIC is running from an 8MHz crystal with PLLx4.

I think this is going to take me a while to fully understand it.

I'm sure it's frustating to repliers earlier in this thread

EDIT: Remembering a couple of comments earlier, I re-checked the [CCP1CON] settings and changed back to [CCP1CON = %00001001] now the SERVO can't be moved once set, which is good, but there's still the LOOP delay.
C

 

[camerart]

Hi,
I've just re-read this thread, and there are quite a few differences of opinion, about what type of SERVO CODE should be used. I now think, PWM can't be used with this PIC, and the alternative is TMR1 and CCP, giving a series of SERVO times.

Timing could be a problem, and I recall that the clock must be 1MHz for correct timing, but the PIC runs at 8MHx crystal x 4PLL. I recall padding the number of times to 10 to give enough time?? It's possible that later for 'say' a camera, more servos would be handy, as there ar 8x on this PIC, I'll adopt this number.

Since the start of this thread, we have added SPI, which works fine, also so that there is only 1x TX/RX for RC, this is on PIC 1 MASTER. This PIC 2 SLAVE 18F4431 has SPI to MASTER and GPS which now uses the RX of this PIC, also now Motor contol. There was a comment regarding SPI, where I'm not sure if it clashes with anything?

I haven't found out why the 0 to 8 count LOOP takes app 1/2 second yet.

EDIT: Correction The REMOTE SLAVE (4431) doen't have QEI.
C.

 

[camerart]

Hi,
I've just re-tried the program at #45 and got the same result in OSH SIM as #51, however 'live' it doesn't work.

The program at #136 works with a slight judder as mentioned, but doesn't show in OSH SIM, which may show me where the 1/2 second judder occures. I'll try to figure it out

EDIT: In the OSH SIM The simulation slows to a snails pace at 'REAL TIME DURATION' 10000us, so TMR1 will take days to overflow, which I assume outputs the SERVO duration.
C
C

 

[jjw]

In the OSH SIM The simulation slows to a snails pace at 'REAL TIME DURATION' 10000us, so TMR1 will take days to overflow, which I assume outputs the SERVO duration.
C
C

??
I ran the original program/Rjenkinsgb from May 2022 in simulator and 100000us real time takes about 15 seconds.