Sonar Board Test fails:

Ref: Verification topic 3, section 4.2 Sonar Board Test:


rostopic echo /pi_sonar/sonar_3
rostopic echo /sonars

no display/just sits there with a blank line until ctrl_C

Previously: sudo nano /etc/ubiquity/robot.yaml

Current contents:

Robot Configuration

Next stmt modified 05/22/2020 by Ed Seymore

raspicam: {‘position’ : ‘upward’}

raspicam: {‘position’ : ‘forward’}

Next stmt commented 05/22/2020 by Ed Seymore

sonars: None

Uncomment next stmt 05/20/2020 by Ed Seymore

sonars: ‘pi_sonar_v1’ # Use this to enable sonars


To help me understand some other things can you tell me if the blue LED on the sonar board blinks on your sonar board? That is the WiFi led. This will help med in what direction we go for debug.

Also please look at each Sonar the how it is soldered into the odd shaped sonar board and look for any broken posts for one or more sonar units. Each little board has 4 connections.

In the mean time I will refresh my memory on issues that could lead to sonars not publishing to the sonar topic.

1 Like

I’m going to mention something else but I don’t think it is your problem. Just an FYI ‘just in case’.

We have had several issues where the robot.yaml file is very particular about spaces and speicial characters. Below I past what I see in vi using :set list which shows ALL chars visible or not. $ is of course end of line. We do know and try to warn everyone that fields in the file must have a space between them so there must be a space after sonars: and before the single quote.

Robot Configuration$

raspicam: {‘position’ : ‘upward’}$

sonars: None$

sonars: ‘pi_sonar_v1’ # Use this to enable sonars$

And this same file in hex dump with chars also showing.
Sorry I have to do this but we would like to know if there is some format issue so we can improve our documents and explain to others if what you are seeing is related to some tiny little format issue.

$ od -xc /etc/ubiquity/robot.yaml
0000000 2023 6f52 6f62 2074 6f43 666e 6769 7275
# R o b o t C o n f i g u r
0000020 7461 6f69 0a6e 720a 7361 6970 6163 3a6d
a t i o n \n \n r a s p i c a m :
0000040 7b20 7027 736f 7469 6f69 276e 3a20 2720
{ ’ p o s i t i o n ’ : ’
0000060 7075 6177 6472 7d27 0a0a 2023 6f73 616e
u p w a r d ’ } \n \n # s o n a
0000100 7372 203a 6f4e 656e 730a 6e6f 7261 3a73
r s : N o n e \n s o n a r s :
0000120 2720 6970 735f 6e6f 7261 765f 2731 2320
’ p i _ s o n a r _ v 1 ’ #
0000140 5520 6573 7420 6968 2073 6f74 6520 616e
U s e t h i s t o e n a
0000160 6c62 2065 6f73 616e 7372 0a0a
b l e s o n a r s \n \n


1 Like

On power up:

Facing the front of Magni:

right sonar LED (LED1) comes on dim, goes out and then blinks bright for
awhile then goes out.

All Ping connection solder joints look good.

Modified robot.yaml to match your sample lines.
The end of line on the last line may be significant.

sudo nano /etc/ubiquity/robot.yaml

Robot Configuration

raspicam: {‘position’:‘upward’}

Next stmt commented 05/22/2020 by Ed Seymore

sonars: None

Uncomment next stmt 05/20/2020 by Ed Seymore

sonars: ‘pi_sonar_v1’# Use this to enable sonars

Now a power light is flashing.
I may need to recharge the batteries in order to test the change.
Will update results later.
Thanks for your help.

I do not think changing the robot.yaml file has solved my problem:

Not sure since, I do not know how to see the raw characters.

I would like to share a couple of thoughts:

I am new to everything about Magni: hardware, OS and ROS and therefore a steep learning curve.
But, driving with Logitech controller works, driving with keyboard works, running with python script works.

I have had Magni (with batteries) since 05/17/2020. So, eleven days and not sure why Magni wants to run over things! I bought Magni because of its strength. But, I want it to be safe to use.
Not a criticism, just an observation and a function of were I have been spending my time.

So, a couple of questions:
Q1. Is it OK to continuing to explore the code while charging?
A1. Sure hope so since that is what I am doing right now.

Q2. How should I know when the batteries are completely charged?
A2. Very clear when charge complete: fan stops and LED2 is green.

Q3. Are the raspicam and sonars values available to display?
I can use rosparam get /ubiquity_robot_mode to see mode of operation and
I can use rostopic echo /battery_state to check charge level and
I can use rostopic echo /sonars (when it is working)
Is there a way to display the values of raspicam and sonars other than
looking in robot.yaml?

Q4. Is there a way use the SSD1306 OLED Display provided?

Q5. What does /pi_sonar (http://Magni.local:42763/) mean after running rostopic info /sonars?

For new users (for me at least) if would be useful to have two functions available on day one:

CheckStatus - display battery level, camera orientation, sonar active.
CheckSafety - battery level is safe, no obstructions in path

As for now, it is still a mystery to me why rostopic echo /sonars just hangs.

Hi Ed,
No problem, understand fully. More than one robotics trained friend of mine and myself all claim that learning ROS is not a ‘learning curve’ it is more like a ‘Learning Cliff’. Lol.

A1) Yes it is ok to explore and even change code and do makes with charger plugged in. If you know you are offline for any real driving here are a couple things to help faster compiles and so on:

  • Use ‘sudo systemctl stop magni-base’ while developing so you will have all the cpu to do dev and especially compiles (catkin_make).
  • Not sure what image you have on the Pi but if you use ‘catkin_make -j 1’ that will assure that you do not run out of memory because some expensive makes can run out of memory and get very stuck for even an hour. The -j 1 sets resources for the make that will not starve the poor Pi3 of memory
  • If you know you are not using magni to drive around your battery life will be longer if you release the red button when just doing makes and so on and this also will assure no runaway robot (not sure how you are hitting that and will explore that later)

A2) Yes, green light goes on on the charger. Also /battery_state topic (IF magni-base service is active) will show battery voltage.

A3) Once we sort out why sonar is not active, yes using ‘rostopic echo /sonars’ will be extremely active and show all working sonars (for good board that will be all 5).
Other parts of this question I am not clear on, re-phrase and I’ll have another go at the robot.yaml part of the question

A4) We are just gearing up to have another image that will support the OLED display and after that we have plans for showing more on it than the default. If you want to mess with that right now you have to get a little bit more into ROS and the catkin_make thing and git but here is the page I wrote (I wrote the driver for that OLED display so I can be blamed for all it’s faults LOL)
I talk about the display here:
In order for that stuff to work you have to be logged in and cd to ~/catkin_ws/src then pull the repo using this command ‘git clone’ That will pull source code. Then go back to catkin_ws and do another ‘catkin_ws -j 1’ after that the directions on the page can be done to make it run the display.

I’m going to get back to this post, have to be somewhere for now but take a look at above and we can move on later tonight.

1 Like

This part of the reply is focused on helping to get the sonar board issue diagnosed so you can use it.

I am positive the sonar board is broken OR the large 50 pin cable is not right or badly manufactured.

The /pi_sonar ROS node would not have started if the robot.yaml file were not indicating to start sonars

The ribbon cable is shown nicely in the last 3 pictures on this page:

One issue that we have seen at least a few times before is that the 50 pin ribbon cable looks to be plugged in but in fact is not making full contact.


Look very carefully at how far the cables have to be inserted. It can be hard to do with 50 pins and several times the issue with sonar board has been the cable was just not all the way inserted.

For Q5 here is A5:
The ‘rostopic info /sonars’ shows who produces messages to the ROS topic of /sonar.
The line you show indicates that a ROS node of name pi_sonar is the only ROS node to publish to /sonars.

Thank you for your inputs on the CheckStatus and CheckSafety ideas. I like the idea too.

A few nice and simple things like you suggest would be good.
I do want to make sure you know about a page written to do verifications on the Magni.
Some of them are more deep than others but there is a lot of good stuff here

Get back to us here after looking into the cable insertion or your cable not looking like the one in the pictures.

Stay Healthy,

1 Like

I have done a visual ckeck: The cable appears to be well seated at both ends.

I have applied pressure trying to seat both cable ends: no movement.

I removed the sonar board and did visual inspection: I see no damage.

I notice two switches and two LEDs on the sonar board: LED1 seems to be working as described in the tutorial. Is there a test program to check the other LED and the switches for a connection?

BTW: There is another issue. When I performed the Pi Camera installation, I sent an email to support to report that the camera cable was a little too short to be installed as shown. I routed it behind the camera rather than through the slot as shown. The Pi appears to have two camera ports and my Magni came with the camera cable plugged into the far connector rather than the one nearest the camera itself. The RaspiCam passed the verification test (4.1).

It would be best to have camera discussion on a new entry. This helps us find things later.
The camera must be plugged into the port near the lan jack and the blue tape on the side of the lan jack. The other jack near the SD Micro card is for a display so do not put camera in that one.
I use all sorts of different lengths on the camera cable so don’t know the actual length of the one that ships. When you open the new entry on the forum here with title for camera cable too short can you please specify the length of your cable? Yes it is very tight. I usually have cable in Pi then run it through the slot to camera. I agree, it should be a cm longer and maybe 2cm. I’ll ask for this. I think it is the stock cable we use that comes with the camera but am not sure.

The other led and the switches are not related to sonar board features. It would be useful for you to know that the SW1 switch acts and does a shutdown for the Pi for a clean shutdown.

I’ll get back to the sonar board here later today after I research what sort of logs may happen if there is a failure.

1 Like

Ok, back to sonar debug.
I disconnected the sonar cable and see what I think you are seeing but please verify.

rosnode list will shows one line with /pi_sonar
rostopic list will show /sonar topic and the separate ones below but all will be idle

Next type (enclosed in backquotes for this please) cd roslaunch-logs
(This is a nice little trick to get you to the log folder for the current ROS session)

If you do an grep sonar *.log command you will see many lines that contain sonar and the last line will be very long but at the end will say ‘Sonar node ready’

If you see all of this then the GPIO lines from the raspberry Pi will be actively sending ‘trigger’ pulses to each sonar unit on the pin the little boards say ‘trig’ on in silkscreen.

So the ‘ultimate’ test here would require an oscilloscope OR even just a voltmeter if you have that. What would be done is to pick one or two of the little boards and measure the voltage on the two outside pins (pin 1 and pin 4). If you do not see 5 volts we have a major clue.

The sonar board is all totally an extension and almost like a ‘Raspberry Pi Hat’ sort of concept. We supply 5V to the sonar boards and then we exercise the ‘trig’ pins and wait for the ‘echo’ pin to tell us how far for that sonar. There are gobs of Arduino DIY projects on web that show how to run these HC-SR04 boards. So if you do see 5V is a major clue. If you had an oscilloscope you would see very thin trigger pulses on a working system going to the ‘trig’ pins of each sonar.

I have manually tried removing one or even two sonar units and the code still reports the units that work.

If you see the 5V on the sensors we have to start suspecting the Raspberry Pi image in use and after that the possibility for broken GPIO pins on the raspberry Pi.

There is really very little going on on the sonar board as it is in itself a ‘dumb’ board that just connects to GPIO pins on the pi

Let me know what you find.

1 Like

Oh crud. This forum removed the ‘backquotes’ from around the word roslaunch-logs. If you just type roslaunch-logs you will see the oddly named directory where the logs are and can then cd to that if you don’t quite get what I am talking about with back quotes. Back quotes in linux deliver the text that the stuff within the backquotes would deliver to the screen and thus is a shortcut sometimes.

1 Like

ubuntu@Magni:~$ rosnode list
ubuntu@Magni:~$ rostopic list
ubuntu@Magni:~$ roslaunch-logs
ubuntu@Magni:~$ cd /home/ubuntu/.ros/log/baecae84-a27d-11ea-b852-d5c6e1ed853b
ubuntu@Magni:~/.ros/log/baecae84-a27d-11ea-b852-d5c6e1ed853b$ grep sonar *.log
master.log:[rosmaster.master][INFO] 2020-05-30 13:59:52,569: +PUB [/rosout] /pi_sonar http://Magni.local:37395/
master.log:[rosmaster.master][INFO] 2020-05-30 13:59:52,576: +SERVICE [/pi_sonar/get_loggers] /pi_sonar http://Magni.local:37395/
master.log:[rosmaster.master][INFO] 2020-05-30 13:59:52,579: +SERVICE [/pi_sonar/set_logger_level] /pi_sonar http://Magni.local:37395/
master.log:[rosmaster.master][INFO] 2020-05-30 13:59:52,595: +PUB [/sonars] /pi_sonar http://Magni.local:37395/
master.log:[rosmaster.master][INFO] 2020-05-30 13:59:52,600: +PUB [/pi_sonar/sonar_0] /pi_sonar http://Magni.local:37395/
master.log:[rosmaster.master][INFO] 2020-05-30 13:59:52,604: +PUB [/pi_sonar/sonar_1] /pi_sonar http://Magni.local:37395/
master.log:[rosmaster.master][INFO] 2020-05-30 13:59:52,607: +PUB [/pi_sonar/sonar_2] /pi_sonar http://Magni.local:37395/
master.log:[rosmaster.master][INFO] 2020-05-30 13:59:52,610: +PUB [/pi_sonar/sonar_3] /pi_sonar http://Magni.local:37395/
master.log:[rosmaster.master][INFO] 2020-05-30 13:59:52,614: +PUB [/pi_sonar/sonar_4] /pi_sonar http://Magni.local:37395/

All five sonar sensors have 4.98 dcv on two outside pins.

You have inspired me to add some additional debug information in our pi_sonar node. More on that later today.

For now can you save into a file the output of our /diagnostics topic?
Do this command for 5 seconds then hit Control-C and return the part of the file that has all the pi_sonar output please.

rostopic echo /diagnostics > diagtopic.txt

The file will be loaded with a lot of stuff that keeps repeating so what we really want is the part discussing pi_sonar which you can cut out and paste here.

OR even better send the entire file to me using and in subject please put attention Mark

Thank You,

1 Like

I should ask something very fundamental actually. Does your magni have a Pi3 or a Pi4? A Pi4 will have two of the USB jacks be blue plastic tab in the jack. Thanks.

1 Like

My Magni has Pi4.

Also, I compared the results of running 2020-02-10-ubiquity-xenial-lxde-raspberry-pi.img (on a Pi3B+) and the SD card included with Magni (on included Pi4):

2020-02-10 displays: Ubuntu 16.04.6 LTS (GNU/Linux 4.19.50-v7+ armv7l)
Magni displays : Ubuntu 16.04.6 LTS (GNU/Linux 4.19.50-v71+ armv71)

I sent the diagtopic.txt file as requested.
Not sure it will be readable. Seems ubuntu and Windows have a difference of opinion on how to best store text files.

I do not see any reference to sonar in the diagnostics output.

Also: started getting repetition of messages after roslaunch magni_demos simple_navigation.launch.

[ INFO] [1590941114.402642687]: Move Basic ready
[ INFO] [1590941114.456054356]: Load map /home/ubuntu/.ros/slam/map.txt
[ INFO] [1590941114.461314122]: Load map /home/ubuntu/.ros/slam/map.txt read 1 entries
[ INFO] [1590941114.491158903]: Fiducial Slam ready
[ INFO] [1590941114.771563366]: Aruco detection ready
[ INFO] [1590941114.774333341]: splitter component done

[ INFO] [1590941114.868826579]: camera calibration URL: package://raspicam_node/camera_info/camerav2_1280x960.yaml
[ INFO] [1590941114.949796591]: Camera successfully calibrated from default file
[ INFO] [1590941114.950042535]: using default calibration URL
[ INFO] [1590941114.950820255]: camera calibration URL: file:///home/ubuntu/.ros/camera_info/camerav2_1280x960.yaml
[ INFO] [1590941114.951142384]: Unable to open camera calibration file [/home/ubuntu/.ros/camera_info/camerav2_1280x960.yaml]
[ WARN] [1590941114.951331532]: Camera calibration file /home/ubuntu/.ros/camera_info/camerav2_1280x960.yaml not found.
[ INFO] [1590941114.951855327]: No device specifc calibration found
[ INFO] [1590941115.057634242]: Starting video capture (1280, 960, 80, 10)

[ INFO] [1590941115.058256444]: Video capture started

[ INFO] [1590941115.532037411]: Got image 1
[ INFO] [1590941115.870808866]: Detected 0 markers
[ INFO] [1590941115.926821788]: Got image 2
[ INFO] [1590941116.164662797]: Detected 0 markers
[ INFO] [1590941116.191520660]: Updating map with 0 observations. Map has 1 fiducials
[ INFO] [1590941116.238987954]: Got image 3
[ INFO] [1590941116.486722421]: Detected 0 markers
[ INFO] [1590941116.491501428]: Updating map with 0 observations. Map has 1 fiducials

Therefore, run rostopic echo /sonars in a second terminal.

My conclusion: sonars are not publishing.

Something has been found due to some recent changes and is being addressed. It will take a couple days but a reply will show up back here once it makes it far enough along so you could pull the fix. Sorry for this issue. Thank you for reporting it.

1 Like

Hi, I think I’m having the some problem with Sonar, I also have an Rpi4. What was the change required?

@mjstn2001 any updates? I noticed that around the time of your posting the pi_sonar repo was updated, did you push the changes there?
I did an apt upgrade though so surely I’d have the latest pi_sonar drivers?