Starting my first UGV project - need some starting help

TiboJ:
Good idea! I've also found a library for it:
http://arduino.cc/hu/Reference/SoftwareSerial

Yeah, that's pretty much the standard library for software serial (or is it the NewSoftwareSerial?) - there are actually several such libraries out there, and I really forget which is the "latest" that is "standard" (maybe somebody here can help me out?). I do know there are a few out there that claim to have this or that improvements over the standard library for certain tasks; you might take a look around.

The point of using a separate servo controller is so you can "offload" the work of controlling the servos to another controller. Note that this is -exactly- what the WildThumper is doing; in its case, the controller is an ATMega168 using the Arduino libraries (specifically the Servo library).

So - if you wanted to - you could easily build your own "custom" WildThumper-clone using the code they provide, your own Arduino, and your own motor controller for the DC motors.

TiboJ:
I'll take a look at this, and search for some tutorials/library's.

As I said above - the WildThumper does everything you need to do, it is just limited in memory; all of the code is published on the site (download it and read thru it - it is very basic and easy to understand, and commented well). The code already handles taking PPM input from the RC receiver, and decoding it for output to the motor driver.

TiboJ:
I think that is a limitation for me, the code is probably going to be big, so the 168 might have to less memory.

If you do as I suggest above (with attention paid to what I note below), you could (in theory) use a 644 or 1284-based Arduino (though you might have to build that yourself) or Mega 1280/2560 as the controller and have room to spare. Or, you could use a pair of 328-based Unos. Or even a single Uno; it is difficult to say what you need or what you can use, without knowing your complete specs of what you plan to do ultimately. For simple RC control, etc - a single Uno would suffice; you could probably even get the OSD stuff I was talking about working as well. But, adding other things like GPS or other peripherals will expand memory requirements, and you might find yourself running low with a 328.

TiboJ:
I'll think about it, and otherwise, there is an alternative:
Sabertooth 2X12 R/C regenerative dual motor driver

Should 2x12A be enough, as each motor requires 5.5A( 3 x 5.5A = 16.5A)?

That is, IIRC, just an h-bridge; it is unclear on the specs of the Thumper whether that 5.5A stall current is for the whole device, or per motor (there are 6 motors on that chassis, btw, not 3). If it is 5.5A per motor, then I would only consider using one h-bridge per set of motors (so you would need 3 of those sabertooth controllers). If it was in total (that is, 5.5A for all motors locked up, so 2.25 amps per each side), then the sabertooth would be extreme overkill, but you could use one. Unfortunately, that site does not give good enough information about the specs on the motors for the Thumper chassis to know what they mean (I would suggest emailing them for clarification and/or reading the manual for the chassis and/or motors).

Ah - reading on the controller page for the WildThumper controller indicates that indeed - it is 5.5A stall current for -EACH- motor; or 33A total for all motors stalled - so you could go with (at minimum) two sabertooth 2x12 controllers; one controlling 4 motors (two per side), the other controlling the remaining two - or use 3 sabertooths, one per pair of motors - or try to find a different suitable h-bridge to handle the motors (about 16.5A per side of 3 motors).

Of course, regardless of the above answer, you would have to build up your own "controller" as outlined before to control the h-bridge(s) involved (based on the WildThumper controller code).

To be honest, you would probably be better off sticking with the WildThumper controller, and using a separate Arduino for the extra peripheral stuff, communicating with it via the 168 on the WildThumper controller via software serial or I2C (or, have the serparate Arduino be the master, controlling the WildThumper using I2C or serial; your call).

As I said above - the WildThumper does everything you need to do, it is just limited in memory; all of the code is published on the site (download it and read thru it - it is very basic and easy to understand, and commented well). The code already handles taking PPM input from the RC receiver, and decoding it for output to the motor driver.

Nice!

it is difficult to say what you need or what you can use, without knowing your complete specs of what you plan to do ultimately. For simple RC control, etc - a single Uno would suffice; you could probably even get the OSD stuff I was talking about working as well. But, adding other things like GPS or other peripherals will expand memory requirements, and you might find yourself running low with a 328.

The UGV needs to be 'modular', so I can always remove or add accessories on it.
These are some accessories I'm thinking about:
-Video streaming
-Remote control Airsoft gun(for Airsoft games)
-Robot claw
-OSD overlay(with GPS)
-Spotlights
-...
So that will need some memory.

(there are 6 motors on that chassis, btw, not 3)

Indeed, but there are 3 motors on each side, and the sabretooth can handle 2x12A, so that means it can handle 12A on each side of the UGV?

Ah - reading on the controller page for the WildThumper controller indicates that indeed - it is 5.5A stall current for -EACH- motor; or 33A total for all motors stalled - so you could go with (at minimum) two sabertooth 2x12 controllers; one controlling 4 motors (two per side), the other controlling the remaining two - or use 3 sabertooths, one per pair of motors - or try to find a different suitable h-bridge to handle the motors (about 16.5A per side of 3 motors).

I'm not going to do that, that will be way to expensive cost, as 1 sabretooth is around $65.

To be honest, you would probably be better off sticking with the WildThumper controller, and using a separate Arduino for the extra peripheral stuff, communicating with it via the 168 on the WildThumper controller via software serial or I2C (or, have the serparate Arduino be the master, controlling the WildThumper using I2C or serial; your call).

I'll probably do it this way, altough I don't know much about using 2 arduino's, so I'll look up some information about it.
Again, I really appreciate your help!

TiboJ:
The UGV needs to be 'modular', so I can always remove or add accessories on it.
These are some accessories I'm thinking about:
-Video streaming

By "streaming" - what do you mean? You probably know you can't do this with an Arduino; but if you mean to use a wifi web cam or something, then there'd be no need to use an R/C transmitter; you could just control the robot/Arduino via wifi. If you intend to stick with an RC kit, then you probably want to use some kind of RF camera, with a transmitter on the robot. There's drawbacks and advantages for both methods, so keep them in mind (and think about what you intend to do, etc).

TiboJ:
-Remote control Airsoft gun(for Airsoft games)
-Robot claw
-OSD overlay(with GPS)
-Spotlights
-...
So that will need some memory.

All of these items are doable, certainly - but they require not only more memory, but more pins - so you need to keep that in mind; you may want to go with a Mega for both. Just realize that if you intend to use shields, they may not all work with a Mega (depends on their functionality) as shields (though if you mount them seperately and jumper them together, most should work ok, with appropriate code bashing, too).

TiboJ:
Indeed, but there are 3 motors on each side, and the sabretooth can handle 2x12A, so that means it can handle 12A on each side of the UGV?

Yes, but at 5.5A stall current per motor, that controller is way undersized for the task (since each side needs 16 amps).

TiboJ:
I'm not going to do that, that will be way to expensive cost, as 1 sabretooth is around $65.

Then you're going to have to find another option for the motor controller; sticking with the WT controller might be the best option, as it was designed for the chassis anyhow. Use a Mega to control it (so you also have expansion options in the future).

TiboJ:
I'll probably do it this way, altough I don't know much about using 2 arduino's, so I'll look up some information about it.

Well, the WT controller is already programmed to listen for another microcontroller (in this case, it would be your external Arduino), so you can just look at the code to see how it is using serial input to achieve this. On the Mega, there is already extra hardware serial ports, so you don't even need to use a software serial library (offhand, I am not sure how you control the extra hardware serial ports, but I am guessing it is fairly easy). You could modify the code on the WT controller to allow you to send commands over the serial connection to control the servos on the WT controller. You could also hook up servos and other things to your external Arduino (and control them with the Servo library). To read commands from the RC receiver, you just need to study how the WT controller is doing it for its motor control (very simple). Or - if you intend to use wifi control (say, with an ethernet shield or board, or via an modded WRT54G router, or something like that), you just need to parse the commands from the network and send appropriate command strings to the WT controller.

[/quote]

By "streaming" - what do you mean?

The camera will not be connected to an Arduino, but it will have his own circuit.
The only way it will be in touch with the Arduino is to remotely switch the camera on or off.
Also, the camera will have his own receiver and transmitter, like here is explained:
http://rcexplorer.se/Educational/FPV/FPV.html

you could just control the robot/Arduino via wifi

I assume I need a wifi connection to control the robot using wifi, and that isn't in the woods? And the range would be reduced very much.
So I'll stick with RC, as it got much more range.

All of these items are doable, certainly - but they require not only more memory, but more pins - so you need to keep that in mind; you may want to go with a Mega for both. Just realize that if you intend to use shields, they may not all work with a Mega (depends on their functionality) as shields (though if you mount them seperately and jumper them together, most should work ok, with appropriate code bashing, too).

Then it's probably a good idea to get an Mega. I'll take a look at this.

Well, the WT controller is already programmed to listen for another microcontroller (in this case, it would be your external Arduino), so you can just look at the code to see how it is using serial input to achieve this. On the Mega, there is already extra hardware serial ports, so you don't even need to use a software serial library (offhand, I am not sure how you control the extra hardware serial ports, but I am guessing it is fairly easy). You could modify the code on the WT controller to allow you to send commands over the serial connection to control the servos on the WT controller. You could also hook up servos and other things to your external Arduino (and control them with the Servo library). To read commands from the RC receiver, you just need to study how the WT controller is doing it for its motor control (very simple).

I also think this is going to be the best way. So I will take a look at code, and see how it does it all.

Thanks!

TiboJ:
The camera will not be connected to an Arduino, but it will have his own circuit.
The only way it will be in touch with the Arduino is to remotely switch the camera on or off.

Ok, understood.

TiboJ:
I assume I need a wifi connection to control the robot using wifi, and that isn't in the woods? And the range would be reduced very much.
So I'll stick with RC, as it got much more range.

Well, if you have the Arduino connected with the router in AP mode, and locked down to a specific mac address (that of your "remote station" - which could be a smartphone, a netbook, or a laptop), then that is really all you need. You could add WPA on top of that if you needed more security (and for even more security, an SSH tunnel on top of that).

As far as range is concerned, that might be an issue, but I would suspect that if it were, it would be the same for an R/C system (especially perhaps a 2.4 GHz spread spectrum radio), but then again, I don't really know. There are ways of boosting wifi as well (though some require a ham license); one way is to use a directional yagi antenna on the robot or the base station (sometimes both), and using GPS keep both pointed at each other. This is done for UAVs; I suppose it could work for a UGV as well (and I bet you could do it with an R/C radio, too; though an FM yagi I think will be a tad larger than a 2.4 GHz one - depending on what kind of radio kit you plan on using).

Personally, I would do some testing beforehand of each method (wifi, 2.4 GHz SS radio, and FM) in the environment you plan to be in (the woods), to see which is better or more suitable. Part of me thinks that the FM control system might be best, but that is just a guess that I wouldn't trust without testing.

TiboJ:
I also think this is going to be the best way. So I will take a look at code, and see how it does it all.

Like I said, the code is really basic and commented well; it should be easy to understand. You should be able to use it to easily implement the R/C control decoding, if that is the control route you decide to use. Note, IIRC, that some 2.4 GHz SS radios - probably the more expensive ones - can also send a 2-way stream of data between the remote controlled vehicle and the base station; this is commonly used for telemetry from the remote vehicle, such as GPS, heading, temperatures, battery monitoring, etc - something to keep in mind and look into. You could also do a one-way data send, if you wanted, using an FM setup, by controlling a channel to send out two different "positions", then reading and interpreting that on the Arduino-side on the vehicle (it would be a low data rate, but possibly useful). If you put a transmitter on the vehicle (at a different frequency and/or channel), you could then set up a two-way communication path.

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?

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.