V-tail Blender debugging

Arduino projects on the go
Post Reply
MaxZ
Posts: 330
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

V-tail Blender debugging

Post by MaxZ »

Hi guys,

Could I please ask for some assistance in debugging my "V-tail Blender" sketch. This is intended to reconstruct the rudder signal from the two V-tail channels, to help a friend out who does not have enough receiver channels to control his nose wheel steering servo.

The basis is Phil G's Digispark V-tail mixer. It is mostly the same code (although I changed some of the variable names), but it only has one output channel, and of course the adapted arithmetic.

I use a FlySky receiver, channels 2 and 4. I tap the through-going servo wires to the V-tail servo's, and connect those to P0 and P4. The Digispark calculates the rudder channel, and puts this out on P2.

The bug: P0 seems to block the Rx channel and locks it high. I checked this with the pulse meter and with an ordinary multimeter. There is no short circuit between either GND or Vcc. P0 is declared as input. There is no movement on the connected servo.

P4 is fine, I can read a pulse there and the connected servo functions properly.

Swapping the Rx channels at the receiver does not change anything, P0 remains "cold".

I cannot find fault in the sketch. I did reprogram the Digispark with usbasp several times and it completes the upload as usual. As P0 is also the MOSI connection, can I conclude that the processor is ok?

This is my code:

Code: Select all

/*
 * V-Tail channel blender to reconstruct the rudder channel, to control the nose wheel steering.
 * Based on the 50:50 Vtail mixer for ATTiny85 such as the 16mhz DigiSpark board by Phil_G.
 * By Max Zuijdendorp, september 2021.
 */
#define Rxch1 0 // receiver channel connected to P0
#define Rxch2 4 // receiver channel connected to P4
#define servoOut 2

volatile unsigned long timer_ch1, timer_ch2; // all timer variables are unsigned long
volatile int pulse_time1 = 1500, pulse_time2 = 1500, inpulse_time1 = 1500, inpulse_time2 = 1500, servoPulse = 1500;
volatile byte ch1Was = 0, ch2Was = 0, sync = 0;

void setup()
{
  pinMode(servoOut, OUTPUT);
  pinMode(Rxch1, INPUT);
  pinMode(Rxch2, INPUT);
  timer_ch1 = 0; timer_ch2 = 0;
  GIMSK = (1 << PCIE);   // Enable Pin Change Interrupts
  PCMSK = (1 << Rxch1) | (1 << Rxch2); // Enable interrupts for rx channel inputs
  sei();
}

void loop()
{
  while (sync == 0);
  sync = 0;
  delay(6);  // do the o/p pulses mid-frame, reduces jitter...
  cli();
  inpulse_time1 = pulse_time1; // do an atomic copy in the quickest way
  inpulse_time2 = pulse_time2;
  sei();
  inpulse_time1 /= 2; // then do arithmetic on the copies...
  inpulse_time2 /= 2;
  servoPulse = inpulse_time1 + inpulse_time2;
//  servoPulse = 3000 - servoPulse; // reverse servo rotation
  constrain(servoPulse, 850, 2150);
  digitalWrite(servoOut, 1); delayMicroseconds(servoPulse); digitalWrite(servoOut, 0); // servo out
}

ISR(PCINT0_vect)
{
  if (PINB & (1<<Rxch1)) {
    if (ch1Was == 0) {
      timer_ch1 = micros();
      ch1Was = 1;
    }
  } else {
    if (ch1Was == 1) {
      pulse_time1 = ((volatile int)micros() - timer_ch1);
      ch1Was = 0;
      sync = 1;
    }
  }
  if (PINB & (1<<Rxch2)) {
    if (ch2Was == 0) {
      timer_ch2 = micros();
      ch2Was = 1;
    }
  } else {
    if (ch2Was == 1) {
      pulse_time2 = ((volatile int)micros() - timer_ch2);
      ch2Was = 0;
    }
  }
}
Help!

Cheers,
Max.
Last edited by MaxZ on 23 Sep 2021, 19:32, edited 1 time in total.
User avatar
Mike_K
Posts: 669
Joined: 16 Feb 2018, 06:35
Location: Hertfordshire

Re: V-tail Blender debugging

Post by Mike_K »

Hi Max

The first thing I would do is to check if Phil's ATtiny85 v-tail mixer works OK with the FlySky. I designed a v-tail mixer back in the mid-1990s using a PIC and it worked great until I tried it with a fast frame rate Spektrum, I'd always assumed a minimum of a 20mS frame rate, but the Spektrum was 11mS and didn't allow enough time for the ppm outputs to finish before the next inputs arrived.

I think Phil's program is similar, there is a 6mS delay after the input ppm pulses before outputting the ppm outputs, so with all inputs neutral, you would have 1.5mS input (CH2), another 1.5mS delay for CH3, then 1.5mS (CH4), then 6mS delay, then another 2x 1.5mS for the outputs = 13.5mS. You only have one output, but it would still need the frame rate to be >12mS to work. Do you know what frame rate the FlySky uses? Try reducing the delay value on line 29 to 1mS if the v-tail mixer doesn't work with the FlySky

delay(1); // do the o/p pulses mid-frame, reduces jitter...

Next, I don't think you have your calculations quite correct, you'll output the elevator value. With a typical v-tail mixer the output calculations are:
output1 = 0.5x elevator value + 0.5x rudder value
output2 = 0.5x elevator value - 0.5x rudder value

So with full rudder (2000uS) and neutral elevator (1500uS) output1 = 1750uS and output2 = 1250uS

You have rudder value = value1 /2 + value2 /2 = 1750/2 + 1250/2 = 875 + 625 = 1500uS (elevator value)

I think what you need is: (value1 - 1500) - (value2 - 1500) + 1500 = rudder value

which can be simplified to: value1 - value2 + 1500 = rudder value

You would now get 1750 - 1250 + 1500 = 2000uS

But if you are using "unsigned int" variables for the calculations, re-order the calculations to be:
1500 + value1 - value2 = rudder value (to ensure you never get a negative value in your calculations)

Finally, are you using a Digispark board or an ATtiny85 chip? I would not recommend using PB3 or PB4 as inputs on a Digispark as they are connected to the USB lines via 68R resistors, I'd always use PB0, PB1 or PB2 for ppm inputs. If you are using just an ATtiny85 chip, then it isn't a problem to use any of the I/O and your PB0 and PB4 is OK.

Mike
MaxZ
Posts: 330
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: V-tail Blender debugging

Post by MaxZ »

Hi Mike,

Thanks for your extensive reply.

Re. the frame rate, I just checked and it is 20 ms, so that should be ok.

Re. the calculations: the V-tail in question is a fully symmetric setup, so the servo's run in opposite directions for elevator, so any difference from 1500 uS of the left servo is compensated by the uS of the right servo, and dividing them by 2 and adding them will always be 1500.

Rudder on the other hand will require the servo's to run in the same direction, and dividing them by 2 and adding them will get you 1500 + a single deviation.

In total this will result in 3000 + a single deviation. By writing this I can see now that I have got 1500 too much in the calculated rudder signal, and that I will have to revise the code there.(edit: No, see below)

I am using a "defluffed" Digispark, so the 68 Ohm resistors have been removed, making it safe to use P4 in my opinion.

I will do the math on the calculations properly to be sure, and upload to the Digispark again. But I still cannot understand how one of the inputs can literally be blocked by the code, stopping any pulse going through to the connected V-tail servo through a continuous lead with just the signal being tapped and hooked up to P0.

Thanks again, cheers,
Max.

Edit: Proper calculations tell me that the code is correct as it was in the first instance.

Right servo pulse: 1500 + Rud_value + Ele_value. Divide by 2: 750 + 0.5*Rud_value + 0.5*Ele_value
Left servo pulse: 1500 + Rud_value - Ele_value. Divide by 2: 750 + 0.5*Rud_value - 0.5*Ele_value

Add Left and Right: 1500 + 1*Rud_value + 0*Ele_value = 1500 + Rud_value, equals a complete Rudder pulse

Edit2: swapped left and right servo's, but the final result remains the same
MaxZ
Posts: 330
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: V-tail Blender debugging

Post by MaxZ »

Whatever the problem with P0 might be, everything is resolved by avoiding it and connecting Rxch1 to P1 instead.
The code is correct, P2 outputs the bare rudder signal :D

Cheers,
Max.
MaxZ
Posts: 330
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: V-tail Blender debugging

Post by MaxZ »

One bug killed, another one appears in the lamplight. I am getting quite severe jitters of more than 50 uS upwards 2-3 times per second. Too short to read the exact deviation with the pulse meter, but a more or less steady 1550 uS blips to more than 1600 uS.

I have tried two things so far, change the delay right at the begin of the loop, and move the sync within the ISR to the end, after the second Rx pulse has been sampled. No results.

Any tips anyone?

Cheers,
Max.

(P.S. can I monitor the ATtiny via a serial link?)

Edit: Solved, or at least reduced to acceptable variations. I forgot to reprogram the Attiny to 16 MHz :(
bluejets
Posts: 316
Joined: 19 Jun 2019, 04:09

Re: V-tail Blender debugging

Post by bluejets »

Re-monitor ATtiny85 via serial.....

https://www.youtube.com/watch?v=HJ4mhXv-MXo&t=15s
User avatar
Mike_K
Posts: 669
Joined: 16 Feb 2018, 06:35
Location: Hertfordshire

Re: V-tail Blender debugging

Post by Mike_K »

Hi Max

You can use serial monitor with an ATtiny85, but the time spent transmitting the serial packets can be so long as to mess up your ppm/pwm output timing unless you use a high baud rate to get everything transmitted before the ppm/pwm output. If it was me debugging this, first I would just use the serial monitor to measure the two ppm/pwm inputs to ensure they were being measured correctly. Next, I'd use a logic analyser to measure the inputs and outputs over a period long enough to measure at least one of the inconsistent output pulses. Basic logic analysers are not that expensive, the one below will happily measure to 1uS and can record multiple channels over a number of seconds, certainly it can record 3 channels over 10 seconds. And there are many other sellers of same logic analyser, this is a UK seller I've previously used:

https://www.ebay.co.uk/itm/313623873097 ... Swgo1hBvin

You can download free compatible software from:

https://www.saleae.com/

Cheers Mike
MaxZ
Posts: 330
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: V-tail Blender debugging

Post by MaxZ »

Mike_K wrote: 26 Sep 2021, 13:52 Next, I'd use a logic analyser to measure the inputs and outputs over a period long enough to measure at least one of the inconsistent output pulses. Basic logic analysers are not that expensive, the one below will happily measure to 1uS and can record multiple channels over a number of seconds, certainly it can record 3 channels over 10 seconds.
Following your advice Mike, I put one on order today.

Cheers,
Max.
MaxZ
Posts: 330
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: V-tail Blender debugging

Post by MaxZ »

I realised that I never informed you guys on the outcome of this drama.

Even though I did find a solution simply by avoiding P0, I was not satisfied with the result. I decided that the Digispark I was using probably was duff, so I programmed another one. And hey presto, it functioned as intended!

It is now in use in my friend's Fouga Magister https://www.rbckits.com/shop/fouga-magister.html and everything is fine. Still some jitter is present, but that is not important for the intended purpose, steering the nose wheel.

Now, I want to use the same way of getting the input pulses (thanks Phil) for another experiment on a Uno/Nano, but it does not accept the GIMSK and PCMSK commands. I have tried to read through the specs to find the equivalents, but I am getting stuck. Can anybody help me here?

For the code, see my starting post.

Cheers,
Max.
Martin
Posts: 744
Joined: 16 Feb 2018, 14:11
Location: Warwickshire

Re: V-tail Blender debugging

Post by Martin »

I suggest you take a look at my On-board Elevon/V-tail mixer
It takes in two channels of input, call them A and B, and provides four outputs: A+B, A-B, B-A, -A-B. You just plug your servo(s) into each of the four outputs till you find the one that moves in the direction you want. No need for reversing switches or changes to the code.
It uses interrupts and timers to provide very accurate, jitter-free mixing.
Post Reply