Advice needed for my eboxbot project

[ozfiddler]

This is where I have got to so far with eboxbot. I have an eBox that is connected to a webcam, a servo controller (http://robosavvy.com/store/product_info.php/cPath/28/products_id/551) and a usb network adapter. That takes up the three available usb ports on the eBox. The webcam is on pan/tilt servos, and I've added a robotic arm to the front. http://robosavvy.com/store/product_info.php/manufacturers_id/35/products_id/1594



I've just started delving into the mysteries of C++ and I have actually managed to write a program that allows me to control the servos from my remote computer using keyboard commands (this may not seem like much to most of you, but for me it is a major achievement). So from my desktop I can now see through the webcam, adjust the viewing angle and potentially pick up an object. I had been hoping to do something with OpenCV but I'm not sure if the eBox is up to that.

As you can see the whole thing is mounted on a tracked chassis (http://robosavvy.com/store/product_info.php/manufacturers_id/35/products_id/1571) and I am wondering how to now handle the control of the two rover motors. Is it possible to do this with the servo controller or will I need a separate motor control? Any suggestions? It would be good to do it without needing another usb.

[i-Bot]

There are some motor controllers which take a servo pulse input. I have used the MD22 from Devantech:
http://robot-electronics.co.uk/acatalog ... llers.html

There must be others with the lower 2.5A current capability you need.

Alternatively you might consider an Arduino with a motor shield. This could be programmed to use the motor optical encoder outputs too. This could use the servo pulses, but may be better using serial to take advantage of the position and speed contol you will gain from using encoders. You might be able to tap onto the servo controller serial bus to avoid adding USB hub.

[ozfiddler]

Thanks for the ideas i-Bot. I think the DC motor controller that takes a servo input would be the easiest way to go. There seem to be a few options.

I also found this simple one that might do the job. http://www.vexrobotics.com/276-2193.html

[PedroR]

Hi ozzfiddler

Your project looks REALLY nice.

We are in the process of preparing a "Linuxified" version of the Rover 5 as well but using the cheaper Omnima to simply stream images to the PC over WiFi and send/receive commands to the PC over the Serial port (VCP over WiFi).

It's a similar solution to what we've done here http://robosavvy.com/store/product_info ... ts_id/1928 but with Rover 5.
In your case it's even nicer because you're using a LOT more horsepower with the eBox.

In any case, back to your question, in the process of developing this, we (actually Marco) developed a solution to control the motors that may be of interest to you:

- The Rover 5 includes Motor Encoders which are essential if you want to have decent control over the speed of the motors (we know this by experience with the Wild Thumper that does NOT have it).

- We've used this board http://robosavvy.com/store/product_info ... ts_id/1573 which includes a 4 channel DC motor controller and includes circuitry to mix the encoder channels
(it's not obvious at first how cool this functionality is abut once we implement control using the encoders you'll really love it).

- We've combined it with an Arduino MEGA (this one http://robosavvy.com/store/product_info ... ts_id/1574 in the case, which is fairly inexpensive)

- Finally, Marco has written Arduino code (including a PI filter) to precisely control the speed of the Motors using the Encoders.
It uses a Serial protocol to receive commands about the speed and direction of the motors.
It uses a protocol with this format "HB[RIGHT DIR][RIGHT SPEED][LEFT DIR][LEFT SPEED]"

You just need to send this through the Serial port and the motors will move.

The code he's written - making use of the encoders and filter - really let the rover move very precisely (it can move really slowly which is something that is very hard to do just by PWM'ing the Motors).

I've uploaded the code here http://robosavvy.com/RoboSavvyPages/Dag ... ontrol.ino

I can't say it's 100% bug free but it works very well from what I have seen.

As i-Bot mentioned, in this scenario you would be using Arduino connected over USB which creates a Serial port where you can just send command sin the format I mentioned to make it move forward, backward, left and right (or stop).

With regards to the solution you mentioned from VEX, I would honestly not recommend it. We have those here at the office and although they should theoretically work, they offer less flexibility than using an Arduino with a DC Motor shield (and in any case, the VEX solution still needs an Arduino or other additional board to generate the PWM pulses to control it).

If you want to start small/simple and and don't want to use the Motor encoders for the moment (and none of the solutions I explained above), then I'd recommend the Romeo controller which includes DC motor controllers. http://robosavvy.com/store/product_info ... cts_id/988
Please note that Romeo only works with 2 motors (ie Rover 5 2WD; if you Rover is 4WD I would then strongly encourage you to go with the solution I proposed above using the Arduino mega and 4 Channel DC motor controller board).

Regards
Pedro

[PedroR]

One additional note:

The Arduino Board I mentioned http://robosavvy.com/store/product_info ... ts_id/1574 includes support for connecting Servos directly to it.

I noticed you have 2 servos on your set up and a Servo Controller; in case you go with the Arduino board (RedBack spider controller) + motor shield, you won't need to use this dedicated servo controller board and thus free up a USB port.

I don't know how familiar youa re with Arduino as to do this you'd need to modify the code and add soe bits and pieces yourself

In any case I leave the information to you.

Kind Regards
Pedro

[ozfiddler]

Hi Pedro,

Wow - thanks for all the great ideas. That gives me a lot of food for thought. I've worked with Arduinos before but I was sort of hoping to avoid that route for a number of reasons. First the eBox doesn't cope with the Arduino program so it would mean always loading up the program from some other computer. But it was mainly just laziness - it took me a while to get the eBox talking to the servo controller with C++, and I was hoping I could just somehow plug in the motors and get them to work as well.

Anyway, I think as a first step I might just try using an Arduino connected through a USB hub to try and get it working. I like the look of the Romeo controller that includes the DC motor controllers, but it sounds like it would be good to eventually get the encoder option working as well. Anyway, the first thing is to get the motors to at least do something and I think I have all the bits I need for that (except the programmer's brain). I'll do a video if I can get it working.

By the way, you may have noticed from the photo that I have already managed to burn out the smaller (front) servo on the robotic arm. I managed to modify it slightly so that I could fit a spare larger servo that I had.

Cheers,

Alan

[PedroR]

Hi Alan

Now that you mention your issue with Arduino (I recall it now ) I believe it's important to clarify a key point here:

1) As I understood from past conversations, the Arduino IDE does not run on the eBox.
This means you won't be able to load sketches onto it

2) However, to operate the Arduino AFTER a sketch is loaded, there should not be any issue. When connected to the PC the Arduino shows up as a normal COM port.

Using - for example - the code I mentioned in my previous post, the only thing you need is to connect the Arduino to a USB port that will be recognized by Windows XP as a Virtual COM Port.

After that you can use ANY program to communicate with the Arduino (ie just write "HBxxxxxx" command to the Serial Port).


There is a clear difference between Loading a Sketch onto Arduino using the Arduino IDE (that you should do once - using some other computer - and be done with it) and using the Arduino after the Sketch is loaded. In the second case it just shows up as a COMM port after it's connected.

I completely understand your reasons for wanting to avoid Arduino although if you really want to I believe it can be possible

Regards
Pedro

[eried]

Hi Pedro,

Wow - thanks for all the great ideas. That gives me a lot of food for thought. I've worked with Arduinos before but I was sort of hoping to avoid that route for a number of reasons. First the eBox doesn't cope with the Arduino program so it would mean always loading up the program from some other computer. But it was mainly just laziness - it took me a while to get the eBox talking to the servo controller with C++, and I was hoping I could just somehow plug in the motors and get them to work as well.

Anyway, I think as a first step I might just try using an Arduino connected through a USB hub to try and get it working. I like the look of the Romeo controller that includes the DC motor controllers, but it sounds like it would be good to eventually get the encoder option working as well. Anyway, the first thing is to get the motors to at least do something and I think I have all the bits I need for that (except the programmer's brain). I'll do a video if I can get it working.

By the way, you may have noticed from the photo that I have already managed to burn out the smaller (front) servo on the robotic arm. I managed to modify it slightly so that I could fit a spare larger servo that I had.

Cheers,

Alan

I built a robot with a x86 with some friends (in this case a eeepc701) and we used arduino and some h-bridges to control the motors. Worked nice, but because issues with image recognition at the end we had to add massive delays to everything in arduino hehe as you can see:
http://www.youtube.com/watch?v=VKftf8Ztisw

You can run only winavr in the ebox to upload the hex file generated by arduino via wireless for example (or the via you are now using for update the c++ code). Our arduino library for serial commands was very simple in this style (only 3 bytes messages for everything):

Code: Select all

0xEE, <speed>, <direction>

And some exceptions like if you send 0xFF as speed you keep the current one, below 0x80 is reverse, etc. Everything worked very fine, so if you have some problem with your current solution, try to re-think about in arduino hehe we had 15 minutes to fix the code between attemps and having a very simple code handling the servos in the arduino was very convenient in a hurry