Enhancement Request: Master Disable for robot motors

GoPiGo
1

Greetings!

Note: This also applies to any other Dexter 'bot with motors and wheels. (except maybe the GiggleBot).

Issue:
For the sake of argument, assume I want to play with the Remote Camera Robot code to make it easier to use and less “quirky”. (I’ve noticed some sensitivity quirks - especially after having traveled backwards.)

I would like to investigate this by modifying code and printing out variables, etc., to debug/troubleshoot this issue.

Obviously, I don’t want Charlie running amok while I do this. Also, placing Charlie upside down makes him dizzy and he has a tendency to vomit all over my desk. (just kidding!)

What I would like to be able to do is (somehow) disable the motors from running without disabling the API’s or functionality. IOW, if I command the motors to go “forward”, they would get the command to go “forward”, but just wouldn’t do it.

SparkFun’s micro:bot has a master ON-OFF switch to disable the motors while coding and debugging - which is a stroke of genius, IMHO. Of course, I don’t believe they have encoder feedback either. . . .

Is it possible to include a “motor_enable(bool)” feature that would inhibit all motor activity without having to pull out those pesky six-pin connectors?

Thanks - and a hug for all of you!

2

You can simply use the USB connector to power the robot, and remove batteries. The motors won’t run and you don’t need to change your code at all

1 Like
3

Not exactly, I’m afraid.

I can’t speak for the other sensors just yet - I am still playing with them and I don’t have the schematics in front of me - but the servos absolutelly don’t work w/o battery power.

I am making the, (perhaps silly), assumption that major functionality on the GPG-3 (first rev) boards won’t work without the batteries.

4

@jimrh

Can’t you do what 99% of the kids/teacher do: put the bot “up on blocks”? Just high center that baby and have at it.

Sorry, but it just seems you are asking for someone else to do something really, really complex to solve something you could solve simply.

And if you want to really learn about the GoPiGo and Python

  • make a copy of easygopigo3.py named sim_easygopigo3.py,
  • in your test code: change the “import easygopigo3” or “from easygopigo3 import EasyGoPiGo3” to
    “import sim_easygopigo3” or “from sim_easygopigo3 import EasyGoPiGo3”
  • in sim_easygopigo3.py add DEBUG = True and SIM = True
  • start adding lots of
if !SIM:
else:
   print "something:", somevalue

and when you like what you see, just remove the "sim_" from your code under test.
1 Like
5

That would be too easy!

Seriously - and as stupid as it sounds - I honestly didn’t think of that. . . .  Though one consideration is maintaining battery life.

Motors consume power, even when up on blocks and even when connected to ground-power or an APU to supplement local power.  And I’m planning on working for a while. . .  (Though, I did take everyone else’s advice and plug in a 5vDC/2-point-something amp “ground-power” source (grin!) while Charlie’s in the hangar and I’m messing with him, to extend the battery life.  Need the batteries for things like the servo’s and such.)

True, Oh Wise One!

This is part of the reason I wanted to find the True and Authorized Version of the library files.  I can copy-and-dink with them, knowing that they are the latest released revision and not some ancient artifact left laying around from The Dawn of Time.

I also had a similar idea - slightly different, I like yours better.

Right now, I’m doing some simple sensor coding to get my feet wet - kind-of a “Hello World” program for the servo and distance sensor.  What it does is:

  1. Center the servo to straight ahead.
  2. Start reading and printing the distance measured by the distance sensor.
  3. If anything gets within a specified minimum distance, Charlie prints “Yuck!  Too Close!” and turns his head away.  The direction he turns his head depends on where it’s currently pointing, center, right, or left.
  4. If I tap Charlie’s bumper, the program exits.

Simple, 'eh?  Not there yet, but I’m getting close.  This is something similar to a program I’ve already written in Bloxter.

6

I’m pretty sure you will learn they are all exactly the same, (if you didn’t dink with them), because DI uses automated build and test to publish these things. If you really can’t trust your system,

  • follow the good practice to NEVER change anything outside your /home/pi/ stuff,
  • keep all your stuff under /home/pi/
  • do a full DI update, (and reboot)
  • put a copy of DI stuff you are messing with in your local working folder
    /home/pi/Charlie/Stufff_I_am_trashing/
  • Always, Always, ALWAYS copy the closest DI …Examples/ or …Projects/ to your local dir and
    check that you have everything hooked up right, and to learn how the smart folks at DI work with that sensor.
1 Like
7

Likely, but I’d really  like someone at DI to verify/confirm that.

Or, I could do something really silly like: extract the egg to a file, find the others, and run 'em all through HashCalc and/or a good diff program.

Also:

  • Map a remote SMB share
  • Set a timer to some reasonable interval, like 30 minutes.
  • Every time it rings, stop everything and dump your work onto the remote share.
  • Reset timer
  • Get smart about it, create a script that runs every so often automagically, and creates a time-stamped zip/gz/7z file on the SMB share.
1 Like