Starting my first UGV project - need some starting help

The xbee looks interesting, the only limit is the range of 100m...
For the wifly shield, do I need internet for it?

About buying a ready made rc car with camera: I searched for some cars, but the transmit range is not enough.

Maybe it is a good idea to buy a FPV camera that they use with RC aircraft.
It has much more range...

I'll search more now.

EDIT: one more question: if I buy a robot chassis, is it possible to install a receiver on it, and control it with a transmitter?
The same way as RC aircrafts work.

I think this is what I want:

http://www.robotshop.com/dagu-wild-thumper-6wd-all-terrain-chassis-aluminum-34-1.html

Now I don't know which controller to take:

or

http://www.dimensionengineering.com/products/sabertooth2x12rc

Can the sabretooth handel the motors?
Is it possible to let a led go on by pushing a button on a transmitter, because I don't see digital pins, but only pins for servo's?
Also, what does 75:1 or 34:1 gearbox mean?

I'm probably going to buy this robot chassis:
http://www.robotshop.com/dagu-wild-thumper-6wd-all-terrain-chassis-aluminum-34-1.html

There is a 75:1 and 34:1 gear ratio version, which one will be the best? Speed is not very important, but strength and carrying capacity is.
Can someone explain it?

I'd suggest the Sparkfun controller given the minor increase in cost and much larger quantities of features (battery charging, programmable Arduino). Also, the pins aren't really "pins for servos" but rather just handily arranged with a +, -, and signal for each output.

75:1 means that the motor rotates 75 times for each 1 rotation of the output shaft. This would of course be slower but stronger than the 34:1 ratio version.

Chagrin:
I'd suggest the Sparkfun controller given the minor increase in cost and much larger quantities of features (battery charging, programmable Arduino). Also, the pins aren't really "pins for servos" but rather just handily arranged with a +, -, and signal for each output.

75:1 means that the motor rotates 75 times for each 1 rotation of the output shaft. This would of course be slower but stronger than the 34:1 ratio version.

Thanks for clearing that up!

I'll go for the sparkfun controller then, and a 75:1 ratio version.

If I want to control a pan/tilt camera on the UGV, will that be possible with a normal 6 channel transmitter like this?:

It will be something like this:

-The right joystick is for going left or right with the UGV(horizontal control)
-The left joystick is for going forward or backward(vertical control)

Now I have only the following left to use:

-The right joystick(vertical control)
-The left joystick(horizontal control)
-Left switch
-Right switch

-So, would it be possible that when I put the left or right switch, the left joystick controls the camera, but doesn't control going left or right anymore?
I assume that the Arduino is the best way to do something like this, but then there is another problem: The Arduino should be able to remote control things on the UGV when the UGV is 500 meters away from me.

I don't want to use the right switch to turn the camera right, and the left switch to turn the camera to the left, because I'll lose the switches for something else then.

Maybe am I thinking to difficult, and is there a much more easy way to control a pan/tilt system?
Or, maybe I should get a transmitter with more channels?

Yes, it would be possible to utilize a switch to tell your Rover that the joysticks (speed and turn signals) control the camera. This would require additional programming on your part; you should look at the example code for the Wild Thumper Controller and make sure you understand it. in the RCMode() function you'll see it reading the speed/turn channels and here is where you'd have it read an additional channel to determine if those readings are for the camera or the wheel motors.

I'd suggest you also set the Rover's speed to zero whenever it detects you've flipped your switch to camera control.

It might be better to have one joystick control the camera position (you may want this one to be non self-centering, if that is an option), and the other control the vehicle motion. Then, pass the signals from the receiver into the Arduino. Have the Arduino decode the signals, and pass them back to the ESC/steering servo, and servos for the pan/tilt (via the servo library); alternatively (and this would possibly be best), use a seperate serial servo-controller (such as from Pololu) commanded by the Arduino. Wire the output of the receiver channel for one of the switches to the Arduino as well. Use this as a "menu" function; add some kind of OSD video overlay controller, and pass the camera feed thru it before you pass it to the on-board transmitter. On this feed you could overlay things like compass readings, other sensor readings, perhaps GPS (might not work well in the woods?) - and also a menu; flip the button, get a menu, select the options with the joystick(s) and switche(s), exit back, continue on. This way, the number of possibilities (servos, "channels", etc) is almost unlimited.

Thank you very much for explaining that!

So this is basically how it will work:

Transmitter sends signal to receiver>> signal arrives at receiver >> servo cable from receiver to the Arduino >> Arduino serial cable to servocontroller >> servocontroller controls the servo's that I want.

I don't understand how the receiver can tell the Arduino to interact with the servocontroller.

I've got a few questions about it:

-Is the Wild Thumper Motorcontroller also a servocontroller? I can see it has outputs for servo's on it. Altough, I don't know if it is possible to control the servo-outputs with RC receiver?
-How can I connect a servo cable, from the receiver, to the Arduino?
-I'll use the Wild Thumper 15A motor controller, and it has an onboard Arduino(ATmega168) on it. So that means that I'll have to connect the Arduino from the motorcontroller to the servocontroller, to send the serial signals. I don't see a useable serial output on the motorcontroller? Maybe the USB?

Probably I'm not understanding it all.

Again, thanks for helping me!

Here is the Wild Thumper motorcontroller:
http://www.robotshop.com/dagu-wild-thumper-dual-15a-motor-robot-controller.html

TiboJ:
Thank you very much for explaining that!

So this is basically how it will work:

Transmitter sends signal to receiver>> signal arrives at receiver >> servo cable from receiver to the Arduino >> Arduino serial cable to servocontroller >> servocontroller controls the servo's that I want.

Pretty much; note that I was thinking of something like the servo controller Pololu sells, which typically communicate using TTL serial (thus, you would use something like a software serial connection, or an Arduino that provided more than one hardware serial port).

TiboJ:
I don't understand how the receiver can tell the Arduino to interact with the servocontroller.

Well - you have to decode the servo commands from the receiver; I know there are people who have done this (there may even be a library available). Essentially, you are converting the PPM signal from the receiver servo channels into a numeric value.

TiboJ:
I've got a few questions about it:

-Is the Wild Thumper Motorcontroller also a servocontroller? I can see it has outputs for servo's on it. Altough, I don't know if it is possible to control the servo-outputs with RC receiver?

Looks that way to me; I think only the high-current DC motor outputs can be controlled by RC control, but I haven't looked at the manual (just basing this on what I read at the link and the image). You might be able to control the servo outputs via I2C or some other manner (meaning you might be able to connect this board to an Arduino using I2C for control of the servos). Note that it has a 168 on board, so it is essentially a basic Arduino itself.

TiboJ:
-How can I connect a servo cable, from the receiver, to the Arduino?

You could use a stripped servo extension cable; you would only need to connect the ground and signal lines (not the power); run the signal line to a digital input (then use/build PPM interpretation code to decode the signal).

TiboJ:
-I'll use the Wild Thumper 15A motor controller, and it has an onboard Arduino(ATmega168) on it. So that means that I'll have to connect the Arduino from the motorcontroller to the servocontroller, to send the serial signals. I don't see a useable serial output on the motorcontroller? Maybe the USB?

I believe that the motor controller is meant as a standalone device, meant to be controlled by some other means, whether an RC system or another microcontroller; while it might have spare code-space to be used as an integrated robot controller, the 168 is kinda limiting. While it doesn't have another serial port (no 168 or 328 based Arduino has more than one, which is "dedicated" to the USB connection), you can use a software serial port connection (via the digital pins - which on this controller are part of the servo pin block) to whatever serial device you want.

That said - since this controller is an "all-in-one" device - if you can live with the limitations of the 168 (memory, I mean) on board, then it probably has everything you need. I don't know if you get the source code to the software on it, but if you do, that code already is set up to decode the steering control inputs from an RC receiver, it looks like; so you could either modify it, or they may include/show how to use it with extra RC channels (each which would take up a spot on the servo output block, of course). If that is the case, then you have just about everything you need.

Unfortunately, I think the 168 might be too limited to allow you to implement anything like the OSD menu-type system for video like I noted earlier, unless you are able to write some very tight code; I really don't know. You would need both that tight code, and some kind of OSD board that used TTL serial or such for commands to draw the characters, with pass-thru for the video (camera->OSD->video transmitter).

Probably I'm not understanding it all.

Again, thanks for helping me!

Here is the Wild Thumper motorcontroller:
http://www.robotshop.com/dagu-wild-thumper-dual-15a-motor-robot-controller.html
[/quote]

I just looked at the Wild Thumper code and manual; it is very basic, easy to read - you should be able to use it to read extra channels if you want (it is only set up currently for two channels, but adding channels should be easy). The code doesn't look very big, so adding the OSD stuff might be doable. You could also use a separate Arduino if you wanted, and use it via I2C or serial TTL (and a software serial library) to act as the OSD piece. This is actually a nice bit of kit for a robot controller (though a bit pricey - you are essentially paying for the h-bridge).

Thanks for explaining again!

Pretty much; note that I was thinking of something like the servo controller Pololu sells, which typically communicate using TTL serial (thus, you would use something like a software serial connection, or an Arduino that provided more than one hardware serial port).

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

Well - you have to decode the servo commands from the receiver; I know there are people who have done this (there may even be a library available). Essentially, you are converting the PPM signal from the receiver servo channels into a numeric value.

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

Unfortunately, I think the 168 might be too limited to allow you to implement anything like the OSD menu-type system for video like I noted earlier, unless you are able to write some very tight code; I really don't know. You would need both that tight code, and some kind of OSD board that used TTL serial or such for commands to draw the characters, with pass-thru for the video (camera->OSD->video transmitter).

I think that is a limitation for me, the code is probably going to be big, so the 168 might have to less memory.
I'll think about it, and otherwise, there is an alternative:
http://www.dimensionengineering.com/products/sabertooth2x12rc

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

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.