Multiple Arduino Yun Controlled Wifi Robots

Here's my Standing
I have four Arduino Yuns. I want to use one as a controller and the other three as the "brains" of my robots. These robots run three DC motors and one servo motor.

I want to setup a network using the controller Yun and have the other three Yuns connected to this network.

My idea is to connect the slaves all to the masters on board wifi. I want to use switches on the controller to depict which robot(s) I want to control.

Here's my thinking:
Once the robot(s) are selected a button is pushed. Data is then assigned to the arduino side of the board depending if I'm controlling one or multiple robots. Then I can send that data through the bridge to the linux processor. From there I want to open sockets and send packets of data across to the selected robots. The data will be recieved by the other linux processor (at the appropriate robot(s)) and then bridged back to the arduino side where it is interpreted to create output.

Here's My Question:
Am I nuts? Can this be done? Is there a simpler way!?
The KEY feature of this project is being able to control multiple robots at the same time.

taylor20x:
Am I nuts?

Maybe, but who isn't :stuck_out_tongue_closed_eyes:

taylor20x:
Can this be done?

Yes.

taylor20x:
Is there a simpler way!?

Yes, simpler and cheaper (using Xbee or NRF24)

So I am even more unexpired with Xbee than I am Arduino. After researching what you suggested, I looked at ordering four Arduino Unos, four Xbee shields, and four Xbees of some type. The Xbee's are going to be inside an enclosure so I am debating what type to get. Do I need one with a Trace antenna, the wire antenna, or one where i can connect the antenna via coax (and run that to the exterior)?

My main goal is to keep cost low hence why I'm buying the Unos instead of using my Yuns.

taylor20x:
So I am even more unexpired with Xbee than I am Arduino. After researching what you suggested, I looked at ordering four Arduino Unos, four Xbee shields, and four Xbees of some type. The Xbee's are going to be inside an enclosure so I am debating what type to get. Do I need one with a Trace antenna, the wire antenna, or one where i can connect the antenna via coax (and run that to the exterior)?

My main goal is to keep cost low hence why I'm buying the Unos instead of using my Yuns.

@taylor20x,
your antenna depends on your case, if you are using a metal case, you most likely will need an antenna via coax. If you use, plastic, wood, cardboard, or paper, you can get away with a trace or wire antenna. Also, so Xbee have built-in antenna, which may be enough - depending on your distance.

Jesse

As long as you already have the Yuns, it's worth giving it a try before investing in a bunch of new hardware (Unos, shields, XBees, etc.)

The advantage to the XBee is that you might get better response (less latency when sending commands.) The disadvantage is that it's likely to be a lot more work (writing code to reliably create and parse serial messages.)

The advantage to the Yun (other than you already have them) is that a nice set of communications tools already exist.

I would start with the robots. Using the Bridge Example as a starting point, develop a basic REST API for controlling them. An initial set of commands might be:

You could add additional parameters if needed, for example http://arduino.local/arduino/fwd/[i]nnn[/i] where nnn is a number indicating a desired speed. Get some basics working first where you can enter those commands in a web browser and the robot responds.

Then, move to the control center. When buttons are pressed, have it send those commands to the robot. You could try using the Process Class to have the Linux side send commands to the robot using curl, or the HttpClient Class to send the commands directly from the sketch.

If that gives you the level of control and response speed you need, then you can expand it to more commands, and start adding more robots. To address more robots, you would just give each one their own name and IP address, and then use the appropriate name/address in place of the "arduino.local" in the above commands. (Addressing the individual robots is the easy part.)

For final "deployment" it probably makes sense to have the control center act as a WiFi hotspot, and have the robots join that WiFi network as clients.

Can i see one of your routines ?

" http://arduino.local/arduino/stop "

DarkAngel1973:
Can i see one of your routines ?

Look at the the Bridge Example. The key is this block of code:

void process(YunClient client) {
  String command = client.readStringUntil('/');

  if (command == "digital") {
    digitalCommand(client);
  }
  if (command == "analog") {
    analogCommand(client);
  }
  if (command == "mode") {
    modeCommand(client);
  }
}

This is reading the portion of the incoming command that I have highlighted in bold in my suggested command list. It decodes that portion of the command, and if it is "digital" it calls the function to call a digital command, if "analog" it calls a different function to handle an analog command, etc. If implementing my example list above, it would check if the command is "stop" and call a function to stop the robot, "fwd" would call a function to make it move forward, etc.

If parameters are added, like how I suggested a speed after the fwd command, then the next level handles that. Just like the example's digitalCommand() reads a pin number, the robot's forward command function would read a speed.

The key is that the example provides a simple way to parse incoming commands and extract multiple verbs and values from the command request. What commands you implement, and what they do, is completely up to you.

the bridge generates a new html page after the comand , can i change that and redirect to same page again?

DarkAngel1973:
the bridge generates a new html page after the comand , can i change that and redirect to same page again?

I replied in the thread you started. Probably best to keep your discussion going in only that thread, and leave this thread for the original topic of controlling multiple robots.