For want of a bumper

[cyclicalobsessive]

I’ve lamented the simplicity of the base GoPiGo3 sensor suite before, and again the lack of a bumper and a few obstacle sensors has complicated my life. When I add a set of asynchronous state machines to control my robot’s stimulus/response behavior to the lack of stimulus sensors, I am nearly going crazy.

To simulate obstacle sensors, I am panning the distance sensor quickly left and right looking for nearby obstacles.

To simulate a bumper, I interpret a “really, really close obstacle” as a bump from that direction.

The first problem I’m having - “avoid left obstacle by commanding a clockwise rotation but robot turns counter-clockwise” has to be a logic issue that more logging will elucidate.

The bigger problem is that the distance sensor, mounted above the GoPiGo3 top chassis and pointed horizontally forward, does not see low obstacles like office chair legs and wheels.

Being stubborn as I am about adding hardware solutions when more free software might due, I really would like to use the GoPiGo3 get_motor_status() function. It has an “Overloaded” status when the actual motor speed is less than the commanded motor speed and the applied power is at or over 100%.

Theoretically, If the GoPiGo3 is stopped by an unseen obstacle this flag should say “hey I’m pushing with all my might but the wheels are not turning, or are not turning as fast as I am commanding”. Indeed it does sometimes, but not always, and it also comes on when the bot is first ramping up to a commanded speed.

I seems like I need to train a neural net to give me a reliable bumper from this “GoPiGo3 sensor” (like that is really going to happen…)

[jimrh]

You’re as stubborn as my son Kirill.

A day with two push buttons, $2 in parts, and a couple of 10 cent barbeque spears from harbor freight, and you have a 100% working bumper.

Why break your head trying to invent a nural net to replace $3 in hardware and epoxy?

(Shakes head)

[cyclicalobsessive]

@cyclicalobsessive

it also comes on when the bot is first ramping up to a commanded speed.

Normal Start (No Stall)

Stall After Reaching Set Speed

Stall From Very Start

Carl always has a fair amount of dust on his wheels, and always some dust is on the slick wood flooring, which explains why even when stalled the GoPiGo3 can achieve and hold the set_speed.

[cyclicalobsessive]

@jimrh

Why break your head trying to invent a neural net to replace $3 in hardware and epoxy?

(Shakes head)

First and foremost is a desire to implement a free and immediate solution, available to all GoPiGo3 users, that does not require any wiring, soldering, or plug building, and does not occupy one of the two extremely valuable “Grove” A/D/I2C sockets.

One of the advantages of buying a robot kit, over just building it from scratch, is to be able to leverage intrinsic features that the manufacturer (or cyclically obsessive fans) supply an easy to use API for.

Like I have said before, every robot kit I have ever bought came with bumper and obstacle sensing (but cost more than a GoPiGo3). I like the idea of an “only pay for the features you need”, but DI has never offered a “bumper kit.”

The fact that they did include get_motor_status() that returns [overloaded, power, encoder, speed] is a very valuable intrinsic function that has lacked a usage example.

(They also allow fiddling with the PID control parameters for some reason, that I have never discovered a use for. There are very few “set X” commands to the GoPiGo3 hardware controller, so I find it very weird the three PID control commands exist.)

Hypothesis: Bumped = Any Overload After Start+0.25s

And if I get lucky:

• Bump Front = Bumped Left and Right Motors
• Bump Right Front = Bumped Right Motor
• Bump Left Front = Bumped Left Motor

And: Clear all bumps when DPS reaches 0

[cyclicalobsessive]

@cyclicalobsessive

And if I get lucky:

• Bump Front = Bumped Left and Right Motors
• Bump Right Front = Bumped Right Motor
• Bump Left Front = Bumped Left Motor

And: Clear all bumps when DPI reaches 0

Ok, so not totally lucky but the hypothesis is looking strong:

NO BUMP RUN:

pi@Carl:~/Carl/Projects/virtualBumper $ ./virtual_bumper.py 
2022-04-17 12:47:04,965 main: === VIRTUAL BUMPERS TEST ===
2022-04-17 12:47:05,018 __init__: left motor status:  [0, 6, 228111, 0]
2022-04-17 12:47:05,019 __init__: right motor status: [0, 16, 178721, 0]
2022-04-17 12:47:05,019 __init__: virtual bumper initialized
2022-04-17 12:47:05,020 main: *** forward() ***
2022-04-17 12:47:07,169 main: *** stop() ***

REPEAT - NO BUMP:

pi@Carl:~/Carl/Projects/virtualBumper $ ./virtual_bumper.py 
2022-04-17 12:47:15,093 main: === VIRTUAL BUMPERS TEST ===
2022-04-17 12:47:15,146 __init__: left motor status:  [0, -12, 228760, 0]
2022-04-17 12:47:15,147 __init__: right motor status: [0, 0, 179369, 0]
2022-04-17 12:47:15,148 __init__: virtual bumper initialized
2022-04-17 12:47:15,148 main: *** forward() ***
2022-04-17 12:47:17,306 main: *** stop() ***

BUMP AFTER UP TO SPEED:

pi@Carl:~/Carl/Projects/virtualBumper $ ./virtual_bumper.py 
2022-04-17 12:47:27,651 main: === VIRTUAL BUMPERS TEST ===
2022-04-17 12:47:27,705 __init__: left motor status:  [0, -12, 229410, 0]
2022-04-17 12:47:27,705 __init__: right motor status: [0, 0, 180020, 0]
2022-04-17 12:47:27,706 __init__: virtual bumper initialized
2022-04-17 12:47:27,706 main: *** forward() ***
2022-04-17 12:47:28,993 bumped: LEFT BUMP  -  motor status:  [2, 100, 229771, 268]
2022-04-17 12:47:28,994 bumped: RIGHT BUMP -  motor status:  [2, 100, 180384, 291]
2022-04-17 12:47:28,994 main: *** stop() ***

BUMP FROM START:

pi@Carl:~/Carl/Projects/virtualBumper $ ./virtual_bumper.py 
2022-04-17 12:47:36,086 main: === VIRTUAL BUMPERS TEST ===
2022-04-17 12:47:36,140 __init__: left motor status:  [0, 6, 229793, 0]
2022-04-17 12:47:36,140 __init__: right motor status: [0, 22, 180402, 0]
2022-04-17 12:47:36,141 __init__: virtual bumper initialized
2022-04-17 12:47:36,141 main: *** forward() ***
2022-04-17 12:47:36,411 bumped: LEFT BUMP  -  motor status:  [2, 100, 229850, 302]
2022-04-17 12:47:36,411 bumped: RIGHT BUMP -  motor status:  [2, 100, 180460, 278]
2022-04-17 12:47:36,411 main: *** stop() ***

BUMP ON RIGHT FRONT AFTER UP TO SPEED:

pi@Carl:~/Carl/Projects/virtualBumper $ ./virtual_bumper.py 
2022-04-17 12:55:19,866 main: === VIRTUAL BUMPERS TEST ===
2022-04-17 12:55:19,919 __init__: left motor status:  [0, 10, 229873, 0]
2022-04-17 12:55:19,920 __init__: right motor status: [0, 18, 180484, 0]
2022-04-17 12:55:19,921 __init__: virtual bumper initialized
2022-04-17 12:55:19,921 main: *** forward() ***
2022-04-17 12:55:20,705 bumped: RIGHT BUMP -  motor status:  [2, 100, 180701, 273]
2022-04-17 12:55:20,706 main: *** stop() ***

BUT BUMP ON LEFT CORNER AFTER UP TO SPEED

pi@Carl:~/Carl/Projects/virtualBumper $ ./virtual_bumper.py 
2022-04-17 12:56:20,586 main: === VIRTUAL BUMPERS TEST ===
2022-04-17 12:56:20,640 __init__: left motor status:  [0, 8, 230108, 0]
2022-04-17 12:56:20,641 __init__: right motor status: [0, 16, 180719, 0]
2022-04-17 12:56:20,641 __init__: virtual bumper initialized
2022-04-17 12:56:20,641 main: *** forward() ***
2022-04-17 12:56:21,480 bumped: RIGHT BUMP -  motor status:  [2, 100, 180954, 291]
2022-04-17 12:56:21,480 main: *** stop() ***

[jimrh]

@cyclicalobsessive

First and foremost is a desire to implement a free and immediate solution, available to all GoPiGo3 users, that does not require any wiring, soldering, or plug building, and does not occupy one of the two extremely valuable “Grove” A/D/I2C sockets.

Free?  I got that.
Immediate?  Who are YOU kidding?

I guess it’s just me, but spending weeks developing a software solution that has a critical dependency on the amount of dirt or dust that may or may not be on the floor?  It just doesn’t make sense to me and doesn’t sound like something easily implemented.

[cyclicalobsessive]

@jimrh

critical dependency on the amount of dirt or dust that may or may not be on the floor?

No dependency - It works better if there is more friction, but it seems to work fine with dust.

Need a lot of testing to make sure there are not “false positive bumps”

[cyclicalobsessive]

@cyclicalobsessive

hypothesis is looking strong

Ouch, reality trumps virtual reality: Hypothesis has some holes!

• My GoPiGo3 virtual bumper works great at 300 DPI on slick floors, but…
• Does not work at all at lower set speeds on slick floors, and …
• Generates false bumps on carpets

Carpet - Normal Ramp Up

 

Carpet - Stall After Reaching Speed

 

CARPET - Stall From Start

 

OOPS - CARPET STALL CAUSED MOTOR TO JAM

Had to wiggle wheel forward and back to unjam gears.

[KeithW]

@cyclicalobsessive

reality trumps virtual reality

I think I’ve mentioned one of my favorite quotes here before:
In theory there’s no difference between theory and practice; in practice, there is.
- Benjamin Brewster

/K

[cyclicalobsessive]

@KeithW

and practice

and practice, and practice a little different, and practice a little harder theories, and don’t give up until I run out of hypotheses to try and theories to practice.

I’m going to figure this yet.

[cyclicalobsessive]

@cyclicalobsessive

I’m going to figure this yet.

BINGO - We have a winner!

Smooth floors, carpets, tiled floors - we’re scootin’ with protection and no false detection.

Working on video and docs…

[cyclicalobsessive]

@cyclicalobsessive

Being stubborn as I am about adding hardware solutions when more free software might due, I really would like to use the GoPiGo3 get_motor_status() function. It has an “Overloaded” status when the actual motor speed is less than the commanded motor speed and the applied power is at or over 100%.

Theoretically, If the GoPiGo3 is stopped by an unseen obstacle this flag should say “hey I’m pushing with all my might but the wheels are not turning, or are not turning as fast as I am commanding”. Indeed it does sometimes, but not always, and it also comes on when the bot is first ramping up to a commanded speed.

Indeed, it works:

Code at: Carl/Projects/virtualBumper at master · slowrunner/Carl · GitHub

[KeithW]

Very cool feature. And the video was very nicely done.
/K