1
$\begingroup$

I've been working on my two-wheeled mobile robot I've been trying to perfect my obstacle avoidance algorithm which is Artificial Potential Field method . Also i use Arduino Uno kit . The basic concept of the potential field approach is to compute a artificial potential field in which the robot is attracted to the target and repulsed from the obstacles. The artificial potential field is used due to its computational simplicity. the mobile robot applies a force generated by the artificial potential field as the control input to its driving system . the Artificial Potential Field method in its computations depends on the distance between robot and goal or target and the distance between robot and obstacles that effected the robot (which could easily get for ultrasonic senors)

I applied the Artificial potential field method in Matlab environment / simulation and it is done successfully , really what I need in the simulation is to get the current position of mobile robot and position of goal as x, y coordinates (to compute the distance between robot and goal) and the obstacles positions.

The output of the Artificial potential field is the desired angle to avoid obstacle and reach to the goal , the method give the robot the angle the pointed to the goal then the robot goes toward that angle and if the robot face an obstacle in his way (got from sensor reading) the Artificial potential field will update the angle to avoid the obstacle and then re-give the robot the angle that pointed to the goal and so on.

The question is how could I apply the Artificial potential field method in real would? what should I get? is it easy to do that or it is impossible?

I had Rover 5 with two normal DC motors and two encoders (incremental rotary encoder) per each wheel.

Any Help or suggestion on the topic will be highly appreciated please.


Edit: Based on the response from Shahbaz.

The case is very simple, but first, there is something to know that I constrained with some limitations that I couldn't overstep them, one of them is that the real world should be exactly as simulation for example in the simulation I consisted that robot started with (0,0) on coordinates x, y axis and I should put the goal point for example (10,20) and feed this point in the Artificial potential field method and then compute distance between robot and goal (so I don't need any technique to determine the position of goal) and I don't know if I could applied that.

The second constraint is that I should use the encoders of wheels to determine the current position of mobile robot and its orientation depending on a calculation formula (something like this here) even if that will be inaccurate.

I had a Rover 5 with two normal DC motors and two encoders (incremental rotary encoder) per each wheel, each encoder has four wires I don't know how to deal with them yet, and how could I translate the pulses of encoders or how to work out the x.y position of your robot based on the shaft encoder data.

I am still searching for ….

$\endgroup$
2
$\begingroup$

From the algorithm's point of view, there is really no difference between the real world and the simulation. The difficult part is to give the correct information to the algorithm.

For that, you need to look at what information your algorithm requires:

  • Your current position
  • Goal's position
  • All obstacles' position

The question is therefore how to get these information. The answer is that it really really depends. There are numerous ways for each and they all depend on what your robot can do, what facilities it has available, what control you have over the environment, whether the environment is static or not etc.

Your location

For example, outdoors you could use GPS to locate yourself, while indoors you may be looking for SLAM. You could possibly get information from a camera installed in the ceiling, or various other methods (search for robot localization).

Goal's location

You could find the goal with the ceiling camera if you have one, you could try to find it by exploration (i.e. set a random goal, go there and in the meantime scan for the real goal e.g. with a camera. If goal not found, go to another random goal), or you could try other methods, e.g. by having the goal send a signal whose direction and strength would be picked up by the robot.

Obstacles' positions

You could again find the obstacles with a ceiling camera, you could find nearby ones (not all of them) with sonar, laser etc, or in case of a static environment simply have a predefined map.


Once you have these information, you can use your algorithm just as before and get the direction you need to go to. You still need to control the robot accordingly. Since you already know about encoders, I assume you know how to make your robot turn to the correct angle given your current angle (which is something you possibly calculated when looking for your current location).


I have a couple of suggestions though. If you already know all the obstacles and the goal's position, then you have better algorithms for navigation. Your algorithm would get stuck in a situation like this:

               ----
            --/
          -/
 goal    |           You
          -\
            --\
               -----

where the algorithm would tell you to go straight to the wall until all potentials cancel out and you reach a stable point where no direction is preferable.

In the case when you have all the information about the environment, you can enlarge the obstacles (in your model) by half of your robot's size (i.e. maximum distance from your center, or whichever point you consider your position to be, to your outer layer), which means you can assume your robot to be a point and the obstacles larger. Then you can use an algorithm such as A* to find the best path to your goal.

If you don't have all information of the environment, you can still use A*, but just add information to the map as you find new obstacles and recalculate your path.

Alternatively, if you don't have all information of the environment and you like to continue with your Potential Field algorithm, you can avoid having information regarding all obstacles and run your algorithm with only those that you know of. Again, as your robot explores, you add more information about the obstacles. This really doesn't change the behavior much since potential is inversely related to distance squared, so the farther objects have very little effect on the potential field at your current position.


Update based on your edit:

Regarding your first point, it's ok. That simplifies things, so all you need is to store the map of your environment (goal position, obstacle positions etc) in whatever way you feel comfortable in your robot (i.e. in a way that you can feed it to your algorithm).

Regarding your second point, you seem to already have the formula, so only thing that remains is the third point, which is converting the signals from the encoder into position.

For that, let's take a look at this very general algorithm:

current_position = (0, 0)
for ever
    current_position = calculate(current_position, delta_encoder_1, delta_encoder_2)

which means start from (0, 0) and on every update, get a new position based on how much each encoder has changed (since last update). The calculate function is effectively the calculations in the link you provided.

To get delta_encoder_1 and delta_encoder_2, you need to consult the datasheet of your encoders. What you get is a series of pulses that you need to detect. Perhaps the most reliable way would be through interrupts, for example by interrupts on the rising edge of a signal arriving from the encoder:

current_position = (0, 0)
for ever
    current_position = calculate(current_position, delta_encoder_1, delta_encoder_2)
    delta_encoder_1 = 0
    delta_encoder_2 = 0

interrupt_on_encoder_1
    if condition for an encoder step forwards
        delta_encoder_1 += 1
    else if condition for an encoder step backwards
        delta_encoder_1 -= 1

interrupt_on_encoder_2
    if condition for an encoder step forwards
        delta_encoder_2 += 1
    else if condition for an encoder step backwards
        delta_encoder_2 -= 1

This means that the interrupts take care of updating delta_encoder_* based on the shape of the pulse, which is something you should get from the datasheet of the encoders. Note the race condition between the interrupts and were the application resets delta_encoder_* values (If you don't know what is a race condition, since you already accept inaccurate position calculation, then don't worry about it).

That said, if you still have doubts, I strongly recommend asking a separate question specifically regarding how to get meaningful data out of your specific encoders.

$\endgroup$
0
$\begingroup$

Oussamma Khatib's potential field algorithms suffer from local minima/maxima finding problems vice global minima/maxima. As such you will get trapped in "box canyons" where the potential field cannot escape. You need to add extra algorithms on top of potential fields to avoid local minima paths.

I did my Master's thesis on artificial neural networks that avoid local minima and find global ones. But there are lots of others to choose from:

$\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.