The diagram shown in the “Lesson” panel for the IMU shows the IMU facing the opposite way.
This puzzles me because you went through Hell and Half of Texas to determine how to make the IMU work properly - and you discovered that the chip-side of the board had to face forward.
I have not seen any canonical literature on which way the IMU chip and/or the IMU board should face. This is important as there might be a driver bug in the current release.
Not really - The IMU examples have always had the chips facing the other way. I was having some difficulty stringing the cable having enough length, and wanting the board to be as protected as possible, and as tight against the holder, and I really didn’t think the compass was going to work near the motors and the spinning encoder magnets, so I chose to use only gyros and accelerometers, with which I could do a reset to heading of zero when on the dock.
What I “went to hell” with was the fact that DI changed the default for all I2C sensors to software I2C which killed Carl’s reliability. (Thank you for the html tip!) I ended up figuring out how to run the Distance Sensor in hardware mode and tolerate the software I2C errors on the IMU to give Carl a time-between-failure greater than six months!
My test of the latest PiOS Raspbian for Robots pre-release showed the same fatal I2C errors returned. I did not attempt to debug what changed. Perhaps they got rid of the hardware I2C mode, or changed the string that specifies hardware mode, or perhaps the software I2C mode is different on PiOS, or who knows?
I cannot debug that one, and I am doubtful that DI/ModRobotics will since the mean-time-between-failure seems longer than one battery session; (MTBF appears to be around three days). Carl is probably doomed to remain on the Stretch version of Raspbian For Robots - but he has not complained that he needs any new OS features. He just needs my attention to implement finding the lines in the floor and returning accurately from across the room.
IMU orientation, and “robot frame” references are community chosen. DI chose a different reference than ROS, and DI chose an IMU orientation that required a remap from the IMU hardware default orientation of horizontal with the arrow pointing forward.
When I started working with that OccuGrid example I found on YouTube, the frame reference difference bit me over and over, in so many functions that I eventually got tired of contorting my mind. I’ll get back to it some day, but frame reference corrections are endemic to robot motion computations, and we just have to wrangle them to our particular combination of hardware and code.
I have not played with the compass bot so I can’t speak to that. Eventually I will get there, but I already have two three major projects on my plate:
Testing this new release.
Figuring out how to implement tabs in Tk for the control panel.
(I really don’t know if I want to challenge porting to Qt. )
Continuing the joystick project.
The big problem with the GoPiGo is that there are SO MANY interesting things to do that it’s easy to get lost in a maze of “Wow! Let me peek at [insert interesting thing to mess with]!” to the point that you get nothing done!
Note that items 2 and 3 swap back and forth as I get frustrated with the current project.
P.S.
<strike> - </strike> work to create strike through text
Additional Update:
I have researched this problem and - in the words of development managers everywhere - “It’s not a bug, it’s a feature!”
No kidding, and I B.S. you not, it is an actual, honest to aggravationfeature in later versions of Firefox.
It is sufficiently annoying, and has the potential to affect other users, so I created a separate article on how to deal with it.
Viz.:
(Previous) Update:
I have determined that, on my system running Windows 10, while using the Firefox browser, the following functional states can exist.
If I have my Ethernet, (hard-wired), connection active and connected to the Internet, then the problem does not exist.
a. The “Log into network” banner does not occur.
b. The video window opens full-size and real-time video is present.
Note that the video frame-rate borders on unacceptably slow as any lateral or vertical motion produces significant blurring.
If my Ethernet connection:
a. Has the network cable physically disconnected
b. Has the network cable connected but the adapter is disabled
c. Has the network cable connected and the adapter is enabled, but there is no external connection to the Internet, (i.e. the router is disconnected from the modem, an external loss of connection, etc.)
Then the “Log into network” banner pops up, and the video is frozen.
This appears to manifest itself when an external internet connection does not exist, for whatever reason.
Note that my Firefox session has other tabs to external sites open. That may be part of the problem. If so, that may end up being a Firefox bug.
Can someone else try to confirm this behavior with Firefox open with more than one active tab to an external web site, and a tab open to the robot in stand-alone host mode?
Note:
Since there is a LOT of testing to do, and this will generate voluminous amounts of data, I am considering creating a separate test document outlining my findings and uploading it both here and to the MR support e-mail.
Pros: It will keep this thread from becoming twenty miles long and - essentially - unmanageable.
Cons: A lot of interesting, and potentially important, test data will be hidden in a document that most people will be unwilling to download and read as it is likely to be quite long.
After thinking about this, I am considering the idea of creating the document(s) noted above and posting an (ahem!) “Executive Summary” to the list. Anyone who is interested can ask for additional clarification.
What say ye? Opinions would be gratefully appreciated.
Additional test data:
Issue with Firefox and the “Drive” page. This appears to be related to the presence or absence of an active external Internet connection. This may also be related to the presence or absence of additional active tabs open as noted in the posting above. Note that this last observation is not yet clearly characterized and additional testing is required.
Test: Basic Scratch functionality:
Scratch ==> Open Examples takes you to a page containing example scripts, but double clicking on them does not open Scratch to use them.
Scratch ==> Open Examples, selecting a script, selecting “Open With”, and then selecting “Scratch” does not open Scratch to use them.
Scratch ==> Start Programming ==> Files ==> Open, navigating to the Scratch/Examples directory and opening one of the example scripts works.
Loading and running the GoPiGo_Basic_Test script as noted in #3:
a. The first time I ran it, commands to move the wheels did not work.
b. The second time I ran it, to verify the steps so I could document it here, commands to move the wheels actually worked.
Note that this requires additional testing to completely characterize. It may be related to the presence of external Internet, it may be a bug in Scratch, or it may end up being operator error.
Test: Bloxter Lessons.
Attempting to run the IMU tests disclosed a potential issue with the I/O port configuration panel:
a. If any sensor except the IMU are enabled and assigned ports, all sensors return active data.
b. As soon as the IMU is added, any existing sensor data showed on the I/O port configuration panel freezes. If the IMU is configured first, no data is ever shown.
Note that the IMU never shows active data.
c. Continued testing disclosed that the sensors were still active and that data could still be returned programmatically.
While running the IMU lesson or while programming in Bloxter:
(The program in Bloxter being, essentially, a duplication of the lesson.)
a. If the IMU is inadvertently assigned to the wrong port and the program started, the program correctly returns the error that the IMU could not be configured.
b. If the IMU is subsequently assigned to the correct port and the program restarted, the program produces no output whatsoever. There isn’t even an output screen. The program apparently goes into the “running” state and freezes solid.
c. In order to restore IMU functionality, the lessons or programming must be completely exited back to a parent window and re-entered forcing the I/O configuration panel to reset to defaults, and the IMU correctly assigned the first time.
Note that I did not try saving and restoring a program while doing this. My test recreated the program from a blank session each time.
There is no if-then-else block in Advanced Bloxter. However this program construct exists in Basic Bloxter. I suspect it was put in the wrong category by mistake.
The programmatic use of the “Test [condition], if true [do something], if false [do something]” construct in Bloxter is by no means obvious.
The “Test” block, (and possibly others) do not fully conform to the general expectation of a block-oriented language. (i.e. If the pieces can fit together mechanically, the statement is presumed valid.)
a. Parameters can be values, constants, logical conditions, or lexical logical conditions. All have the left-point jigsaw puzzle bulge.
b. Apparently the use of lexical logical conditions, (i.e. “if 0”, which should evaluate to “false”) are not allowed even if they appear to fit.
c. I suspect that this behavior is consistent with other block-oriented languages, though it’s confusing because the blocks appear to be able to fit.
d. It should be noted that Python, (the underlying language), allows lexical logical conditions as tests.
)