3
$\begingroup$

I was wondering whether something like this is possible: A block of ice(say) needs to be transferred piece by piece from a source to a destination with the help of 5 robots standing in a straight line between the source and destination. The first robot picks up a piece of the block from the source and checks if the next robot in line is busy. If yes, it waits for it to complete its task and proceeds, otherwise it transfers the piece and goes back to collect another piece. Please help me on implementing this if it is possible, as I am thinking to make it a project topic.

to clear out the confusions, here's a smaller prototype of the project i'm thinking,

i have two cars, one wired, another wireless. the wired car is the master here, the wireless, the slave. through a remote, i send a command to the wired car to instead command the wireless car to move forward. the wired car will then check if the wireless slave is already executing some previously given command or no, and accordingly send the command.

conversely, the master may send the command as soon as it receives it, it's on the slave now to complete the task it's doing, and then execute the command it just received.

$\endgroup$
  • 5
    $\begingroup$ Isn't this a rather broad question? Designing robots has at least 2 very different aspects: designing the hardware (choosing sensors, motors, microcontrollers, designing actuators etc.) and designing the software, which allows the hardware to behave the way you want. Could you perhaps clarify which aspect of the implementation you need help with? $\endgroup$ – Daniel Eberts Nov 24 '12 at 13:13
  • $\begingroup$ @DanielEberts: In fact, even if the question was about the hardware aspect, ti would still be quite broad. It needs to be narrowed down a lot :) $\endgroup$ – Manishearth Nov 24 '12 at 13:23
  • $\begingroup$ This is a problem of threaded programming that is going to get played out in the real world. Are there things beyond a producer-consumer thread model that you'd need to learn about? $\endgroup$ – Ian Nov 25 '12 at 21:09
  • $\begingroup$ Also, can you explain the constraints a little bit more? It sounds like you're saying that all 5 robots can pick from the source at once, but only one robot at a time can drop at the destination. Is that accurate? $\endgroup$ – Ian Nov 26 '12 at 20:30
  • 1
    $\begingroup$ Ah, I believe the term you're looking for would be "bucket brigade". $\endgroup$ – Joe Baker Nov 28 '12 at 7:40
3
$\begingroup$

The generic answer is yes, such a project could be implemented using existing hardware and frameworks (ROS, MRDS, something else, or none). The collaboration part is pretty simple in this scenario, it's a straightforward handshake between producer & consumer.

The hard part would be first defining each of the jobs in detail, procuring hardware that meets the requirements, and actually getting each robot to do his assigned task reliably. As others have pointed out, you'll need to be a lot more specific.

|improve this answer|||||
$\endgroup$
3
$\begingroup$

A standard way to model that kind of discrete-event behavior is through Petri Nets or a Parallel Composition of Automata.

An interesting start might be to simply create the model and see if it works in simulation first. That will help you solve the high-level logic of your problem. After that is dealt with, you can begin to think about which robot you want to use (or whether you want to build your own) and how you'll implement that high-level logic in your programming language of choice.

The good thing about using these models is that you have means to systematically evaluate whether you have solved your problem or not. Ad-hoc programming might work if the problem is simple enough, but as soon as you incorporate more difficult situations it becomes too error-prone IMO.

|improve this answer|||||
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.