pi_sonar is nonfunctional for Pi4 rev 1.2 in 2020-11-07 image

[mjstn]

We have a Magni Silver show stopper on Pi4 on the 2020-11-07 image

I am unable to get the formulas used to fix 2020-02-10 image to work any more either on Pi4.
This formula did work back in July but I think submits in pi_sonar OR messing with pigpio changes
that happened just after Aug 2020 have broken sonar even on the 2020-02-10 image.

I know Rohan had a Nov or so new image but cannot contact him nor find a reference to that image.
That image MAY be the fix for this but in mean time customers have this fault and are on Forum now.

Here are my observations with 2020-11-07 image on Pi4 on a MCB rev 5.3

• 2020-11-07 trying to get pi_sonar to work: (All cases below are after enable of sonars in robot.yaml of course)
  • 2020-11-07 image (clean) does show node pi_sonar and all sonar topics show up.
    ZERO log errors but nothing is in the sonar topics
  • Tried pull of commit just prior to big-time pigpio lib sort of change. This ws
  • pulled pi_sonar of today, cmake and run and rosout.log now not even sonar topics show up
    last sonar log ends in 'Cannot initialize gpio'. Also, No sonar topics exist
  • switch to branch daemon_pigpio and same error of 'Cannot initialize gpio' Also pi_sonar node not starting

[mjstn]

Tried second Pi4 also on fresh 2020-11-07 image with same results.
To repeat this symptom: Node and topics exist but no publishing to topics about sonar.
Zero logs saying 'sonar' in rosout.log many logs in master.log at startup that appear similar to normal master.log output on sonar

MAJOR CLUE: On both of my Pi4 the v26 frontpi image works on sonars.

[mjstn]

So here is how I got this to work on Nov 2020 image, this may or may not be overkill but does fix this so I am going to post to forum if the pigpio experts see this as reasonable

sudo systemctl stop magni-base then these 3 basic operation (sorry for long lines)

A) wget https://github.com/joan2937/pigpio/archive/master.zip ; unzip master.zip ; cd pigpio-master ; make ; sudo make install
B) cd catkin_ws/src; git clone https://github.com/UbiquityRobotics/pi_sonar ; cd pi_sonar ; git checkout daemon_pigpio ; cd ~/catkin_ws ; catkin_make
C) sudo systemctl enable pigpiod

[MoffKalast]

Hmm I doubt all of that is needed. After all if you run sudo apt-get install pigpio it reports as installed at the latest version.

I've tested out a fresh image and another node that uses pigpio (since I don't have a sonar board) and it really didn't run at first. sudo service pigpiod status reports the service as offline. But if I run sudo systemctl enable pigpiod or your option C) and reboot then it works fine.

So yeah, we should make a PR to pi_image_build to add that line into the build script and also perhaps sudo apt install libproj-dev since the latest move_basic branches crash on compilation without it.

[anfederman]

Try commenting out: #ifdef arm

for some reason the #ifdef arm
is thinking the arm64 architecture isn't arm, I haven't had any problem with my noetic ARM32.

[MoffKalast]

Ah that makes sense, it's probably just armhf, we'll need to look up the preprocessor tag for arm64 and add an "or" in there. It would be helpful if you could make as a PR, Alan, since you're the only one who can test it right now.

[anfederman]

When you have eliminated the impossible, whatever remains, however improbable, must be the truth.

…

---- Attributed to Sit Arthur Conan Doyle in Sherlock Holmes stories.

On Sun, Apr 17, 2022, 9:16 AM MoffKalast ***@***.***> wrote: Ah that makes sense, it's probably just armhf, we'll need to look up the preprocessor tag for arm64 and add an "or" in there. — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHZ372ZB7EXNSVCJHXPULDVFQ2L5ANCNFSM4WQKXEEQ> . You are receiving this because you commented.Message ID: ***@***.***>

[anfederman]

I have this working now on a PI 4 1.4 ARM64. just commented out the #ifdef arm

So if somenone can verify this and figure out a workaround? I don't know why arm64 triggers bu arm32 doesn't, unless armhf is 'arm' and arm64 isn't.

[MoffKalast]

Assuming the tags from these answers are legit, then it may be possible to replace that line with something like the following:

#if !defined(__x86_64__) && !defined(__amd64) && !defined(i386) && !defined(__i386__) && !defined(__x86_64)

Instead of detecting the various ARMs, we exclude the common amd64 and x86 where it wasn't intended to compile.

You could also try if something like this compiles:

#if defined(__arm__) || defined(__arm64__)