Go Down

Topic: PPM input and sloppy/slow servo response (Read 2193 times) previous topic - next topic


Hi, I am playing with a self stabilizing radiocontrolled platform, and came across this great little snippet in this forum:  http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1290626864

It works great bu itself, but i had already built the controlling logic which reads accelerometer input and servo output, wich worked great until i added this code to my sketch.  Actually i removed all subroutines *doing* anything in the code and still with only the initialization remaining in the sketch the sloppyness ( really slow servo response - more than 5 sec to complete a servo turn)

Here is the initialization i am using:
Code: [Select]

//Create variables for 6 channels
int RXCH[6];
volatile int RXSG[6];
int RXOK[6];
int PWMSG[6];

void setup() {
  for (int thisReading = 0; thisReading < numReadings; thisReading++)
    readingsx[thisReading] = 0;
  //Assign PPM input pins. The receiver output pins are conected as below to non-PWM Digital connectors:
  //RXCH[1] = 4;  //Throttle
  //RXCH[2] = 6;  //Aile / Yaw
  //RXCH[3] = 5;  //Elev. / Pitch
  //RXCH[4] = 2;  //Rudd. / Roll
  //RXCH[5] = 7;  //Gear
  //RXCH[6] = 8;  //Aux / Flt Mode
  //for (int i = 1; i < 7; i++){
  //  pinMode(RXCH[i], INPUT); 
// } 

Now that i have torn most of my hair off,  do anyone have a clue what happens ?
Sorry for being a newb ... :-/



Did you remember to set "numReadings" to 6 before using it?

Did you declare "readingsx" as a 6-entry array before writing to it?

Hard to tell what's going wrong without seeing all of the code.
Send Bitcoin tips to: 1G2qoGwMRXx8az71DVP1E81jShxtbSh5Hp


Hi, Thanks for the post.

Yep, I actually did.  The complete unfinished code are here: http://putcode.com/review.php?id=340
As you see from line 099 i am only testing output of smoothed values to one servo at this point in development.

Excuse my oversimplified code though, i am not a programmer and some of the things i have done are probably done in an oversimlistic way...




Can I suggest that you review the other current thread on this subject


There is one major problem which I see in your approach, the function you are using 'pulseIn' waits for a complete pulse before returning. If you do this for each of the six channels in turn you are potentially missing 85% of the information coming from your controller. This is because you give on channel your full attention and ignore the other five for one pulse, the you give the next channel all your attention and ignore five, at any one time there are five channels of information which you are ignoring with this approach.

The approach used in the thread I have linked above uses interrupts, you can read up on these but basically its a mechanism that allows something outside to 'interrupt' your program. In your case you want each channel to interrupt your program when a new pulse occurs. In between pulses your program can so something useful like listen to the other channels or perform some calculation based on the information you are monitoring.

I would test the code in the other post and see what you input looks like, if your input is very jumpy and needs smoothing, there is possibly something wrong with your circuit rather than the code. Mine had this problem, again its covered in the other thread, the sample code is more or less the code I used to confirm the hardware problem.

Hope it helps


Read this
then watch this



RC recievers pulse outputs in succession, the decoders are simplistic, a 1 of10 counter and a gate after frame reset the counter is zeroed, and on the rising edge of the pwm multiplex it maps the data to a port, next rising edge maps to port +1 ect until the nth channel, at which point the next advance inhibits the 1 of 10. this is done to keep a 7 channel transmitter from wrapping around on a 5 channel reciever.

Go Up