Automatic Ping Pong Collector

I am planning to do an Automatic Ping Pong Collecting Machine that is able to navigate on its own as well as pick up ping pong balls. I would like to ask for feasible ideas for navigating within a controlled environment and what kind of sensors should I use for specific object (round objects) detection.

Here are some of my ideas in the design of the machine

  1. Follow a specific path using a tape as the path
  2. Randomly moving for a period of time before Return To Home
  3. Scan for object and approaching it. Return To Home after an amount of time

Please provide any suggestions. I am open to any other methods which I am not aware.

P.S. I am a Arduino Beginner.

Cheers

If you are an Arduino beginner and don't have other programming experience this will be a major challenge. In addition to the navigation issues there are many other features - electrical and mechanical as well as programming - that need to work to achieve a finished product.

Start by working through several of the example programs that come with the Arduino IDE.

As far as the navigation is concerned, what sort of space will the robot be working in? A large room with table-tennis tables and few other obstacles?

Ping pong balls are very localized things (compared with mowing a lawn or cleaning a floor). I wonder is it sensible to do anything other than identify them visually which is beyond the capacity of an Arduino. A rotatable camera should find them very quickly with a minimum of movement by the robot.

...R

For picking up the balls a suction pump (small cooling fan and tube) can be used. It's easier to position than a mechanical gripper.

We just used a blower to push them all to a corner.
You could make a dumb bot do sweeps without having to locate and react.

But as a beginner, figuring out motors and coding will take awhile, so unless you have the time and interest to learn what's necessary, abandon all hope for your balls.

I study robotics; navigating an uncontrolled environment like this is extremely challenging and very pricey. Your best bet is to make a semi-dumb robot that tries to follow a path on the floor as you said; it should look like combine harvester and should pick up as many balls as possible.

Here, this is from a robocompetition hosted by my school, should give you some ideas:

video link

I am thinking of adapting a cylindrical roller concept to collect the balls. If the method works, the collecting of balls is done passively, the only challenge is to identify location of balls.

Please refer to link for the roller example.

Please give advise whether it is feasible.

By following a specific path, the collection rate may not be 100%. But since its my first project, achieving above 80% is good enough for me.

I am aware that Arduino is capable of obstacle avoidance, however, can I make it approach an object with a specific width instead?

Here is my concept of object finding.

For example, it wont approach the fence enclosing the area as the ultrasonic sensor senses that it is an object of width larger than 3cm, it will reverse and go another direction. By this way, it will always travel randomly in the enclosed area. When it sense a 3cm object (pingpong ball) it will approach it, collect and then sense the surrounding again.

So to sum it up, the machine will go another direction when ultrasonic sensor senses object is greater than 3cm and will approach it if it is less than 3cm.

The project can be conducted in a controlled environment. A flat enclosed surface with ping pong balls.

It may be very difficult to measure the size of an obstacle, in detail when this object is ball-shaped. Eventually it helps to find the resonant frequency of the balls, to improve their detection. Get a sensor and find out yourself, whether your idea can work at all.

Build a working bot that you can manually control, first.
You deciding on your ping pong ball pickup method isn't some executive decision, it's nearly irrelevant at this point. It's like you're choosing what to hang from a rearview mirror before you even have a car.

Now if each ping pong ball had an LED in it and the lights were off you might be able to
find them without resorting to OpenCV and major-league hardware.

MarkT:
Now if each ping pong ball had an LED in it and the lights were off you might be able to
find them without resorting to OpenCV and major-league hardware.

Color detection actually wouldn’t be difficult, as long as there weren’t any other whitish objects. Color sensing modules are cheap. Not sure what the range on those things are, and it may still be a blind wander until one happens to fall into range before detection runs. But after I typed all of this so far I think we’re talking the difference between ‘finding’ and ‘identifying as a ball once found’. So I’m not disagreeing with you after all.

HOTeddy:
I am thinking of adapting a cylindrical roller concept to collect the balls. If the method works, the collecting of balls is done passively, the only challenge is to identify location of balls.

Please refer to link for the roller example.

Gather My Balls - ME 407 Design Project METU - YouTube

Please give advise whether it is feasible.

By following a specific path, the collection rate may not be 100%. But since its my first project, achieving above 80% is good enough for me.

I am aware that Arduino is capable of obstacle avoidance, however, can I make it approach an object with a specific width instead?

Here is my concept of object finding.

For example, it wont approach the fence enclosing the area as the ultrasonic sensor senses that it is an object of width larger than 3cm, it will reverse and go another direction. By this way, it will always travel randomly in the enclosed area. When it sense a 3cm object (pingpong ball) it will approach it, collect and then sense the surrounding again.

So to sum it up, the machine will go another direction when ultrasonic sensor senses object is greater than 3cm and will approach it if it is less than 3cm.

The project can be conducted in a controlled environment. A flat enclosed surface with ping pong balls.

Is the floor color going to be constant, with high contrast to the pingpong balls?

The video you're linking to says:

GMB is a robot tennis ball collector, designed by 6 senior mechanical engineering students in Middle East Technical University in Spring '12.

GMB Features:

  • 50 Ball Collecting Capacity
  • Unloading Mechanism up to 50 cm
  • Radio Frequency Control
  • High Maneuverability

It took 6 senior mechanical engineering students to design a ball picker that's RADIO CONTROLLED.

I am not trying to underestimate you, but... This is not easy.

Well, but if I were to do it:

I'd use a mobile phone for the pingpong ball detection. I'd ensure the robot can turn on a spot. I'd connect the phone to an ESP8266.

I have recently bought about 10 phones for $10 each, they run Android. Watch out on Ebay, you might be able to get a similar deal. They are usually bound to an operator that has quit and can't be used to make calls. Still work perfectly fine for robot control...

For the robot, I'd use servos hacked for continuous rotation. I'd then get a ball mouse and hack it into a cheap optical rotary encoder. This should keep the price of your robot under 100 bucks. Alternatively, you might be able to get slightly worn LEGO parts and attach them to a metal or a wooden frame.

Just keep in mind Android programming is... How to put it. You could say it's not really beginner friendly; you could also say it's not a good idea to wear shorts on Antarctica.

I have did some research and I came across an Arduino Radar.

Please refer to the link below.

So from this video, can I assume that my concept can work?

HOTeddy:
Here is my concept of object finding.

For example, it wont approach the fence enclosing the area as the ultrasonic sensor senses that it is an object of width larger than 3cm, it will reverse and go another direction. By this way, it will always travel randomly in the enclosed area. When it sense a 3cm object (pingpong ball) it will approach it, collect and then sense the surrounding again.

So to sum it up, the machine will go another direction when ultrasonic sensor senses object is greater than 3cm and will approach it if it is less than 3cm.

Arduino can sense object size and I would need to write a code for my machine to approach it (which I have no idea how to start).

I greatly appreciate all your active replies.

The sound sent by the ultrasonic sensor is not a narrow beam, it's more like a cone. About 15 degrees. You can't really hope to be able to reconstruct the geometry of your surroundings reliably with it, at least not without using a lot of post processing and perhaps machine learning... This being said, the "radar" technique is usually suficcient for avoiding obstacles in environment consisting of just walls and no narrow poles or silly stuff like that. I remember having done something like this before; I used 2 sensors, one ultrasonic and one light reflective distance sensor. I used the latter with a PID control loop to make it run close to a wall. That was in a controlled maze environment.

Well anyway. For obstacle avoidance, the simplest and best way (in my opinion) is doing this:

  1. have ultrasonic sensors all around you, maybe like 6 of them...
  2. give your robot 2 differential wheels (meaning it steers by running one forward and one backwards)
  3. make the robot perfectly round by giving it a cylindrical bumper with the center right between the 2 wheels
  4. if you're not expecting any thin poles to be around, also preferably put wheels on the cylinder, so when it bumps into the wall, it just continues riding along it.

Now, this will work perfectly until you want your robot to ride under a bridge-like structure. Then it might not recognize it, headbump it and tip over.

Maybe you could use a Pixy camera to detect and mode toward ping pong ball coloured objects.

You ask about feasibility and yes a robot can be built to do many things. But you are constantly giving the impression that you severely underestimate the time and learning involved, and expect free constant hand holding along the way.
Maybe not what you want to hear or are capable of truly hearing, but this project is way too much for a self-proclaimed beginner. It's more than buying parts and sticking them together. That's likely the easiest part.

INTP:
You ask about feasibility and yes a robot can be built to do many things. But you are constantly giving the impression that you severely underestimate the time and learning involved, and expect free constant hand holding along the way.
Maybe not what you want to hear or are capable of truly hearing, but this project is way too much for a self-proclaimed beginner. It's more than buying parts and sticking them together. That's likely the easiest part.

What he said; this being said, I still encourage you to give it a go. Just try doing it as cheap as possible. Spending time on it isn't a waste, since you'll learn a lot. Spending a lot of money would be.

I would consider myself an intermediate Java programmer and I do have some field experience with robotics. I do have a pretty extensive experience with a (simple) PCB design. I don't really know much about mechanical engineering...

But the thing is, if I were to attempt this project, I would estimate the time needed to no less than 3 months. However, my estimates regarding time required tend to be severly on the low side.

You don't, and can't see the problems that will arise as you try to complete the project. Allow me to elaborate:

First you'll need to code the pingpong ball detection. So you will fire up Processing, and you'll try to code something that scans the screen pixel by pixel and notes if the value differs from the previous one. You will be programatically moving random drawn shapes in the background and use this as your "video data". Soon you will find out the "fps" is around 0.1; so you will scratch your head and increase the distance between the pixels you're scanning. This will increase the speed a lot, but you will be thinking that this is a silly solution. Indeed, wouldn't it be better to make the movement detection in such a way, that it scans for the object in the area it's last seen it in and then move on from there? That would give you a big resolution for small movements, but you'll still be able to catch bigger ones, too! So you will implement that. Yes, but it'd be best to also take the direction the object has been moving in into account! So you add it, too. Whoops, but you've only been tracking one dot so far!! So you decide to add a second one. Your program breaks. You decide to fix it. Congratulations, now you can track multiple shapes on the screen! You decide to test this on real data. You run around with your camera phone, taking a video of the balls rolling on the ground. Then you spend 2 hours explaining that suspicious behavior to a cleaning lady who happened to be watching you the whole time.

Equipped with the test data, you decide to run your program on them. It all goes haywire. Turns out you didn't account for the camera image noise.
You use boxcar averaging to surpress the noise and... It works! woooohoo! You managed to track pingpong balls. Now... the tracked position seems jittery, so you decide to make a follower object, which tries to follow the estimated position of the ball on screen. But what's that? Whenever the balls accelerate, your tracker has a hard time keeping up. Puzzled, you go study a control theory to find out you need an integral regulator to track a ramp (or in general a regulator that can generate the input signal).

Once everything works, you go port it to Android. It takes you ages to figure out how to even read a pixel value from a camera; once you figure it out, you manage to port the whole stuff. However, it's not fast enough. Soooo you dig deep and try to solve everything on gpu chip of the phone and... go down the rabbithole.

But it all goes well! :3 Your phone can track the balls now. Now you need to send the data to your micro. After a while, you manage to get that to work. You fix the issue where when 2 balls go past each other, you are no longer sure which one is which;

Now you have to decide which one of the balls to go for! Well... the closest one? That one will be lowest on the screen. But... once the balls move, the closest one will be a different one. If you don't want the bot movement to be erratic, you'll need to fix this. Of course, you also want to target larger groups of pingpong balls! But... larger group is rather relative. But let's not go there.

Then you will be building the robot itself. You'll encounter many problems-such as your micro resetting once you start rollin,' as it's not getting enough current any more.
You will have issues with the motor stalling if you try to apply low duty cycle to it. This will sometimes happen and sometimes not. You will use a light based rotary encoder and a PID control loop to control the motor itself; you'll get to understand gray code.

And then there is still the mechanical engineering.
By the way, do you have a mechanical engineering background?