A Raspberry Pi Pico based full sonar subsystem using HC-SR04 classic sonars

[Mark Johnston]

Ready to unveil a cool little project.   Some of you may know in the past I had done a subsystem using ST micro parts and up to 8  ST micro IR distance ToF sensors, the VL53L0X units.  That was a subsystem that talked to my ROS node that implemented the Range interface common for sonars.

So now I did on the Pico a PC board and Pi Pico 1st cut working firmware that implements up to 8 sonar units and like the other one replies with queries over serial at 115.2k baud with checksumed packets and what-not.

This board as shown in the picture also uses a fully OpenSCAD printed mount that holds the sonars vertical.    

Some care went into the top of the board 4 sonars cover a great deal of the front of the bot but to get all the way to 90 degrees I have 2 more sonars on the bottom so if this board is on tall enough standoffs the idea is you get 180+ degrees of sonar coverage.

I have not put this info or picture up on mark-toys.com yet but will get to it this month.

So as a preview here it is in this post.

I may post other info as far as what it takes to do Raspberry Pi Pico dev but need to gather my notes into a more presentable post for that so maybe later.

[Mark Womack]

That is pretty awesome, Mark.  Are you able to fire them simultaneously or serially or fire multiple but on different sides...?

-Mark

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/fd650a12-3013-4291-ade6-713cf2b96200n%40googlegroups.com.

[Mark Johnston]

I am not doing any fancy stuff yet except that I use both cores.   One core is the sonar scanning task and it simply runs through each sonar and populates a structure based on the distances for each sonar reply.   As is typical I watch for max delay or bad 0 delay and in those cases do not populate a reading.

The other task is what you may call 'main' and once a full command from uart has come in then main will lock the structure for sonars, grab copy of struct, unlock strucs then format a reply with a crc for the main host.   The host will see each distance in units of  mm over serial so I can have less bytes over the wire.  All messages ASCII so are human readable and easily parsable (by a geek) or simple code.

This does not reply in any ROS2 or rather 'microros' way but since I know there is microros on the Pico I will at some point make this thing be a microros node.  For now it is a serial slave with host using 115.2kbaud polling.     

Additional planned improvements are now all to be done in improved Pico software.   This is done in C (Not micro-python ... DaveC)  lol

[Chris Albertson]

I am trying to learn how to rogram the PIO.  These are very powerfull little devices, like 8 extra cores.   My first PIO project is to read a quadrature encoder.   Then I wanto to look at doing a Sonar controller in the PIO

A single Pico should be abler to run a complete base controller under micro ROS, I think running the sonar, bumper switches and motor control PID loops and so kind of LCD status/debug display.  All the fast real-time stuff could run in the PIOs.  

My goal is that all the sonar, bumper, odometry and twist messages go over one USB cable from Pico to RPI4.   Maybe IMU data too.  I don't know yet.       But I'm sure the Pico can handle it.

BTW I really like the idea of using a PCB to connect the Pico and sonar units.   I made one of those multi-sonar units and I don't like mine.  I used a wire harnes and it turns out to be a rat's nest of wire.  Even if the 3D printed housing looks good.   Here is what I did.   I think after seeing yours I can combine your idea and mine somehow 

https://a360.co/3feuZnU  

I'm replacing my Blue Pill boads with Pico. I think those PIOs are going to be very usful.

BTW, I found it's good to record the time the distance was measured as there might be a delay before batch of distance measurements are sent.   The rout planner can apply TF trasforms if it knows the time and "back out" the robot's motion.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/03fa7cbb-49dc-4e87-844d-d96b162dfc20n%40googlegroups.com.

--

Chris Albertson
Redondo Beach, California

[Mark Johnston]

Chris,

Im doing a bit of a chuckle now.   I thought about explaining the planned enhancements but it seemed too deep after I wrote it so I removed that and just said planned improvements.   It is indeed of value for time of each measurement and I have a plan for that.    Because this is a subsystem that is polled I am going to have different queries where one is simple with just ranges and another has a timestamp for each measurement.  The 'time' of a sonar measurement is interesting because sound moves so darn slow in terms of processors that you need to give time perhaps as the time the echo hit the object.  Sonars gets one measurement of ping delay so the time to hit the object is 1/2 of that.  Anyway, time will be a second type of query.

The PICO has I2C and even SPI and at this time one of those jacks is just a breakout of I2C but this subsystem could hold other devices as sort of an expander for switches or leds and other stuff.  Since the Pico has a LOT of pwm ability the ability to drive pwm to motor hardware or dimable lights or what-not would be other forms of expansion but at this time I'm keepin it simple here because sonar subsystem is a general piece usable in many robots.

[Steve " 'dillo" Okay]

On Monday, June 14, 2021 at 11:17:04 PM UTC-7 Mark Johnston wrote:

Chris,

Im doing a bit of a chuckle now.   I thought about explaining the planned enhancements but it seemed too deep after I wrote it so I removed that and just said planned improvements.   It is indeed of value for time of each measurement and I have a plan for that.    Because this is a subsystem that is polled I am going to have different queries where one is simple with just ranges and another has a timestamp for each measurement.  The 'time' of a sonar measurement is interesting because sound moves so darn slow in terms of processors that you need to give time perhaps as the time the echo hit the object.  Sonars gets one measurement of ping delay so the time to hit the object is 1/2 of that.  Anyway, time will be a second type of query.

Maybe I missed this somewhere in one of your messages, but I'm wondering how you're handling things like multi-path returns, carpeting, etc.

I've actually started to move away from sonars for my rover because I've found that they are unreliable  in "complex" environments for anything other than close-in obstacle avoidance. 

'dillo

 

[jsam...@pobox.com]

Chris, have you seen this code yet?

https://github.com/GitJer/Rotary_encoder

Maybe I will have to break down and buy a Pico. I didn't know the PIO existed.

Jeff Sampson

[Chris Albertson]

Yes, I read that a while back.   I think there is room to improve it.   It uses two interrupts per encoder and interrupts the CPU once per line crossing.   This does not remove much load from just doing the whole thing in the CPU.   But it is good proof it can be done.

Many ARM-M microcontrollers have built-in hardware quadrature decoders that are even better than the PIO.  They maintain a 32-bit register that the CPU can poll as it needs.  I'd like to do it that way with no interrupts.  Why? I have a four-wheel-drive robot chassis and at full speed, each motor makes 10,000 encoder line crossings for 40,000 interrupts per second.  Interrupts are expensive because each one requires the CPU to save its state on the stack.

Yes, buy the "Pico" for $4 but also Arduino is coming at "real soon now" with a board based on the same chip but with some excellent extras added:  (1) Bluetooth and Wi-Fi, (2) an IMU.    This could run a MicroROS base controller node.  The robot would be able to do basic driving on its own but connect to a navigation stack that runs on (say) a server-class PC that has a high-end GPU.  This reduces the cost and size of a ROS-powered robot to something that fits in your hand.

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/1390007404.547611.1623905408523%40mail.yahoo.com.

[Mark Johnston]

Steve:  Agree.  Sonars suck.   This particular subsystem is being done to be an alternative to an existing subsystem and not an upgrade.

Anyone who has placed complex things in front of a sonar OR even a piece of plywood at 45 degree angle knows sonars are a total brute force, but cheap approach.

I saw the Pico and was dyin to make SOMETHING so I wiped this up for kicks.   It's software has  'room for growth'  lol

I did it in this way so I could use either my ST  TOF board or this board with the same ROS node or perhaps only mildly hacked.

The tof thing is here on Mark-Toys.com of course:    http://www.mark-toys.com/ProximoMultiLidar.html

The Vl53L0x or even newer ones offer some distinct advantages over the 'classic sonar'.   They too have their 'flaky-isms' but I feel they are better, just shorter range.

Neither are ok for nav, stay with other better solutions like lidar and image and so on for nav.