When trying to test the sonar sensors using rostopic echo /sonars, the command seems to return no information. Because of this the cones for the sonar sensors do not display in Rviz. I have tested the board to see that 5V is across each sensor and I’ve disconnected the centre standoff so that only the four on the sides are there.
When i execute the command rostopic list the following topics do appear:
Job for pigpiod.service failed because the control process exited with error code. See “systemctl status pigpiod.service” and “journalctl -xe” for details.
After looking at “systemctl status pigpiod.service” i got the following:
Jan 21 16:06:04 ubuntu-VirtualBox systemd[1]: Starting Pigpio daemon…
Jan 21 16:06:04 ubuntu-VirtualBox systemd[1]: pigpiod.service: Control process e
Jan 21 16:06:04 ubuntu-VirtualBox systemd[1]: Failed to start Pigpio daemon.
Jan 21 16:06:04 ubuntu-VirtualBox systemd[1]: pigpiod.service: Unit entered fail
Jan 21 16:06:04 ubuntu-VirtualBox systemd[1]: pigpiod.service: Failed with resul
Im not sure if this is the cause of my issue. Also I am unsure whether this must be executed in the catkin_ws or not.
Hello,
There is something wrong, I agree. Lets debug it.
Please tell me if you are running a Pi4 or a Pi3 host processor.
Use this command: sudo cat /proc/cpuinfo
Paste the very last line back to here because there is a Rev 1.1 and a rev 1.2 for the Pi4.
The line will be something like this:
Model : Raspberry Pi 4 Model B Rev 1.1
For a normal magni the ros log will at an early point say this ‘Pi Sonar node ready’
Obviously you will not see this. Please when the robot is running edit from /home/ubuntu the current ros log which is .ros/log/latest/rosout.log Then search for ‘pi_sonar’ or even ‘sonar’. Use case insensitive search just so nothing is missed.
Report back any sort of sonar lines which if not saying the node is up it is debug info.
Whenever you start ROS a new set of logs get generated in home folder under .ros/log
The directory names are long unique strings so there is a shortcut setup for current log.
This folder holds the latest or current logs on magni: /home/ubuntu/.ros/log
Instead of editing just now lets just search the main log called rosout.log for sonar info:
grep -i sonar /home/ubuntu/.ros/log/latest/rosout.log
For the ros log you can edit it I will use vi below but you may replace ‘vi’ with nano if you like that more.
vi /home/ubuntu/.ros/log/latest/rosout.log
I’m going to try to setup a system like you are running and use the 2020-11-07 for Pi4 image.
I do recall some issues with Sonar and Pi4 that had to do with GPIO but I was not doing that work so I do not recall what the resolution was on all that. There is some sort of forum thread that is sort of long that was all about that.
I am contacting the expert on that issue to find out and post back to here.
It may have been that to get it all going you may have had to do the full ‘sudo apt-get upgrade’
So if you want to give that a go or wait, it is your option.
WARNING the process to follow is a couple lines and is here:
Also that upgrade can reset your settings that you may have made in such files as base.yaml
So suggest take out sd micro card you have now and get new and clean image of the 2020-11-07 image. Them bring it up and do the full updating on above web page of our ‘learn’ doc site.
For those who wish to verify for me this is how I have fixed this.
I do not claim to be ‘expert’ but everything I do below seems ‘reasonable to me’ and fixes sonars.
I cannot vouch for if it breaks some other GPIO related things so that will await more tests.
Start with a CLEAN burned version of our 2020-11-07 image. Don’t try to do this on some image
you have been messing with to try to get sonars to work.
You of course must enable sonars in /etc/ubiquity/robot.yaml since it is new image.
So as a ‘beta fix’ for experimentation do these thing all from perhaps /home/ubuntu
sudo systemctl enable pigpiod
sudo shutdown -r now
Let me know how it goes, I am going to look for things it may or may not have broken because remember this is messing with GPIO and that can be used in many ways.
UPDATE:
I have found that the semi-complex step pulling master.zip is not required so that helps.
Thus just do the pull of pi_sonar to the branch specified and the enable of pigpiod and that may be all there is to it.
Again, I am calling on interested parties to try to test and help prove this and we will all get to the end goal of sonars all ok on Pi4 faster. Thank you for any assists.
When using grep -i sonar /home/ubuntu/.ros/log/latest/rosout.log command to search the log files for sonars, it returns nothing.
When I get the opportunity I will try using a clean burned version of the 2020-11-07 image and the commands you suggested. Will report back to you when if it works or not.
Could it be that one of the components on the sonar board have shorted due to the centre standoff having been there when the magni initially started up? even though the Voltage across the sonars is 5V?
UPDATE:
now when I type rostopic list the following no longer appears
Ivano: Just to be complete I am wondering if after you came up on the new image with all the changes that you can check these things:
/etc/ubiquity/robot.yaml no longer has the line that says ‘sonars: None’ and that it does have a line that says: sonars: ‘pi_sonar_v1’
There must be a simple space (not a tab) between the word sonars: and the single quoted rest of the line.
Given above is true type this line so we can verify the pigpiod service is running:
ps -ef | grep pigpiod
There should be 2 lines. One shows the grep command in progress but the other line must be present to show that pigpiod is in fact running. If you don’t see pigpiod running
You had a question on the File exists message and I do not know why that is happening. Part of the start command creates a symbolic link so I was thinking doing it a second time may lead to above error but my system does not do that so I don’t have an answer.
I did a reboot after all that stuff because a few of those things like the service would not start till next reboot.
Notice I did an ‘update’ stating the first set of steps involving the ‘wget’ and make and install do not appear to be required for our 2020-11-07 image although that was the formula I used.
Do start whatever you do for these updates with the ‘sudo systemctl stop magni-base’
and then when done a reboot (shutdown -r now) is required.
You also discuss that the standoff was present at an earlier time. That situation is know to lead to damage. So I am now on the path of deciding if the sonar board or the gpio pins leading to it from the Pi4 have been damaged.
I wish to simplify this situation. You appear to be showing me output with a lot of things going on that are not part of the standard basic just after boot configuration. I see move_basic for example and some sonar topic remaps.
Can you please not launch your own files and then show me the output from the grep of master.log?