TiboJ

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:

- 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:

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:

Quote

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:

...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?

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

TiboJ

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).

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 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.

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

TiboJ

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.

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 - http://nootropicdesign.com/ve/index.html). 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.

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

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.

TiboJ

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?