GoPiGo3 Virtual Bumper From MotorStatus

GoPiGo
, ,
1

Tests this morning with Dave confirm and refine my suspicion that GoPiGo3 Virtual Bumpers are possible.

My ROS2 GoPiGo3 node publishes a custom message topic /motor/status which is filled by calls to GoPiGo3().get_motor_status()

            # publish motor status, including encoder value
            (flags, power, encoder, speed) = self.g.get_motor_status(self.ML)
...
            status_left = MotorStatus(low_voltage=bool(flags & (1<<0)), overloaded=bool(flags & (1<<1)),
                                      power=power, encoder=float(encoder), speed=float(speed))
...

When Dave was commanded to drive backward at 0.1m/s, my ROS2 GoPiGo3 node commanded the GoPiGo3 red board to drive at 172 DPS.

The unimpeded GoPiGo3 ROS2 status reports:

---
header:
  stamp:
    sec: 1632833460
    nanosec: 595076614
  frame_id: ''
left:
  low_voltage: false
  overloaded: false
  power: -45
  encoder: 21201.0
  speed: -172.0
right:
  low_voltage: false
  overloaded: false
  power: -33
  encoder: 20058.0
  speed: -172.0
---
...
left:
  power: -35
...
  speed: -170.0
right:
...
  power: -33
  speed: -172.0
---
...
left:
---
  power: -40
...
  speed: -172.0
right:
...
  power: -40
...
  speed: -172.0
---

The GoPiGo3 red board tweaks the power to each wheel to maintain the commanded speed.

When Dave backed into the wall, his wheels started to slip and the GoPiGo3 red board attempts to continue meeting the drive at 172 DPS command by increasing the power to the wheels:

---
header:
  stamp:
    sec: 1632833461
    nanosec: 861067993
  frame_id: ''
left:
  low_voltage: false
  overloaded: false
  power: -86
  encoder: 20988.0
  speed: -140.0
right:
  low_voltage: false
  overloaded: false
  power: -76
  encoder: 19845.0
  speed: -145.0
---

The GoPiGo3 is applying twice the power and still cannot meet the commanded wheel velocity of 172DPS.

I confirmed similar reports for hitting a wall with a forward drive command.

The bumper truth table could be as simple as:

  • bumper True: dramatic jump from an average power greater than 0

but could be more sophisticated to include cases for:

  • (still) blocked when started from a stop
  • excessive power applied for reported wheel speed
  • virtual side bumpers: excessive power applied for reported wheel speed when speeds and power are complementary signed

I’m not going to implement virtual bumpers at the moment, but proving virtual bumpers are possible has been on my mind.

I thought the “overloaded” field would be the field to watch, and may yet be another indication but only if the friction is enough to completely stall the wheel. It may be that my slick wood floors do not offer enough drag to trigger the overloaded flag. I don’t want to risk stripping the gears to test a full wheel stall.

bit 1 -- OVERLOADED - The motors aren't close to the target (applies to position control and dps speed control).
2 Likes
2

I still think a metal skewer and a couple of normally closed pushbuttons is a better design.

Viz.:

1 Like
3

“better” is dependent on the design criteria.

No cost, no parts from junkbox, no tools, no danger of hurting oneself, no ports, no mounting hardware/design, and universally implementable … could also be considered “keeping it simple”

2 Likes
4

Then there’s the “no strange new software to interact with other software and cause Dave to dance jigs instead of playing quietly” criteria - which you have already encountered.

In my case “push-button” was already implemented in the software.

For me, hardware solutions are (almost) always simpler and easier.

And even when I do use a software solution, (*i.e. multi-booting), I prefer a hardware interface, (dip-switches), to a software interface, (a screen menu), because I can then switch headlessly.

You’re right - it is a matter of what’s simpler for you and what you’re comfortable with.

Me. I like hardware.

Call it “old skool” if you wish, but (IMHO) a hacksaw is “simpler” than a full-blown dev environment any day of the week!
:wink: