experience welcome

Reference this thread, It’s gone off topic, so I figure I can continue here. I’ll gladly take any advise on structure, design, ect.

Example of what I built before:

Video: http://magnethead794.com/AIRT/images/robot124.avi (keep in mind that’s 30 pounds going up a 22 degree smooth surface)

The version 2 that I planned to build, until college occured, and I want to revive via arduino, just not as complex, and not with the huge body on it…

axle design: http://magnethead794.com/AIRT2/images/robot141.jpg

CAD rendering: http://magnethead794.com/AIRT2/images/robot129.jpg

here is the visually simplified platform:

So, if I were to link two Uno’s over I2C, and think big picture. The thought is, that the master should contain all the devices neccesary for the driving and autopilot, while the slave should have the peripherals. What this allows, that the boards only talk during the autopilot, in which case I just send the slave a simple signal, which runs the autopilot function on the slave drive for the peripherals.

Now, I know somebody will tell me to go to a Mega. But my question with the mega, is does it have the same PulseIn CPU usage (30% per pin) as the Uno? If so, it makes more sense to me to use more Uno’s and split the reading between two processors.

That said, given the layout below, I have 5 ping sensors and 3 PWM Rx inputs. On the ping sensors, the fronts only get polled moving forward, and the backs only get polled moving backwards, and they’re only used during autopilot, which means it’s not listening for Rx CH1 or 2. Thus,

Parts list:

2 motors- $60 (http://www.robotshop.com/lynxmotion-...ead-motor.html)
12 feet of track- $150 (http://www.robotshop.com/lynxmotion-track-trk-01.html)
2 sets 9 tooth sprockets- $20 (http://www.robotshop.com/lynxmotion-...t-9-tooth.html)
10 sets of 6 tooth idlers- $80 (http://www.robotshop.com/lynxmotion-...t-6-tooth.html)
6 sets of 6mm hubs- $48 (http://www.robotshop.com/lynxmotion-...ersal-hub.html)
Arduido basic kit- $40 (http://www.robotshop.com/robotshop-a...sic-kit-7.html)

Total Cost: $772

is does it have the same PulseIn CPU usage (30% per pin) as the Uno?

Can you explain what you mean by that? pulseIn is a blocking function, but maybe with a little thought or external hardware you could get this perceived overhead down.

AWOL:

is does it have the same PulseIn CPU usage (30% per pin) as the Uno?

Can you explain what you mean by that? pulseIn is a blocking function, but maybe with a little thought or external hardware you could get this perceived overhead down.

Going off of this:

http://diydrones.com/profiles/blog/show?id=705844:BlogPost:38418

In Arduino, you read RC signals by using the PulseIn command, and you drive servos with the servo.write function added by the servo library. The problem is that PulseIn waits for the next pulse, and the more channels you're reading the more time your CPU is spent waiting. A good rule of thumb is that each PulseIn, without modification, takes about 30% of your CPU time, so you can see that about two channels is the max.

In Arduino, you read RC signals by using the PulseIn command

Sounds a bit prescriptive to me. There are other ways of doing it.

This is all new to me (I started researching Saturday), I've done plenty of RF controller bots, but now implementing autopilot, I'm trying to learn everything as soon as I can. What other ways could I read the servo-out PWM from the RC receiver?

An R/C receiver doesn't have a PWM output, it has a PPM output. Best to get that one straight as soon as possible, or you might start imagining you could use analogWrite to control your servos. I haven't done it for a while, but I tapped the point in the receiver between the RF and the decoder where the PPM stream was intact, and used interrupts and timers. You could probably do the same with the servo outputs and some diodes onto a single pin, assuming the outputs are not retimed and synchronised by the receiver, and the pulses remain consecutive.

I can't see an issue driving servos, they have their own library of servo.write(). And the motor controllers I'm choosing are PWM, which would be analogWrite. It's just the reading part that I can't say I'm 100% positive about. The RF receiver is a Hitec RCD3500. I'd prefer using the servo outputs, as I use the same receiver in all of my projects.

Not so sure I understand the diode method, as everything I see on google for "arduino read rc receiver" is using pulsein or the PPM.

http://scottrharris.blogspot.com/2010/01/reading-servo-pwm-with-arduino.html

http://forum.sparkfun.com/viewtopic.php?p=81679

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1220617779

http://www.diydrones.com/profiles/blogs/reading-pwm-from-a-receiver

http://diydrones.com/profiles/blog/show?id=705844:BlogPost:38418

Assuming the receiver outputs are sequential, you could diode-OR the R/C receiver outputs onto a single pin. Servo outputs from the receiver are normally active high, so you set your interrupt for a rising edge, then in the ISR, note the time and swap the interrupt condition to the falling edge. Rinse and repeat.

AWOL: Assuming the receiver outputs are sequential, you could diode-OR the R/C receiver outputs onto a single pin. Servo outputs from the receiver are normally active high, so you set your interrupt for a rising edge, then in the ISR, note the time and swap the interrupt condition to the falling edge. Rinse and repeat.

Is there a laymens for that, please?

I found these-

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1283093971 - somewhat helpful

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1282856325/all - more helpful (the more diagrams, the better)

http://forum.pololu.com/viewtopic.php?f=2&t=2513 - most helpful....

Is there a simple laymens way to describe this? And how do I know if my Rx transmits serially?

So the code listens for channel one, and either does it's command, or if blank, skips to channel 2, and so on? But it still uses PulseIn, I thought the whoile point was doing ti without PulseIn?

And how do I know if my Rx transmits serially?

Simplest way would be a two channel scope. Failing that, a bit of simple software on your Arduino.

The Pololu link looks about the most sensible.

AWOL:

And how do I know if my Rx transmits serially?

Simplest way would be a two channel scope. Failing that, a bit of simple software on your Arduino.

The Pololu link looks about the most sensible.

Didn't I see a link somewhere for a scope that runs from the mic jack on a computer?

I did- http://www.zelscope.com/faq.html but has volt limitations.

So theorietically, once I get my arduino, I should be able to set up the system shown on the pololu forum, and have a test bed?

also, again I ask, this method still uses PulseIn. What is the difference between using PulseIn on a single pin with diodes vs using it on separate pins?

I haven't got any R/C gear here with me, or an Arduino for that matter. The Pololu software looks incomplete to me (I don't see how it re-syncs with the PPM stream) but it looks to be a start. Obviously, you'll have to replace the pulseIn with interrupt code, if that's what you want to do. I haven't done this on an Arduino (last time I did it, it was a Z80), but I don't see why it shouldn't be feasible.

Also, how would I manipulate other channels this way? IE, I only want the left/right joystick axises to function if the up/down axis are zero, as a lockout.

If I had to replace the PulseIns with interrupts, wouldn't it just be easier to read the pulse off the 2 drive channels + camera servo channel, and have the rest operate as digital? Or am I missing an integral part here?

Additionally, since I'm going to have several PWM devices (ie, the 4 ping sensors) attached, how would I read the PWM off of those in a more efficient manner than PulseIn? The example file uses PulseIn, but when I'm dealing with 4 sensors....

The initial thought was to only measure the 2 relevant to the direction of travel?

The Pololu software looks incomplete to me (I don't see how it re-syncs with the PPM stream) but it looks to be a start.

Scrub that - it uses two pins, one for Ch1 (to detect the start of the train) and the other for the ORed pulses.

AWOL:

The Pololu software looks incomplete to me (I don't see how it re-syncs with the PPM stream) but it looks to be a start.

Scrub that - it uses two pins, one for Ch1 (to detect the start of the train) and the other for the ORed pulses.

So would this be accurate?

That's a slightly counter-intuitive diagram, but I think it looks OK.

AWOL: That's a slightly counter-intuitive diagram, but I think it looks OK.

How do you mean? I don't understand board diagrams too well, as was provided with the pololu thread (mostly because I can't see the traces very well). Also, it's nearing 5AM here in texas, so my mind is a bit cloudy at best.

How would I manipulate other channels this way? IE, I only want the left/right joystick axises to function if the up/down axis are zero, as a lockout.

If I had to replace the PulseIns with interrupts, wouldn't it just be easier to read the pulse off the 2 drive channels + camera servo channel, and have the rest operate as digital? Or am I missing an integral part here? Since I'm going to have several PWM devices (ie, the 4 ping sensors) attached, how would I read the PWM off of those in a more efficient manner than PulseIn? The example file uses PulseIn, but when I'm dealing with 4 sensors....

The initial thought was to only measure the 2 relevant to the direction of travel?

and have the rest operate as digital?

PPM R/C used to be known as "digital proportional" - there will [u]always[/u] be a pulse for [u]every[/u] channel in every frame, only the width will change, so you'd have to discriminate pulse widths to decide what is "on" and what is "off"

The example file uses PulseIn, but when I'm dealing with 4 sensors....

What sort of sensor?

AWOL:

and have the rest operate as digital?

PPM R/C used to be known as "digital proportional" - there will [u]always[/u] be a pulse for [u]every[/u] channel in every frame, only the width will change, so you'd have to discriminate pulse widths to decide what is "on" and what is "off"

Thank you for that warning. Yes, it is a digital proportional radio. So now this is starting to make more sense. (As i mentioned, it's 5AM here in Texas, so my brain is a bit foggy at the moment)

So with that diagram, it is ORing the inputs, using channel 1 as the start sequence.

Are the shift values proprietary to the radio reciever in question, or can the values in the provided code be held true? Or is it a test, change, retest method?

the digitalRead on Pin2, is used to determine what, exactly? There is only an "if", not an else- so what would happen if pin2 were high when the code was executed- nothing? It sets puls high through declaration, so that has me confused.

Since the sample code uses PulseIn, does it still pull the ~30% CPU load?

The NOP is used to declare if no signal is found, correct? So the sample 2000 and 3000 values are used to neutralize that output, I'm guessing? But I thought the output was between 1 and 2 ms?

Excuse the volume of questions, but as I said, I'm trying to learn as much as possible, as soon as possible, so I can be ready to go when I take delivery of the parts and equipment.

The PWM's I will be reading will be ping sensors. The example code uses PulseIn. If the 30% rule is true, then how would it be possible to read from 2, if not 4, ping sensors, while still listening to the RC reciever, which also uses a PulseIn?

Example code for reading the dioded signal, for reference:

    //Channel 1 = analogpin2
    //Channelsum(1234)=analogpin7

    byte Rx1 = 2; // pin Receiver CH1
    byte Rxin = 7; //pin Reiceiver CH 1234
    byte puls= HIGH; //puls Rx CH1
    int Rxon= 0; // RX Failsafe
    int PPM1 = 0; //Length signal CH1
    int PPM2 = 0; //Length signal CH2
    int PPM3 = 0; //Length signal CH3
    int PPM4 = 0; //Length signal CH4
    int NOP = 0;   //Pulse detect
    #define shift1 54 // Time shift center CH1
    #define shift2 -160 // Time shift center CH2
    #define shift3 15 // Time shift center CH3
    #define shift4 20 // Time shift center CH4

    void setup()
    {
      pinMode(Rx1,INPUT); //set pin as input
      pinMode(Rxin,INPUT); //set pin as input
      Serial.begin(57600); // set up Serial at 57600 bps
    }

    void loop() {

    puls=digitalRead(Rx1); //read level of Rx1
    if (puls==LOW) { //if level is low, read all PPM)
        PPM1=pulseIn(Rxin,HIGH); // read PPM CH1
        PPM2=pulseIn(Rxin,HIGH); // read PPM CH2
        PPM3=pulseIn(Rxin,HIGH); // read PPM CH3
        PPM4=pulseIn(Rxin,HIGH); // read PPM CH4
        puls=HIGH; //set variable CH1 detect
        NOP=PPM1;
    }
    if (NOP==0) { // Failsafe /no PPM detect
        PPM1=3000; // set value CH1
        PPM2=2000; // set value CH2 Motor
        PPM3=3000; // set value CH3
        PPM4=3000; // set value CH4
    }
    else {                       //double PPM and adjust
       PPM1=(PPM1+PPM1+shift1);
       PPM2=(PPM2+PPM2+shift2);
       PPM3=(PPM3+PPM3+shift4);
       PPM4=(PPM4+PPM4+shift4);
       }   
    Serial.print(" CH Seite= ");
    Serial.print(PPM1);
    Serial.print(" CH Motor= ");
    Serial.print(PPM2);
    Serial.print(" CH Quer= ");
    Serial.print(PPM3);
    Serial.print(" CH Hoch= ");
    Serial.println(PPM4);
    }