Starting my first UGV project - need some starting help

TiboJ:
I'll use 2.4Ghz for controlling the UGV, because FM radio controlling can get disturbed by other radio signals, and that is not the problem with 2.4Ghz.

Do you really expect this to be a problem out in the woods? I mean, at a landing field with multiple R/C planes, I could see the issue, but out in the middle of nowhere (unless these "woods" are closer to a population center than I am imagining?) I would think there would be little issue (not too mention the fact that this is a ground-based vehicle, so interference wouldn't likely cause destruction of the machine). Regardless, FM is pretty much phased out for most uses, from what I've gathered (over the weekend I found a 72 MHz FM aircraft transmitter at Goodwill for $15.00 USD; I'm in the process of getting a receiver and crystal off Ebay to try it out; it seems like FM radios are almost dirt cheap on the used market as everybody flocks to 2.4 GHz SS).

TiboJ:
I'm going to make a summary of everything I know right now, and then see how I will put it all together.

Good plan.

TiboJ:
I've read that I can't use 2.4Ghz on my camera receiver if I'm already using 2.4Ghz for the UGV receiver, I think that isn't true, because 2.4Ghz signals can't get disturbed, as I mentioned above?

TBH, I don't know; I've often wondered this myself. I would think it wouldn't be much of an issue if the R/C equipment is spread-spectrum (and I think they all are); that R/C kit would be hopping all over the place - if anything was to experience issues, it would be the video. Even so, it's a good question, and something to definitely research.

Do you really expect this to be a problem out in the woods? I mean, at a landing field with multiple R/C planes, I could see the issue, but out in the middle of nowhere (unless these "woods" are closer to a population center than I am imagining?

Yes, some airsoft terrains are close to population, and it's possible that someone uses a radio controlled UAV (mostly in milsim). :slight_smile:
I just want to eliminate the risk of it being disturbed.

Even so, it's a good question, and something to definitely research.

Will do that.

Hi,

Lots about interfacing RC equipment to Arduino on my blog including a comparison of signal performance from a 2.4ghz system and older 27mhz am system -

Duane B

DuaneB:
Hi,

Lots about interfacing RC equipment to Arduino on my blog including a comparison of signal performance from a 2.4ghz system and older 27mhz am system -

Rcarduino.blogspot.com

Duane B

Nice blog! I've read some articles, and the 2.4Ghz is obviously the best.

Okay, I've took the time to think about everything, and this is how it will work:

TX > 2.4Ghz > RX > cable > WP controller > Serial cable > Arduino

I'm not going to use a servo controller, as I can control servo's with Arduino, via the Servo library.

Now I have a few more questions:

  • I've read the following about the WP controller: The default pins for RC mode are D0 and D1. As these are also the serial communications pins used for programming. You must disconnect cables connected to these pins when uploading a new program or usinging the serial port for diagnostics.
    So I can't upload sketches with a USB?
    I've read it here: http://sites.google.com/site/daguproducts/home/tutorials/understanding-wild-thumper

  • With the software serial, is it possible to use any digital pin on the Arduino for serial communication?

  • The receiver will be connected to the WP controller RC pins. If the receiver is connected to the RC pins(D0 and D1) on the WP controller, will everything we talked about be possible(use channels for spotlights, etc...)?
    I'm not going to connect the receiver to the Arduino, but first to the WP controller.
    This is what I mean:

  • With the software serial, is it possible to use any digital pin on the Arduino for serial communication?

Any pins except the hardware serial pins.

Thanks for the answer!

I've add one more question in my post before the answer of PaulS

TiboJ:

  • I've read the following about the WP controller: The default pins for RC mode are D0 and D1. As these are also the serial communications pins used for programming. You must disconnect cables connected to these pins when uploading a new program or usinging the serial port for diagnostics.
    So I can't upload sketches with a USB?
    I've read it here: http://sites.google.com/site/daguproducts/home/tutorials/understanding-wild-thumper

That reads, and I quote:

Control and Communications:
The default settings in the sample code allow the controller to be controlled using a standard RC receiver. In this mode pulsewidths from the receiver are measured and converted to speed and direction for the two motors. The default pins for RC mode are D0 and D1. As these are also the serial communications pins used for programming. You must disconnect cables connected to these pins when uploading a new program or usinging the serial port for diagnostics. If you have spare I/O pins then you can redefine "RCleft" and "RCright" in the "IOpins.h" tab of the sample code. Other servos can be plugged directly into the RC receiver to create a fully radio controlled robot.

So - number one - if you want to hook that board up to your receiver as it is intended to be used (ie, pins 0 and 1 to the receiver), then in order to upload your own sketches to it via it's on-board USB port, you will have to disconnect the RC receiver from those pins -before- you do so. What this means is that you can't use the USB port -and- have the RC receiver connected at the same time. The main reasons for this is: If the receiver is on, you would likely get garbage sent to the bootloader when you tried to upload your sketch; furthermore (and more likely), you might damage your RC receiver when you uploaded a sketch because you would be driving the receiver's -outputs- with the HIGH/LOW signals from the serial converter, which would be a bad thing.

This is pretty standard fare whenever you code on the Arduino; if you need those extra two pins, you can use them, but you can't use the USB if you have something connected to them.

So - for the WildThumper board, what do you do if you want to use USB -and- use the RC receiver? Move the receiver pins to other pins! Note in the quote above, it reads:

If you have spare I/O pins then you can redefine "RCleft" and "RCright" in the "IOpins.h" tab of the sample code.

If you look in IOpins.h (I have it here open in front of me), you'll see that RCleft is defined as "0" (digital pin 0) and RCright is defined as "1" (digital pin 1); those are the two pins as currently defined. What you would need to do is instead use a couple of the "servo output" pins as "input" instead; you could either define outputs 0 and 1 for the inputs, or outputs 5 and 6, or some other combination (whatever you are comfortable with); just know that you can't use those headers on the WT board for servos any more, only for the R/C input (you could do you debugging this way, then switch it back later, too). So, for instance, IOPins.h could be modified like follows:

#define LmotorA             3  // Left  motor H bridge, input A
#define LmotorB            11  // Left  motor H bridge, input B
#define RmotorA             5  // Right motor H bridge, input A
#define RmotorB             6  // Right motor H bridge, input B

#define RCleft              2  // Taking over servo 0 for RC receiver input
#define RCright             4  // Taking over servo 1 for RC receiver input

//#define S0                  2  // Servo output 00 - NO LONGER AVAILABLE
//#define S1                  4  // Servo output 01 - NO LONGER AVAILABLE
#define S2                  7  // Servo output 02
#define S3                  8  // Servo output 03
#define S4                  9  // Servo output 04
#define S5                 10  // Servo output 05
#define S6                 12  // Servo output 06

#define A1                  1  // Analog input 01
#define A2                  2  // Analog input 02
#define A3                  3  // Analog input 03
#define A4                  4  // Analog input 04
#define A5                  5  // Analog input 05

#define Battery             0  // Analog input 00
#define RmotorC             6  // Analog input 06
#define LmotorC             7  // Analog input 07
#define Charger            13  // Low=ON High=OFF

...and that modification would now use servo pin 0 (digital pin 2) for RCleft and servo pin 1 (digital pin 4) for RCright, and you would connect your receiver to those pins instead. Does that make sense?

Thanks for clearing that up!
It is no problem for me to remove them when uploading a sketch.

Now I will have to think how I will code it all.

Now for exemple, I want to use a switch on my transmitter to put spotlights on, on the UGV.
Is this the right way to do it?:

TX switch on > RX receives signal that switch is on > cable goes from the switch channel on the RX to WP controller digital pin(set as input) > code on WP controller detects that the switch is high, and sends with serial communcation a command to the second Arduino to turn the spotlights on, that are connected, for exemple, on digital pin 5(on the second Arduino).

Am I thinking the right way about it?

TiboJ:
Thanks for clearing that up!
It is no problem for me to remove them when uploading a sketch.

You might also look into using compiler directives to selectively enable/disable the code as needed (so you can set this kind of thing up once, then only change one spot of code to put it into "dev mode" when you need to).

Now I will have to think how I will code it all.

TiboJ:
Now for exemple, I want to use a switch on my transmitter to put spotlights on, on the UGV.
Is this the right way to do it?:

TX switch on > RX receives signal that switch is on > cable goes from the switch channel on the RX to WP controller digital pin(set as input) > code on WP controller detects that the switch is high, and sends with serial communcation a command to the second Arduino to turn the spotlights on, that are connected, for exemple, on digital pin 5(on the second Arduino).

Am I thinking the right way about it?

That would work (also remember that the digital and analog outputs of the 168 on the WT board are available; think of them as extra pins to use as well, if you need them), but you need to also ask yourself a couple of questions about what you are controlling:

  1. Do I need programmatic control of this peripheral?
  2. Will I need to change the pin assignments for this peripheral?

Both of these kinda boil down to what you are planning on doing; IIRC, you noted that you wanted your robot to be "modular"; allowing you to swap out functions, etc; and this reason alone may be enough to keep things under programmatic "indirect" control as you have indicated. You could also have some kind of menu (as I alluded to before) where you would need this kind of programmatic control in the event that you have fewer channels than you do peripherals (especially if you are already thinking of some kind of HUD overlay on the video).

If, however, you don't need programmatic control of the peripheral (ie - you just want to turn something on or off; you don't care about being able to customize the brightness, the color, whether it is flashing or whatever) - then it might be best in that case to bypass the added complexity of code and hardware interfacing, and just go with some kind of "R/C relay interface" module (which are sold by most R/C hobby supply places). Just something to keep in mind as another possible option.

Okay, I'm happy that I'm thinking right about!
Thanks!

Now, I do not really understand what you mean with "indirect" control?
Can you explain that a little more, please?

You mean the following? :

For exemple, I have currently connected a robot arm on channel 1. I'm not happy with it anymore, and I want to put an Airsoft gun on channel 1.
Now, all I will have to do is go in the "menu"(that is displayed on a LCD), and select there to use channel 1 for an Airsoft gun, instead for a robot arm.

TiboJ:
Okay, I'm happy that I'm thinking right about!
Thanks!

Now, I do not really understand what you mean with "indirect" control?
Can you explain that a little more, please?

What I meant by indirect vs direct control is:

Indirect: RX -> WT Controller -> Arduino -> Servo
Direct: RX -> Servo

TiboJ:
You mean the following? :

For exemple, I have currently connected a robot arm on channel 1. I'm not happy with it anymore, and I want to put an Airsoft gun on channel 1.
Now, all I will have to do is go in the "menu"(that is displayed on a LCD), and select there to use channel 1 for an Airsoft gun, instead for a robot arm.

Yes, you could do that; that is also part of the "indirect" method, but what I was originally meaning was going from the receiver to the servo (or to an RC relay module - for a spotlight, for instance) as being a "direct" mode, whereas having the intermediate WildThumper/Arduino combo doing some pre-processing before sending the appropriate command to the servo as being an "indirect" mode.

Finally - you don't really need an LCD on the robot for your "changes", since you'll already have video; you just need a way to put text overlayed on top of the video signal. There are modules and shields that can do this very easily (for example, the Nootropic Design Video Experimenter shield - Video Experimenter: Arduino shield that lets you do all kinds of experiments with video). If you go that route, then your television, hmd or whatever you are using to view the video at your "base" can act as your display for menus and other data.

Okay, now I understand it.
Thank you!

Can that shield be used as a OSD overlay? I mean, if I use that shield with the Arduino, will I be able to connect GPS and other OSD stuff on it?

I'm now going to continue to make a summary of everything.

TiboJ:
Nice explanation!
I'll use 2.4Ghz for controlling the UGV, because FM radio controlling can get disturbed by other radio signals, and that is not the problem with 2.4Ghz.
I'm going to make a summary of everything I know right now, and then see how I will put it all together.

I've read that I can't use 2.4Ghz on my camera receiver if I'm already using 2.4Ghz for the UGV receiver, I think that isn't true, because 2.4Ghz signals can't get disturbed, as I mentioned above?

Just want to note: Higher frequency signals are more susceptible to physical interferences than lower frequency signals. By physical interferences, I am referring to things like trees. Since you have been talking about using this UGV in the woods, that should be taken into consideration. You will likely find the range of your 2.4Ghz systems are noticeably reduced or have lower reliability in those kinds of environments. Lightly wooded areas may be ok, but heavily wooded areas will have a significant impact on the range of your system. UAVs have the advantage of having essentially no physical obstructions impacting their range.

You may, in fact, find that a Wifi router/AP/bridge actually has better performance in these environments than an RC system, since these wifi devices have been designed to operate in environments with lots of physical obstructions (utilizing a technique known as beamforming). Since RC systems generally assume line of sight, they just aren't designed to operate optimally in highly obstructed environments.

Yes, I already read something about it.
Thanks for let me think about it!

I've a few questions:

  • How much will the range be recuced in a normal forest, with 2.4Ghz? Is it drastically?
  • What will be the range when using Wifi router/AP/bridge?

I really need a good range of about 500m in the woods.

I'd be surprised if you could get 500m (1640ft) in clear air, let alone in a forest, but I'm not an expert, so if anyone knows better, I'd be interested to hear.

dxw00d:
I'd be surprised if you could get 500m (1640ft) in clear air, let alone in a forest, but I'm not an expert, so if anyone knows better, I'd be interested to hear.

That would be no problem in clear air, as my RC airplanes have range of 1km+

If I use Nootropic Design Video Experimenter shield on my Arduino, will I be able to add GPS function to the Arduino?
I don't see a way to use a shield on top of the noobtropic shield. Are there other ways to add GPS? Modules?

Fair enough. That contradicts the results from googling 2.4ghz rc range, but like I said, I'm no expert. My Heli is on 35Mhz FM.

It also depends on transmitter and receiver.
So it can be less then 500m with some.