Demo ?

Duane B

rcarduino.blogspot.com

This project does something similar, It has an IR Transmitter fitted and the Arduino looks for the presence of the IR to count a lap, you want to look for the abscense of the IR to indicate a person, but the principle is the same -

http://rcarduino.blogspot.ae/2012/01/can-i-control-more-than-x-servos-with.html

Duane B

rcarduino.blogspot.com

You do not want to use the software servo library, at one time the standard servo library that comes with Arduino was limited to a small number of servos, but for years now it has been able to support 12, it is very well known, very well supported and very reliable. Best of all the standard library does not require you to call refersh every 50ms.

Here is an example you can use right now that drives 12 servos with the standard library -

http://rcarduino.blogspot.ae/2012/01/can-i-control-more-than-x-servos-with.html

Duane B

rcarduino.blogspot.com

Yes, most servos are designed to work with the standard RC Pulse range of 1000 to 2000 microseconds as provided by the Arduino Servo library - I assume that you mean the standard Arduino Servo library when you refer to 'Software Servo' ?

Duane B

rcarduino.blogspot.com

8 Channel RC Reading/writing/loopback code now up here -

http://rcarduino.blogspot.ae/2013/04/reading-rc-channels-with-arduino-due.html

Duane B

rcarduino.blogspot.com

Hi,
   Thanks Stimmer for your work on the confirmation and resolution.

Duane B

rcarduino.blogspot.com

Hi,
   It looks as if the error comes from a combination of interrupts and the way in which micros is implemented, you can find more information and a suggested fix to the Due cores here -

http://arduino.cc/forum/index.php/topic,162787.0.html

Try the code in the post above with the fix to the micros function and let us know how you get on by posting in the topic linked above

Once you have this fix in place, the 4 channel code should also be fine

Duane B

rcarduino.blogspot.com

As far as i know timer capture only works on the single timer capture pin - great for a single wheel, not much use for four wheels though.

Duane B

rcarduino.blogspot.com

Hi,
   The following sketch reproduces a bug whereby interrupts are reporting the time as measured using micros to be either 1,000 micros too soon or 1,000 micros too late.

The code is a lightly modified version of a pattern used man times to measure RC Channels on the AVR Platforms. I have stripped the sketch down, changed the data types and added some additional tracking variables to assist with debug.

The sketch implements a loop back where a servo signal is output on pin 8 and read back in on pin 2. Over a period of time, the signal read back in will alternate between periods of being correct, 1,000 micros too short and 1,000 micros too long, each of these conditions can be seen repeatedly for short periods while the sketch is running - sample output below -
The columns are

Pulse Width, start time in micros, end time in micros, pulse width, Time since last rising edge, time since last falling edge

Code:

1102 12823887 12824989 1102 20001 20002
1102 12843888 12844990 1102 20001 20001
1102 12863889 12864991 1102 20001 20001
1102 12883890 12884992 1102 20001 20001
1102 12903891 12904993 1102 20001 20001
1102 12923892 12924994 1102 20001 20001
1101 12943894 12944995 1101 20002 20001
1102 12963895 12964997 1102 20001 20002
1102 12983896 12984998 1102 20001 20001
1102 13003897 13004999 1102 20001 20001
102 13023898 13024000 102 20001 19001    // we lost 1,000 micros on the falling edge here ?
102 13043899 13044001 102 20001 20001
102 13063900 13064002 102 20001 20001
101 13083902 13084003 101 20002 20001
102 13103903 13104005 102 20001 20002
102 13123904 13124006 102 20001 20001
102 13143905 13144007 102 20001 20001
102 13163906 13164008 102 20001 20001
102 13183907 13184009 102 20001 20001
102 13203908 13204010 102 20001 20001
101 13223910 13224011 101 20002 20001
102 13243911 13244013 102 20001 20002
102 13263912 13264014 102 20001 20001
1102 13283913 13285015 1102 20001 21001 // we gained 1,000 micros on the rising edge here ?
1102 13303914 13305016 1102 20001 20001
1102 13323915 13325017 1102 20001 20001

This pattern continues with the measured pulse being reported as 100,1000 or 2000

Anyone seen something similar with interrupts or micros ?

Loop back test code -

Code:

//
// rcarduino.blogspot.com
//
// A simple approach for reading RC Channels using 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 "Servo.h"

// Assign your channel in pins
#define THROTTLE_IN_PIN 2

// Assign your channel out pins
#define THROTTLE_OUT_PIN 8

// 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;

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

// holds the update flags defined above
volatile uint32_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 uint32_t ulThrottleStartShared;
volatile uint32_t ulThrottleEndShared;
volatile uint32_t ulThrottleInShared;

void setup()
{
  Serial.begin(115200);
 
  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);

  // using the PinChangeInt library, attach the interrupts
  // used to read the channels
  attachInterrupt(THROTTLE_IN_PIN, calcThrottle,CHANGE);

  // for loop back test only, lets set each channel to a known value
  servoThrottle.writeMicroseconds(1500);
}

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 uint32_t ulThrottleIn;
  static uint32_t ulThrottleStart;
  static uint32_t ulThrottleEnd;

  // local copy of update flags
  static uint32_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)
    {
      ulThrottleIn = ulThrottleInShared;
      ulThrottleStart = ulThrottleStartShared;
      ulThrottleEnd = ulThrottleEndShared;
    }

    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

  if(bUpdateFlags & THROTTLE_FLAG)
  {
    Serial.print(ulThrottleIn);
    Serial.print(",");
    Serial.print(ulThrottleStart);
    Serial.print(",");
    Serial.println(ulThrottleEnd);
  }
  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))
  {
    ulThrottleStartShared = 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.
    ulThrottleEndShared = micros();
    ulThrottleInShared = ulThrottleEndShared - ulThrottleStartShared;
    // use set the throttle flag to indicate that a new throttle signal has been received
    bUpdateFlagsShared |= THROTTLE_FLAG;
  }
}

Duane B



rcarduino.blogspot.com

Hi,
    I have managed to replicate the situation -

Expected results -
1304 1402 0 1102 1600 1195
1304 1402 0 1102 1600 1195
1304 1402 0 1102 1599 1195
1304 1401 0 1102 1599 1194
1304 1401 0 1102 1599 1194
1305 1401 0 1102 1599 1194

At this point the final channel looses 1000 us

1305 1401 0 1101 1599 194
1305 1402 0 1101 1599 194
1304 1402 0 1101 1599 194
1304 1402 0 1101 1600 194

which soon turns up on the first channel

2304 1402 0 1102 1600 194
2304 1402 0 1102 1600 195
2304 1402 0 1102 1600 195
2304 1402 0 1102 1600 195
2304 1402 0 1102 1599 195

Finally everything gets back in synch

1304 1402 0 1101 1600 1194
1304 1402 0 1102 1600 1195
1304 1402 0 1102 1600 1195
1304 1402 0 1102 1599 1195

Having used the same code pattern extensively I am wondering if this might be an internal error in the way that Arduino Due interrupts are implemented, its very similar to a synchronisation problem I have had in the past when multiplexing RC Channels into fewer pins (i.e. six channels read through two pins) the problem seems to effect adjacent channels i.e. 1 and 2 or 6 and 1 (wrap around) never 2 and 4.

The test code is here for anyone else that wants to try, its a simple loop back where a servo output is fed back in as a channel input.

http://rcarduino.blogspot.ae/2013/04/reading-rc-channels-with-arduino-due.html

I will continue to look into this tonight.

Duane B

rcarduino.blogspot.com

Chaps,

My wheels are turning at around 80 RPM, with two transitions/interrupts per revolution on each of the four wheels.

I would not bother with conversions to frequency, it doesn't tell you anything, the ratio between the wheel speeds will be the same in the time domain as it is in the frequency domain so the conversion is pointless.

I have used a schmitt trigger to condition the signal, it has introduced problems of its own, a simple comparitor would have been a better idea for converting the sensor output into a hard 0 or 5. I also added indicator LEDs on the outputs of the schmitt trigger for hardware debugging i.e. I can see what is being sent into the Arduino.

Lots more to tell about this project, will try to get my act together and write it up this weekend.

Duane B

rcarduino.blogspot.com

Hi,
    I have just put together a loop back sketch which simply outputs six servos and reads them back in again as if they are RC Channels.

    Right now it uses pinChangeInt on the Arduino UNO. I will convert it for Due this evening, in the meantime if you want to have a go at converting it you can find the post here -

http://rcarduino.blogspot.ae/2013/04/problem-reading-rc-channels-rcarduino.html

Duane B

rcarduino.blogspot.com

Hi,

I have a traction control system running at the moment, I was planning to publish it this weekend or next weekend. Its coarse grained with only 1 interrupt per revolution, I would like to try it with four per revolution, but not more, the code could handle it, but i dont trust the sensors.

Try using a lower number of transistion on your encoder, basically give the sensors larger light/dark areas to work with and also turn out the lights to make sure its not environmental interference.

Duane B
rcarduino.blogspot.com

Now that you have the code, and for anyone else that wants to try it, I would suggest the following -

Code:

// uOutput will have 10 bit resolution - the sum of 4 8 bit channels.
// The channels assume 127 is the mid or zero point
// 4*127 = 508, so we use this as the mid point of our output
uint16_t uOutput = 508+(((m_Voices[0].getSample(bUpdateEnvelope,bApplyEnvelopePitchModulation) + m_Voices[1].getSample(bUpdateEnvelope,bApplyEnvelopePitchModulation))
  +(m_Voices[2].getSample(bUpdateEnvelope,bApplyEnvelopePitchModulation) + m_Voices[3].getSample(bUpdateEnvelope,bApplyEnvelopePitchModulation))));

// scale up to 16bit
uOutput <<= 6;

// split for 2-Byte PWM here and use OCR0A and OCR0B as the outputs
...

Duane B

rcarduino.blogspot.com

And the link I posted is not a guide to anything at all but rather a link to the OPs recent posts, bar sport indeed.

Duane B