Arduino Forum

Using Arduino => Sensors => Topic started by: Carlos mononoke on Nov 05, 2012, 01:19 pm

Title: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 05, 2012, 01:19 pm
Hi,

I´m trying to read the RC signal on the receiver with pulseIn() function, i am using 6 ch rx tx turnigy equip.
What i am trying is to read the value and print in the serial monitor but
I´ve tryed:
-Power the receiver with arduino regulator and power with 7805 regulator
-Connect the GND pin in the receiver´s channel slot to arduino gnd pin
- Read the high value and the low value time
- Use analogRead too

Allways I´ve readed 17731 value,in the beggining I was trying to read the six values
but now I am trying to read only one value,and if I disconnect the receiver from arduino´s pins in the serial monitor read 17731 again,but a bit slowly.
someone knows why or what is happening????
Thanks!!!!!!
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 05, 2012, 01:26 pm
I can probably help.

First of all, are you reading the channels individually through six three wire connections or are you reading a PPM Stream which contains all of the six channels in a single connection ?

Duane B

rcarduino.blogspot.com (http://rcarduino.blogspot.com)
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 05, 2012, 01:47 pm

I am reading the channels individually,first I connected six single wire,the receiver signal pin to arduino I/0 and then y tryed to connect the receiver gnd pin to arduino gnd pin too
(six double wire)
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 05, 2012, 01:51 pm
That sounds fine.

Lets try and read one signal first, try the sketch in this link

http://rcarduino.blogspot.com/2012/01/how-to-read-rc-receiver-with.html (http://rcarduino.blogspot.com/2012/01/how-to-read-rc-receiver-with.html)

connect one of your channels to pin 2 of your Arduino to read it

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 05, 2012, 01:57 pm
thanks, I will read and try this afternoon.
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 05, 2012, 02:01 pm
Let me know how you get on, I can point you to the links for more channels and when your up and running - my new library.

Duane B

rcarduino.blogspot.com (http://rcarduino.blogspot.com)
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 05, 2012, 06:20 pm
hi!!!
I read and try your sketch for one channel and work perfectly.
Thanks!!! now I will start with the oder two tutorial(for more channels),I will tell you.
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 05, 2012, 07:48 pm
Its good to read and understand this one -

http://rcarduino.blogspot.com/2012/04/how-to-read-multiple-rc-channels-draft.html (http://rcarduino.blogspot.com/2012/04/how-to-read-multiple-rc-channels-draft.html)

but if your feeling brave try this one -

http://rcarduino.blogspot.com/2012/11/how-to-read-rc-channels-rcarduinofastlib.html (http://rcarduino.blogspot.com/2012/11/how-to-read-rc-channels-rcarduinofastlib.html)

Its going to be a big benefit with six channels, the sensitive parts of the code are much faster than the original link.

If you need help with it let me know.

Duane B

rcarduino.blogspot.com (http://rcarduino.blogspot.com)
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 05, 2012, 10:57 pm
Hi again,
I was understanding the first one, but when upload the example code,
the servo start to move like little crazy.
So I added a serial print inside  the interrups,in the else stament,just before updating the flag,for see the variable
that is passed to the servo but it was randomly,always between 17000 and 25000.
I have use first the 2,03 version and them 1.81 library,but no.
it´s that normal????

thanks for your help :D
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 05:57 am
Hi,
   Its going to be something simple, my first guess is that you have the receiver channel connected to digital pin 2 still.

The multi channel code expects channels to be connected to pins 5,6,7

Code: [Select]

// Assign your channel in pins
#define THROTTLE_IN_PIN 5
#define STEERING_IN_PIN 6
#define AUX_IN_PIN 7


And servos to 8,9,10 so that the channel on pin 5 drives the servo on pin 8, 6 drives 9, 7 drives 10

Code: [Select]

// Assign your channel out pins
#define THROTTLE_OUT_PIN 8
#define STEERING_OUT_PIN 9
#define AUX_OUT_PIN 10


I would also suggest that you remove the serial commands you have added, they are not the problem, but they should not be inside any of the time sensitive sections of code.

If this doesn't help, PM me the sketch and what board you are using.

Duane B

rcarduino.blogspot.com (http://rcarduino.blogspot.com)
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 12:27 pm
Good morning!!!
No, I have connected well the receiver channel and servo,now I am using one nano v3.0.But when RC works i want to use in oder proyect in ARduino Mega 2560.
I put the code for try to understand what´s happening,or see what is reading from the receiver.
Thanks!!!!

the sketch:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------
// MultiChannels
//
// rcarduino.blogspot.com
//
// A simple approach for reading three RC Channels using pin change interrupts
//
// See related posts -
// http://rcarduino.blogspot.co.uk/2012/01/how-to-read-rc-receiver-with.html
// http://rcarduino.blogspot.co.uk/2012/03/need-more-interrupts-to-read-more.html
// http://rcarduino.blogspot.co.uk/2012/01/can-i-control-more-than-x-servos-with.html
//
// rcarduino.blogspot.com
//

// include the pinchangeint library - see the links in the related topics section above for details
#include <PinChangeInt.h>

#include <Servo.h>

// Assign your channel in pins
#define THROTTLE_IN_PIN 5
#define STEERING_IN_PIN 6
#define AUX_IN_PIN 7

// Assign your channel out pins
#define THROTTLE_OUT_PIN 8
#define STEERING_OUT_PIN 9
#define AUX_OUT_PIN 10

// Servo objects generate the signals expected by Electronic Speed Controllers and Servos
// We will use the objects to output the signals we read in
// this example code provides a straight pass through of the signal with no custom processing
Servo servoThrottle;
Servo servoSteering;
Servo servoAux;

// These bit flags are set in bUpdateFlagsShared to indicate which
// channels have new signals
#define THROTTLE_FLAG 1
#define STEERING_FLAG 2
#define AUX_FLAG 4

// holds the update flags defined above
volatile uint8_t bUpdateFlagsShared;

// shared variables are updated by the ISR and read by loop.
// In loop we immediatley take local copies so that the ISR can keep ownership of the
// shared ones. To access these in loop
// we first turn interrupts off with noInterrupts
// we take a copy to use in loop and the turn interrupts back on
// as quickly as possible, this ensures that we are always able to receive new signals
volatile uint16_t unThrottleInShared;
volatile uint16_t unSteeringInShared;
volatile uint16_t unAuxInShared;

// These are used to record the rising edge of a pulse in the calcInput functions
// They do not need to be volatile as they are only used in the ISR. If we wanted
// to refer to these in loop and the ISR then they would need to be declared volatile
uint32_t ulThrottleStart;
uint32_t ulSteeringStart;
uint32_t ulAuxStart;

void setup()
{
  Serial.begin(9600);

  Serial.println("multiChannels");

  // attach servo objects, these will generate the correct
  // pulses for driving Electronic speed controllers, servos or other devices
  // designed to interface directly with RC Receivers
  servoThrottle.attach(THROTTLE_OUT_PIN);
  servoSteering.attach(STEERING_OUT_PIN);
  servoAux.attach(AUX_OUT_PIN);

  // using the PinChangeInt library, attach the interrupts
  // used to read the channels
  PCintPort::attachInterrupt(THROTTLE_IN_PIN, calcThrottle,CHANGE);
  PCintPort::attachInterrupt(STEERING_IN_PIN, calcSteering,CHANGE);
  PCintPort::attachInterrupt(AUX_IN_PIN, calcAux,CHANGE);
}

void loop()
{
  // create local variables to hold a local copies of the channel inputs
  // these are declared static so that thier values will be retained
  // between calls to loop.
  static uint16_t unThrottleIn;
  static uint16_t unSteeringIn;
  static uint16_t unAuxIn;
  // local copy of update flags
  static uint8_t bUpdateFlags;

  // check shared update flags to see if any channels have a new signal
  if(bUpdateFlagsShared)
  {
    noInterrupts(); // turn interrupts off quickly while we take local copies of the shared variables

    // take a local copy of which channels were updated in case we need to use this in the rest of loop
    bUpdateFlags = bUpdateFlagsShared;
   
    // in the current code, the shared values are always populated
    // so we could copy them without testing the flags
    // however in the future this could change, so lets
    // only copy when the flags tell us we can.
   
    if(bUpdateFlags & THROTTLE_FLAG)
    {
      unThrottleIn = unThrottleInShared;
    }
   
    if(bUpdateFlags & STEERING_FLAG)
    {
      unSteeringIn = unSteeringInShared;
    }
   
    if(bUpdateFlags & AUX_FLAG)
    {
      unAuxIn = unAuxInShared;
    }
   
    // clear shared copy of updated flags as we have already taken the updates
    // we still have a local copy if we need to use it in bUpdateFlags
    bUpdateFlagsShared = 0;
   
    interrupts(); // we have local copies of the inputs, so now we can turn interrupts back on
    // as soon as interrupts are back on, we can no longer use the shared copies, the interrupt
    // service routines own these and could update them at any time. During the update, the
    // shared copies may contain junk. Luckily we have our local copies to work with :-)
  }

  // do any processing from here onwards
  // only use the local values unAuxIn, unThrottleIn and unSteeringIn, the shared
  // variables unAuxInShared, unThrottleInShared, unSteeringInShared are always owned by
  // the interrupt routines and should not be used in loop

  // the following code provides simple pass through
  // this is a good initial test, the Arduino will pass through
  // receiver input as if the Arduino is not there.
  // This should be used to confirm the circuit and power
  // before attempting any custom processing in a project.

  // we are checking to see if the channel value has changed, this is indicated
  // by the flags. For the simple pass through we don't really need this check,
  // but for a more complex project where a new signal requires significant processing
  // this allows us to only calculate new values when we have new inputs, rather than
  // on every cycle.
  if(bUpdateFlags & THROTTLE_FLAG)
  {
    if(servoThrottle.readMicroseconds() != unThrottleIn)
    {
      servoThrottle.writeMicroseconds(unThrottleIn);
    }
  }

  if(bUpdateFlags & STEERING_FLAG)
  {
    if(servoSteering.readMicroseconds() != unSteeringIn)
    {
      servoSteering.writeMicroseconds(unSteeringIn);
    }
  }

  if(bUpdateFlags & AUX_FLAG)
  {
    if(servoAux.readMicroseconds() != unAuxIn)
    {
      servoAux.writeMicroseconds(unAuxIn);
    }
  }

  bUpdateFlags = 0;
}


// simple interrupt service routine
void calcThrottle()
{
  // if the pin is high, its a rising edge of the signal pulse, so lets record its value
  if(digitalRead(THROTTLE_IN_PIN) == HIGH)
  {
    ulThrottleStart = micros();
  }
  else
  {
    // else it must be a falling edge, so lets get the time and subtract the time of the rising edge
    // this gives use the time between the rising and falling edges i.e. the pulse duration.
    unThrottleInShared = (uint16_t)(micros() - ulThrottleStart);
    // use set the throttle flag to indicate that a new throttle signal has been received
    bUpdateFlagsShared |= THROTTLE_FLAG;
    Serial.println(unThrottleInShared,DEC);
  }
}

void calcSteering()
{
  if(digitalRead(STEERING_IN_PIN) == HIGH)
  {
    ulSteeringStart = micros();
  }
  else
  {
    unSteeringInShared = (uint16_t)(micros() - ulSteeringStart);
    bUpdateFlagsShared |= STEERING_FLAG;
    Serial.println(unSteeringInShared,DEC);
  }
}

void calcAux()
{
  if(digitalRead(AUX_IN_PIN) == HIGH)
  {
    ulAuxStart = micros();
  }
  else
  {
    unAuxInShared = (uint16_t)(micros() - ulAuxStart);
    bUpdateFlagsShared |= AUX_FLAG;
    Serial.println(unAuxInShared,DEC);
  }
}
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 12:47 pm
Hi,
   Can you take the serial commands out of the interrupt routines, thats the last place you would want to put them.

Lets focus on just the throttle channel for now, put a serial print inside this section in the main loop -

Code: [Select]

if(bUpdateFlags & THROTTLE_FLAG)
  {
    if(servoThrottle.readMicroseconds() != unThrottleIn)
    {
      servoThrottle.writeMicroseconds(unThrottleIn);
    }
    // Serial print here ....
  }


The only reasons I would expect random values are -

1) Floating inputs - your ISR is pointing to a pin that is not connected

2) No common ground - check that the receiver ground is connected to the arduino ground

3) Some difference in pin/port mappings on Nano3.0 that makes pinchangeint reference the incorrect pin

It might not be any of these, but an easy way to check is to connect each digital pin to ground one by one and watch the output, if the output stop we know that the pin you just grounded was the one that the signal was being read from.

Use a 10K resistor as the connection to ground to limit the current in case one of the pins is set to output.

Does this make sense ? let me know how you get on

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 01:07 pm
So, the experiment will be, throttle thah is pin 5 in arduino, trought a 10k resistor conected to ground, and the output in the serial monitor will stop becouse there is no change for interrupt no???, and if this don´t happen change looking for the real pin.
I will do, but yesterday when I power down the transeiver (buttom off),the serial monitor stop. well I´ll try and say what happend in a moment.
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 01:19 pm
Let me know what happens, I am eager to get to the bottom of this ...

Duane.
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 01:32 pm
Worksss!!!!!!!!!!
it was my foult I sopouse that first i try reading the serial monitor and when i saw the random read values i connected the servos and nothing works.
it was what you say I must read out of the interrupt,but i don´t understand this so well.What was the diference between read the shared value just before give  this value to the loop, and  read the value when you use in the loop???

Thanks a lot!!!!!!
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 01:44 pm
There is a lot of good information in this link

http://rcarduino.blogspot.com/2012/04/how-to-read-multiple-rc-channels-draft.html (http://rcarduino.blogspot.com/2012/04/how-to-read-multiple-rc-channels-draft.html)

Your question relates specifically to this part of the post -

2) Variable Access

And the reason you should not put serial print in the time sensitive parts of the code -

3) Fast Interrupt Service Routines

Let me know if that makes sense of not.

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 01:59 pm
Yes,I´ve read it yesterday and i thing i understand, but what i don´t understand well is if i read something
in the interrupt but just when all is finish is not the same that read when we go back to the loop.
I am thinking in this particular case, when we hava the variable that is needed update and we go back to the loop for make a copy.
is not the same read this variable that we will copy in the loop??? well is not the same and i see the real case no when i did this i have unexpected values and when i read in the loop i have expected values.... but for me it´s a little extrange.
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 02:09 pm
When you are in the interrupt, no other interrupts can happen.

If you do something slow in the interrupt like Serial.println no interrupts can happen for a long time, this means that we will get inaccurate values because we are not able to respond to the new interrupts until we finish the current one. When we do get to respond the values we read will be wrong.

So it is the same variable, but by using Serial.println in the interrupt we were ensuring that it would become inaccurate.

You want to get in and out of interrupts as quickly as possible

If you look here you will see that I am reading timers directly instead of using micros, you can also see the improvement in accuracy in the graphs -

http://rcarduino.blogspot.com/2012/11/how-to-read-rc-channels-rcarduinofastlib.html (http://rcarduino.blogspot.com/2012/11/how-to-read-rc-channels-rcarduinofastlib.html)

Stay with the code you are using for now, once you are a familiar I would like to help you try this code, its faster but a bit new.

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 02:23 pm
aha, i understand you, thanks a lot Duane. now i ill try to update the RC to my proyect, i am doing a puppet.
but i will follow your web, and in some days i hope to probe your  fast library.
Only one thing , I want to include you in the acknowlegement of my proyect,you have help me a lot,
Can you mail me your name to alehop@mononokeproducciones.com

THANKS Duane B!!!!!
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 03:04 pm
Hi,
   If you keep some variation of this with a link to the RCArduino blog, that would be great as acknowledgement.

   Also if you let me know what you build I will put a link to your project on the RCArduino blog.

Duane B
   

Code: [Select]

// MultiChannels
//
// rcarduino.blogspot.com
//
// A simple approach for reading RC Channels using pin change interrupts
//
// See related posts -
// http://rcarduino.blogspot.co.uk/2012/01/how-to-read-rc-receiver-with.html
// http://rcarduino.blogspot.co.uk/2012/03/need-more-interrupts-to-read-more.html
// http://rcarduino.blogspot.co.uk/2012/01/can-i-control-more-than-x-servos-with.html
//
// rcarduino.blogspot.com
//


Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 04:37 pm
Duane at this moment a haven,t any place for show my proyects but i want to do one blog.
Whent this happend of course I put the link to your work.
But, one more time, Thanks, this week i want to change my code for include RC control i will tell you how works all together.
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 05:42 pm
only one question? Can i asing the receiver to Analog i/o (A10 t0 A15 in the arduino mega) or this is not allow???
thanks!!!
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 05:47 pm
Hi,
   You should be able to, try it.

   Why do you want to though ?

   I always think that analog pins are more valuable than digital pins as they have functionality so try to use them last.

   If its just because you are running out of pins, there are lots of ways around that problem.

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 06:19 pm
I am trying but when I veryfy say that A13 is not declare in this scoope;
I soupouse that may be is becouse is not allow by library ....
-------------------------------------------------------------------code---------------------------------
PCintPort::attachInterrupt(A13, calcThrottle,CHANGE);
------------------------------------------------------------
I want to use this pins only becouse I have made a shield for the mega and in the last moment I decide to include RC control so I am trying to keep the shield.... you know if i change the shield i must change all the circuits that i have done and I need to finish the proyect....
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 06:23 pm
There is a plan B.

I have just spent the past few minutes hacking two RC Receivers to access all the channels through a single pin.

Are you up for taking the case off your receiver to see if yours supports this ?

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 06:27 pm
of course
what is what i must lok for??
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 06:29 pm
There will be one or more chips inside, if we are lucky one of them will have the number 4015 on it - that chip is what gives us a plan B.

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 06:35 pm
no...
here are :

7105
FT24C02A
TG48754
CA33g
a clock...
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 06:43 pm
well if is imposible to use the APins(or so complicated) i could sacrify one RGBLed an cut the shield for use the Digiltal 7 to 13, is less beuty but yes i am in this point.  ]:D
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 06:43 pm
What is the receiver make and model - I will have a scan around and see what alternatives might be inside - we are looking for a counter IC or a shift register IC.

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 06:48 pm
here is the model

http://www.hobbyking.com/hobbyking/store/__12901__Hobby_King_2_4Ghz_Receiver_6Ch_V2.html
if you want i can make a picture and sen you
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 06:52 pm
Post the picture here, if we find the right chip, it will be useful for others to follow

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 06:59 pm
Ok, it looks like you might have a PPM output on the battery pin.

Write a quick test sketch using pulse in on one of your digital pins and connect the arduino pin to the receiver pin which is nearest the word 'bat'.

If you get a consistent stream of short pulse, you have PPM on that pin.

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 07:30 pm
ok here is the photo....

ill try the sketch (http://)
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 07:45 pm
This post gets very off topic but seems to suggest that earlier versions of the receiver have PPM on the battery pin (pin nearest bat). Later versions do not.

Yours has ZLH which some people have suggested means it is a later board and does not have PPM, try it anyway, the post is not very clear.

http://9xforums.com/forum/viewtopic.php?f=42&t=1487

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 08:00 pm
well.. two things...

first one The Apins works perfectly in the arduino Mega the mistake was that i have selected nano board.... (mmm juyuuu i am discovering how much stupid can i be, no limit for my....)

the second one i have try this sketch:
---------------------------------------------------------------------------------------------------------------------------------------------------
/*
  Prueba de mando R\C
*/
int Ch1Pin =2;

//// variables donde mapeamos la lectura de 0 1024 a 0 256

unsigned long Ch1Var;

//////////////////////////////////////////////////

void setup() {
  Serial.begin(9600);
  pinMode(Ch1Pin,INPUT);

}

void loop() {
  Ch1Var = pulseIn(Ch1Pin,HIGH,200000);   
          Serial.println("POSITIVO");
          Serial.println('Ch1Var,DEC');
  Ch1Var = pulseIn(Ch1Pin,LOW,200000);     
          Serial.println("negativo");
          Serial.println('Ch1Var,DEC');
}
--------------------------------------------------------------------------------------------------------

and what i have obtain in the serial monitor is read 17731 for high and 17731 for low every time like in the beginning of the post....

well and thing taht i had the dremel in one hand and i was screaming CUT the shield nobody know.... jeje i little idiot...

one more time Thanks for your help and time
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 06, 2012, 08:05 pm
So no need for plan B - which is a good thing because from your findings it looks like the other link is correct -

boards with ZLH printed on them do not have PPM, older boards found inside the same receiver do have PPM.

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 06, 2012, 08:13 pm
Well in this days I will try to include RC to the puppet, I´ll tell you how get I on.
XD
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 09, 2012, 10:54 am
Hi,
I have a question again,becouse in am trying to include R/C in a big sketch that I am working.
I have some menus,and only in two option I want to use R/C contol.
So I need to activate and deactivate the interrupt but only this that come from the pins change
becouse I don´t need that the arduino hear all the time to the rc transeiver.

is this possible and how?

Thanks!!!!!!
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 09, 2012, 11:49 am
Hi,
   Two ways to do this

1) Have a mode variable and just ignore the RC Pulses when you don't need them

2) Detach the interrupts using void PCintPort::detachInterrupt(uint8_t arduinoPin)

In and ideal world option 2 would be your best choice, but in Arduino this is not a good choice - it uses the delete function to free the pin memory, this function is not properly supported on Arduino so every time you attach an detach pins a small amount of memory is used up that you sketch cannot use again until it is reset - technically its know as a memory leak.

Option 1 is easy to do and just means that you sketch will be about 1% less efficient.

A third option is to disable individual interrupt flags - but lets not get into that because 1) is easy and has so little impact on your sketch that you will not notice.

so wrap the code in something like this -

Code: [Select]

if(gMode == RC_CONTROL)
{
  read channels
 
  update channels
}


this way the RC Code will only be processed when your sketch sets gMode to RC_CONTROL

Duane B

rcarduino.blogspot.com (http://rcarduino.blogspot.com)


Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 09, 2012, 12:57 pm
So, if i have understand you well, for use mode variable, the gMode is a variable that I must declare before setup or is something that  I can use becouse the library have it.
And when I use if stament I understand that I am allowing to read and copy, but when I am out the flags from rc control will change but the arduino don´t go becouse gMode != RC_CONTROL but Will I need to change gMode to oder value in the code,not? which value/state is this??
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 09, 2012, 01:36 pm
You have the idea mostly right.

You mentioned that you have a menu and in two menu options you want RC Control - you could represent each of your menu options as a mode - MODE_MANUAL, MODE_RC_NORMAL, MODE_RC_XXX etc

Then you can have a 'switch case' statement inside loop which does different things depending on the value of gMode -

Code: [Select]

switch(gMode)
{
case MODE_MANUAL:
  // put your manual control code here
break;
case MODE_RC_NORMAL:
  // put your manual control code here
break;
case MODE_RC_XXX:
  // put your manual control code here
break;
}


If you modes are very different, one way that I have done this in the past is to have the code I want for each mode in a separate function -

Code: [Select]
switch(gMode)
{
case MODE_MANUAL:
  doModeManual();
  break;
case MODE_RC_NORMAL:
  doModeRCNormal();
break;
case MODE_RC_XXX:
doModeRCXXX();
break;
// etc etc etc
}


This might also help - http://www.arduino.cc/en/Reference/SwitchCase (http://www.arduino.cc/en/Reference/SwitchCase)

Duane B

rcarduino.blogspot.com (http://rcarduino.blogspot.com)
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 09, 2012, 02:59 pm
Yes,i have use switch/case stament for built the menus, and the thing is gMode tath is a variable that i don´t need to define becouse is created by library which values can take( mode_manual,mode_rc,rc_control....)

do you know what I mean?? where can I see the values that i can espect from gMode or i need to define the variable gmode and decide whitch values will contain... and in this case witch kind of variables are this?
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 09, 2012, 03:16 pm
Hi,
gMode was just a suggestion, its not in the library ,if you already have a switch/case set up with your modes, add the RC Code to the modes you need it in and leave it out of the others, thats enough to achieve what you want.

Duane B


Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 09, 2012, 03:54 pm
sorry I am not understanding well, what kind of variable will be gMode(int,boolean...)?
becouse I am understanding that will be one that I can define the spected values (RC_MODE,NO_RC_MODE)

Thanks!!!
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 09, 2012, 04:24 pm
Hi,
   Can you PM me your sketch so that I can make a suggestion based your current structure ?

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 10, 2012, 11:42 am
Good morning,
the sketch have 49 pages of code,i was looking in github and google proyect for upload there but it was a little dificult for me( i supposo that it will be easy like a dropbox or something like this....)
if you sendme one email to alehop@mononokeproducciones.com I´ll send you the .pde code.
i am using in this code:

1 arduino Mega 2560
1 4x3 matrix keypad
1 lcd
1 sd21 servo controller
3 thumb joystick (6 potentiometers)
8 buttoms
1 udrive microSDcard (2gb uSD card)
1 RGB led

and now I am changuin to only 1 thumb joystick and 5 buttoms and 6 chanels r/c control.

the structure is:

one menu with 3 posibilities:

PLAY
REC
Config

and inside of this posibilities you have more posibilioties:

Play:

play from memory,
play from the joysticks
and now i want to add here another posibility from RC

Record:

record move  (here I need to add the rc control too)
record a secuence of pre recorder movement
erase movement
erase secuence

config:
Format sd card
calibrate joystick
---------------------------------------------------------------------------------------------

I explain all this becouse went I send you the code you will see that is uncoment, only have comment for me and in spanish...
When I finnish I want to document it in a blog but now... is a little unreadable... sorry

For this reason I only need that arduino hear the RC control in two moments.what i am thinkin is the gMode variable for me only have two posibilities so it is a boolean variable,but how can i create one tath have more posibilities(Manual,RC1,RC",RC)

thanks for your interest!!!!!
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 12, 2012, 12:11 pm
Hi,
This weekend I was studying the diference between a class,a structure,and another posibility that is only define a int variable(gMode), and define no_RC =0;RC1=1;RC2=2.....;
and I could use Mode names.
But the thing is allways the calc rutine will be stopping for do the micro second pulse count independently if this is needed or not, so I would try to implement all together and see what happend if I have problems I should try to use detachInterrupt;and see how many times I can use before arduino´s memory is full,and when this happend make a reset.
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 12, 2012, 01:17 pm
A better approach is to disable the interrupts at a hardware level.

I have been busy getting two blog posts and videos out this weekend but will get to modes and switching the signal source in a day or two.

I will suggest the ability to temporarily enable and disable interrupts on specific pins to the pin change int guys, if they are not keen i will add it as n externala helper class.

Duane B
Title: Re: Problems with R/C 6ch transmission
Post by: Carlos mononoke on Nov 12, 2012, 06:05 pm
When you say disable the interrupt at a hardware level, you mean that power off the transmitter no?? only when you are inside of the rc_mode power on.

Duane I want to understand better how to work with class, do you recomend me some thing for read or see??? becouse I was reading the book beguining with processing but i think the classes in arduino are a little bit diferent.

thanks!!!!
Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 12, 2012, 06:21 pm
Hi, no transistors, the arduino has a set of registers which enable or disable each pin for generating pin change interrupts. If you disable the interrupt at this level you can leave interrupts attached and disable specific pins until you need them. You can then enable/disable as often as you want with no overhead when they are not in use and no memory leaks from attach/detach

Im in Ethiopia today so no time to dig out the register names.

Duane B

Title: Re: Problems with R/C 6ch transmission
Post by: DuaneB on Nov 14, 2012, 07:48 am
Hi,

Here is a link to the thread where we have been disussing the problem with using detach in pinchangeint. As you can see greygnome has confirmed the issue and is planning to add support for the enable/disable mechanism i suggested as a fix.

http://arduino.cc/forum/index.php/topic,87195.0.html (http://arduino.cc/forum/index.php/topic,87195.0.html)

Duane B

rcarduino.blogspot.com (http://rcarduino.blogspot.com)