The Real Skinny about the Raspberry Pi i2c clock stretching bug

Absolutely!

If I remember rightly, it defaults to AD1 if you don’t specify a port.

However, (IMHO), I think it makes the code easier to read, easier to remember what the heck is going on, and easier for third parties to understand - if I always specify the port, even if it’s the default.

No - nothing that sophisticated.

I was running a Bloxter program something like

"While" [true]  #Infinite loop
"Print" => "the IMU [aircraft heading]" on => "AD2" # heading in degrees
"Print" => "the IMU [compass heading]" on => "AD2" # values like "north", "south-east", etc.
# Implied "wend" statement because of the shape of the block

and then just let it run for a while, occasionally moving the robot around to see the readings change. If you don’t use a “sleep” block, it runs about every 0.5 or 0.25 seconds due to the built-in delay.

The closest I’ve gotten to “sophisticated” with Charlie is a program that moves Charlie forward until either:

  • He comes within “x” distance of an obstacle.
  • His front bumper hits something.
     

He then backs up for a second or two, randomly turns a number of degrees to either the right or left, and then continues.

He does no mapping. There is no instrumentation. No logs are kept, he just wanders around like a drunken robot until he gets too close to something, bangs into something or I kill his program at the web console.

It starts with a tight loop that tests the value of Charlie’s front bumper, waiting for it to go from “0” to “1”. Once it goes from zero to one, it jumps out of the loop and runs the rest of the program. This lets me start the program, place the robot on the floor, position it, and then tap the bumper to start the ball rolling.

Right now there are two random functions, one for angular rotation, (20 to 360) and the other for direction of travel. I’m thinking that I can do both in one random call by taking the integer value of the angular rotation and making it turn left if even and right if odd. Or, I just thought of this: constrain the angular rotation value to -360 to +360, and feed that directly into the command that makes Charlie turn.

One other thing I do is require a minimum amount of rotation, (I think ±20° to make sure he’s moved enough to avoid the obstacle by constraining the angular rotation to no less than 20.

This would be how I would do it if the rotation were constrained between -360 and +360:
(pseudo-code)

if (abs(degrees)) < 20
    if (degrees < 0)  # is the rotation angle negative?
        degrees = degrees - 20  # then add an additional -20 degrees
    else degrees = degrees + 20  # Otherwise the rotation is positive or zero
    endif
endif

 
This is fairly complex for Bloxter.

2 Likes

Actually quite sophisticated - Depending on the speed of that backing, is he backing sufficient for the clearance radius of a 180 degree evasion turn?

Carl’s clearance turning radius is around 140mm, 5.5 inches with all distance readings 75mm 3 inches from the turning center. At 150 degrees per second Carl backs roughly 85 mm per second which means a 1 second backing will allow safe 180 degree turns.

Charlie’s bumper might be a bit farther from the turning center, so Charlie is “ensuring safe evasion maneuvering” (If Charlie backs at the default 300 DPS, then for sure 1 second is “ensuring safe evasion maneuvering”)

1 Like

I haven’t. I’ve still been mostly running code from Hands on ROS, and I do have a copy of those libraries on my PC. But it probably would make sense to have an exact copy of my catkin_ws/src files. I’ll have to look at setting that up.

I looked at the GitHub versions of ros-gopigo. Looking at the commits, they had changed actually changed the default port for the IMU example (imu.py) from “GPG3_AD1” to “RPI_1”. I ran the “book version” of the program (which actually isn’t in the gopigo3_node but a different package called mygopigo) last night and it seemed to work fine. It still has GPG3_AD1 as the port (the book/mygopigo version is called IMU-sensor.py; other than the file name and the port it seems to be identical to the ros-gopigo version; another weird inconsistency). As I traced the files imported as modules for the IMU program through GitHub, it looks like di_sensors/inertial_measurement_unit.py actually changed the default port from “RPI_1” to “RPI_1SW” in the repository (and this is the version of the di_sensors file on Finmark - I checked). So now I’m thoroughly confused as to what the port should be called.

Yes - that’s right.

2 Likes

Good practice.

Sounds like a good “random walk” program.
/K

2 Likes

Right now, Charlie doesn’t care - the minimum turn is an enhancement I hope to program in.

Right now I have him back up a specified time or distance, (I don’t remember which), make the random turn, and try again. He either escapes or he doesn’t. If he does, golden! If he doesn’t, stinks being him and he tries again.

If he doesn’t turn far enough, or turns too far, he bumps into something again - or notices that he’s still too close - and tries again.

Even in Bloxter that’s a bit hairy and it is teaching/has taught me a lot about what makes robots tick in the real world.

Eventually I’ll be brave enough to try that in Python.

2 Likes

Nothing worthwhile was ever as simple as it seemed.

2 Likes

I don’t use Bloxter - I know some of these kind of block languages have an option to show what code is generated. Does Bloxter generate Python? Reviewing that would be a good way to start. And I suspect some things would actually be easier in Python because you’re not limited to the options available in Bloxter.

As for learning Python, there’s a lot of free online resources.

/K

1 Like

Yes it does and that’s one my sneaky tricks.

If I want to know if a particular piece of hardware works, I can throw something together in Bloxter and see it working - without having to worry about indentation levels or parentheses.

1 Like

Found this on the Adafruit site:
A visual i2c monitor that shows buss activity in real time.

2 Likes

@cyclicalobsessive,

Thinking about it, an i2c controlled power interface may not be that difficult to implement.

The big design questions are:

  1. How do we connect this device in series with the devices to be controlled?
    a. Two Grove connectors? (A pair for each channel.)
    Grove connectors will increase the size of the interface considerably.
    b. Smaller connectors on 0.1 or 0.05" centers?
    b. Sets of pin headers on 0.1 or 0.05" centers?
    Note that both of these solutions will allow the resulting PCB to be considerably smaller at the exxpense of wiring. One possible solution is to use Sparkfun-like Qwik connectors on the PCB and use Grove-to-Qwik cables to connect it.

  2. How many ports would be needed?

  3. Should the device also function as a i2c buffer? If so, how would A/D sensors/devices be handled?
    The easiest way would be to wire the connectors “straight-through” only interrupting the power lead.
    Another metthod, though more difficult, would be to specify certain connectors as buffered i2c connectors and others as wired straight through for A/D or un-buffered i2c.

  4. Would you want the device completely isolated? (i.e. break either both power-leads or break all four leads?
    Or, would it be sufficient to break just the power lead? (IMHO, the best and safest way.)

It might be possible to find a small microcontroller board that already has i2c capabilities and modify it.

Ultimately, it would have to be a custom PCB to reduce the size.

Way over my head to even know what the specifics need to be. I don’t know to answer any of your questions, especially since I don’t have a specific target device.

My original intention has always been to use the GoPiGo3 / DI sensors efficiently, coupled with using the microphone and pi camera efficiently.

That OAK-D looks like it would draw more than the GoPiGo3 I2C 5v lines have available, so it would need a lot of, lot of engineering for another tap off the batteries, another 5v switching power supply, and then the power switching function.

In all reality, Jim, I am “probably never” going to add a $300 sensor to Carl that takes all that just to put power to it only to find out that to really use vision with depth, I would have to reinvent Carl as a ROS bot, and end up wanting a Pi4 and bigger batteries, and now we’re no longer talking about little Carl - it becomes Carla the “Muscle Bot”.

At one point I was thinking that the HuskyLens might be a low current basic vision processor that I would only use for docking, but its functionality is so limiting that I think it will stay in my “failed toys” box.

2 Likes

Maybe a Pi-4 isn’t a bad idea, but I totally agree that loading up a GoPiGo like a DARPA experiment on steroids ultimately will be the worst of both worlds.

Thomas wants a 'BotZilla with dual NVIDIA Xavier Pro processors and the Lidar From Hell.

Me, I’m happy if my simple experiments don’t crash-and-burn.

I’d be happy to try and design you a switchable power source, but the ultimate direction and goal is up to you.

1 Like

The ultimate direction and goal: stimulating thoughts, conversations about those thoughts, and turning selected thoughts into actions which stimulate pleasurable thoughts.

More specifically, this week was filled with reading researchgate.net papers and searching github for:

  • Knowledge representation for robots
  • Intelligence without representation
  • Machine Consciousness
  • Natural Language Tool Kit, WordNet, Rule-based Chatbots
     
    (Thank you again for teaching me about &nbsp; - I just used it here.)
     

and coding:

  • healthCheck enhancements: added transient I2C failure detection (and delay before attempting the yet untested “reset GoPiGo3 board without rebooting”)
  • carl_chat.py: revisited my 2019 “Let’s talk about me [Carl]” NLTK based chatbot
  • keyword_chat.py: created to review using WordNet synonyms to spot user intentions in human-robot dialog
  • leds.wifi_blinker(): thread management to blink WiFi LED used when healthCheck finds swap space exceeds 60%

 
While I should be revisiting OpenCV and building a “Find Line and Follow It” program, I am distracted after adding speech reco to researching ways to imbue Carl with a more general dialog and voice action engine.

This then opened up the whole “Could Carl use knowing what he knows and can do?” (meta-knowledge) line of thought. This morning I read that new research shows Crows (corvids) can think about what they can do with what they know. This is meta-level thought.

And I keep remembering one of my “robot heroes”, Rodney Brooks and his subsumption robot architecture I built into my RugWarriorPro in the year 2000, that Carl doesn’t need (and in fact should avoid) an “all encompassing” knowledge (robot-model and world-model) to enable a reliable tolerance for reality.

Which brought me back down to earth with my goals for Carl.

BTW, no hard I2C failures in 8 days, and no intermittent failures in 4 days, so I have yet to be able to test the resetGoPiGo3 function I wrote.

2 Likes

This is why I think that we’d make a great team.

You come up with great software ideas and try to find the correct mix of hardware to balance it.

I come up with great hardware ideas and look for the correct mix of software to balance it.

It’s a pity that we’re located on two different continents.

I may, eventually, try to implement your addressable switch because I’ve been wanting to get back into low-level circuit design.

1 Like

Oooh!

You’re going to start a robot revolution!
[Insert flag with segmented, metallic snake with the words “Don’t Tread On Me!”]

How are you going to test it?
Deliberately fill swap?

1 Like

Getting real close:

“Hey Carl, Swap Space?”
“Swap Usage Fifty-Three Point Eight Percent”

Something is quietly eating chunks of swap space, but I don’t have the chops to figure out what, nor fix it if I figured it out!

2 Likes

How Linux uses swap is way over my head. But from a practical standpoint, does it matter? Is it affecting performance somehow? Not trying to be confrontational - I’m asking for my own edification.
/K

2 Likes

At some point the whole system slows to a grind and stops responding to my ssh remote command line, so for the time being, I am just going to set the WiFi light blinking when it gets over a “still working threshold”.

2 Likes

Yeah - that would definitely be a problem.
/K

1 Like

Aren’t there memory/swap management/debugging utilities out there you can use to chase this down?