Wall Following Code - Anyone?

GoPiGo
1

In September 2018, I posted a question: Safe Wall Following Ideas?

Anyone know of some wall following code using a single distance sensor?

Or even better yet: wall following code using the pi-cam?

There are so many robot behaviors I can imagine using wall following:

  1. corner bot: (start along in corner) follows wall till opening or obstruction, (announces wall length), turns 180, follow wall till corner, (announce wall length), turn 90, follow the second wall till opening or obstruction, (announce wall length), 180 turn, then return to corner, (announces wall length), turn other 90, rinse and repeat.

  2. Changing of the guard: (Start along wall), pace to opening or obstruction, 180 turn, pace to opening or obstruction, 180, rinse and repeat.

  3. Hall Monitor: ( start along wall), fwd to opening or obstruction, 90 turn, fwd to wall following distance from opposite wall, 90 turn, rinse and repeat.

  4. room mapper?: this one gets really complex

1 Like
2

One thought is that you should be able to use your lane following code to find the “edge” where the wall and floor meet - and the distance sensor to locate obstructions.

After that, it’s just a walk in the park for an old code-hound like you!

3

True, but also a consideration is the higher cost for Carl (processing load, juice, and, and thermal).

I hope to make a first cut solution that will be useful for GoPiGo3 Starter Kit owners to build a class of simple bots that demonstrate behaviors which evoke synthetic emotions. (And self contained, simple to understand, simple math, and easy to extend hopefully.)

1 Like
4

I really wish I help, but you’re already way over my head.

I don’t know how you’d do a low-resource, simple mathematics solution to something that, essentially, involves image processing.

AFAIK, the words “image processing” translate almost directly into “non-trivial”. Roget’s Thesaurus (:wink:) suggests “active cooling” as a synonym. “math co-processor” was also a suggestion. :laughing:

All kidding aside, I’m not sure how you’d get a decent “simple” first-cut without a dedicated image processor.

Doable? No prob!

Easily doable? Not so sure about that one.

You DO have my curiosity riz, though.

5

I have not implemented it yet, but this is what I’m thinking:

Wall Following: (wall on right roughly parallel to bot heading)

  1. Point distance sensor 45 degrees to right of forward
  2. (Check distance > “safe to drive distance” or exit function)
  3. Start Driving Forward
    Loop:
  4. Check distance > “safe to drive distance” - else stop wheels and exit function
  5. If distance (to wall on the diagonal) is > (105% of desired distance): turn a little to the right
    • (by decreasing the speed of rt wheel)
  6. Else If distance to wall on the diagonal is < (95% of desired distance): turn a little to left
    -(by increasing the speed of rt wheel a little)
  7. Else we’re doing good so set rt wheel speed to equal left wheel speed
    • (I think there may be a reason to slightly bias the bot toward the wall)

This can be (must be?) tuned of course, choosing different percentage band and different safety distance.

Smarter folks can go math crazy implementing Proportional Integrative Derivative and tuning to maximize correction speed with minimal overshoot, but I’m guessing the simple math algorithm will work well considering the minimal effort to implement it and understand it.

I think the line follower example implements a PID controller, so I probably could “fake a line sensor” with the 45 degree diagonal distance to the wall and reuse the line follower PID code, but no one would understand it without pictures.

1 Like
6

If it were me, I’d think more like this:

  1. Point distance sensor directly ahead. Measure to determine if it’s safe to move.
  2. Rotate sensor 90° to one side, measure distance.
  3. Rotate sensor 90° to the other side, measure distance.

(Assume: The robot will be placed relatively close to the wall you want it to follow.)

  1. Move forward and continue measuring.

Ideally, a visual field description is the most efficient since you can determine where you are, where the wall is, (on which side), and clearance in front at the same time.

It might be a bit more processor expensive, but ultimately it may well be more efficient in the long run.

This is the kind of thing I just love to start thinking about at 11pm, after smacking my head on a stair while putting something away. :dizzy_face:

I start thinking about what the 'bot needs to do, then start wondering “but what if the [etc.] happens?”, and I don’t get to bed before five!

7

It can be…

Here I’ll get you started:

  • save it as: jim.py
  • python3 jim.py
#!/usr/bin/env python3

import easygopigo3
import easysensors
import time

STOP_DISTANCE = 4.0

def follow_wall(egpg):
    #
    print("distance reading: {}".format(egpg.ds.read_inches()))
    while (egpg.ds.read_inches() > STOP_DISTANCE):
        egpg.forward()
        print("distance reading: {}".format(egpg.ds.read_inches()))
        time.sleep(1)
    egpg.stop()


def main():
    egpg = easygopigo3.EasyGoPiGo3()
    egpg.ds = egpg.init_distance_sensor()
    egpg.pan = egpg.init_servo()
    egpg.pan.rotate_servo(90)
    print("OUTA MY WAY! I'm goin' till I can't")
    follow_wall(egpg)
    print("GUESS THAT'S ALL SHE WROTE")


if __name__ == '__main__':
    main()
1 Like
8

I found this - an Arduino implementation of a wall follower:

http://btulab.com/bt-u-go

Interesting!

9

Interesting indeed. Thanks for the link. It is a well-documented description of the chosen problem, the approach, the surprises, and the result. It also represents the familiar “build a bot to solve a single problem.”

The single problem provides a wealth of opportunities to learn about a processor, a computer language, programming techniques, editing, testing, debugging, motors, sensors and sensing, feedback loops, human interfaces, batteries, robot construction, wires, connectors, hardware busses, and even screwdrivers.

All of my prior robots used two limited-purpose proximity sensors; cross angled to provide greater angular coverage.

The GoPiGo3 sensor suite does not preclude, nor include a dual direction close-proximity sensor, instead emphasizing a single, larger range, servo mounted sensor.

For this reason, I think your algorithm:

  • (find the wall),
  • loop_start:
    • measure the distance to the wall,
    • look forward,
    • measure the safe distance forward,
    • move forward while managing wall distance, and
    • repeat until not safe or wall disappears

is the best algorithm to implement for wall following on the GoPiGo3.

There are variations on a theme possible with this algorithm

  • slow and careful,
  • fast and presumptuous,
  • simple vs complex,
  • PID vs no PID,
  • robust or fragile,
  • single side vs dual side,
  • forward vs reverse,
  • start aligned to follow wall, vs start aligned facing a wall,

and so many more.

I’ve put my development work on hold for a bit; hopefully some STEM teacher will choose this robotic function to investigate (and document a few solutions for us).

1 Like
10

“Single problems” are interesting because they directly invoke the “90/10” rule. The solution of the “single” problem will solve 90% of the issues of a more complex problem too. In other words, you will have already done the lion’s share of the work - without the complexities of a multi-headed Medusa of a project.

This is why I like “simple” projects. Since there are relatively few “moving parts”, it’s easier to see how the parts that are there move and articulate with respect to each other.

11

Single problems can indeed be wonderful learning experiences for the person with the single problem - ie. a robot with two distance sensors - one facing forward and one facing right can follow a wall on its right side.

90% of GoPiGo3 users don’t have two sensors. One of the “single problems” our community needs is a simple-to-understand wall following example that uses the DI Servo kit and DI Distance Sensor.

In the interest of not having to solve every problem myself, I started this to elicit wall following solutions. I thank you for providing a link to one way to solve the wall following problem. I cannot use that solution, but it is good to have for others that can.

I am still hoping someone will find or write a “single sensor wall following function (with obstacle and loss of wall detection).”

1 Like
12

True.

What I was trying to express, (obviously not very well), is that it’s not always necessary to solve the entire problem, all at once.

If you break down a complex problem into a series of simple problems, it’s easier to tackle.

For example: (one possible methodology)

  1. Implement a simple object avoidance solution for objects directly ahead.
    a. Is the way clear for “x” distance? Then proceed.
    b. Is there an obstacle? Then turn a random amount in the range -90 to +90 degrees
    c. Go back to “a” and continue.
  2. Implement #1 as a real-time process running continuously.
  3. Modify #2 to provide a “head motion” to scan for a way out.

Then modify #'s 1 and 2 to detect the presence of a “continuing obstacle” on one side or the other.

Then modify to maintain a fixed distance from the obstacle.

For example, SparkFun just advertised a very small LIDAR tof distance sensor that could be added. Since you can now support 3 distance sensors, (at least in DexterOS), implementing a “maintain a fixed distance” routine should be a total cinch for an old code-hound like yourself while still running #'s 1 and 2 as background processes sending events to the main program.

What say ye?

13

I get it Jim. I hear you. I agree with you. I love that you want to help.

WHAT??? You are killing me.

Please,

  • I told you that I started this thread to elicit single DI Distance sensor on a panning (DI) servo wall following CODE.
  • I told you that "your solution looks to be “the best algorithm”.
  • I suggested a software framework for you or anyone else to turn an algorithm into reality
  • Please …

That’s what I said, and that is what I say.

1 Like
14

I haven’t read the whole thread, but you folks know that the GPG3 can handle 3 distance sensors now, right?

Just in case it wasn’t known.

2 Likes
15

True, but perhaps only for short sessions.

My testing has hinted that non-recoverable I2C errors are lurking - even for two distance sensors, or one distance sensor and one IMU.

This is why I am asking about single sensor servo mounted wall following code.

1 Like
16

I am terribly sorry if I have missed the major thrust of this.

Since I am in the middle of a major electrical renovation, I have little time for code. Charlie, by the way, hid in a corner when he saw me with sharp tools. Then again, most everyone runs and hides when the see me with sharp tools!

As I browse the 'net, if I see something that I think might contribute to this question, I post it. If I have an idea, perhaps inspired by something I read, I post it. My hope is that either you, or someone else on this forum will see, and elaborate on, the ideas I posted for you.

I am sorry that I do not have either the time, or expertise, to provide working code examples for your benefit. I am trying to contribute what I can.

Thanks for your patience with my stupidity.

1 Like
17

Is this with the new, NEW rev GoPiGo red-board, or an update to DexterOS, or what?

There hasn’t been a major update to R4R/Buster that I missed? Maybe an update to the gopigo/easygopigo libraries?

18

1 in either hardware I2C port, 1 in AD1 with software I2C, and 1 in AD2 with software I2C.

I think that software I2C was added to the distance_sensor.py (and others) in Feb 2019.

A month or two after the change, I decided to update Carl’s RaspbianForRobots to the latest. That night Carl had a silent heart attack (Unrecoverable I2C error) and could not get back on his dock. I found him “dead” in the morning. Carl had been using the default port, and when DI added software I2C, they changed the default port to be the new software I2C. I discovered the change and exhaustively tested hardware vs software I2C. I discussed the issue with Robert at the time, but did not enter an official issue. I believe the issue still exists because the IMU has to use software I2C and I have seen unrecoverable I2C errors when I was testing the IMU extensively.

1 Like
19

Do you know if it is possible to change the i2c address of the IMU/distance sensors?

I have a SparkFun i2c breakout board for the Pi that, as far as I can tell, simply parallels additional connectors on the existing buss.

What I really want is their i2c mux board that actually adds additional i2c ports on one buss with different, (programmable?), addresses.