ExampleBot Subsystem design

[Mark Womack]

So, I was thinking about the current design of the ExampleBots where there is a microcomputer running ROS2 (assumed to be a Pi 4 at this point) and a microcontroller handling all of the low level sensors, motor driver, power management, etc (assumed to be a Teensy 4.1 at this point). And I was thinking about micro-ROS or not micro-ROS...and all this led me to rethink the microcontroller and the lower level systems. I wanted to pass it by the group.

What if each subsystem (ie distance sensors, surface sensors, motor driver, power info) is it's own self sufficient component? Each with its own microcontroller written to manage it's low level components. There would be no single microcontroller to be a bottleneck, just like in other discussions Camp has multiple Pi 4s running, each with a specific responsibility (and presumably all tied together over ethernet). There would be multiple microcontroller.

At this point, let's assume they are running micro-ROS. It provides a ready, ROS approved way of allowing each microcontroller to define publishers for the data they are collecting. And in the case of the motor driver it would subscribe to cmd_vel for motor control. The subsystems wouldn't be connected to each other, they would be independent. They could publish/subscribe messages if inter-component communication is necessary.

The Teensy 4.1 has support for direct ethernet connections, but might be a little overkill as an overseer of just one component. Teensy 4.0 is smaller and is the same size as the lesser Teensys, so.. why not? But with no ethernet support, each Teensy would need to connect via USB serial instead. There are each converters between TTL serial and USB serial, some built into the USB cord itself. And USB is used by the RealSense and Lidars, so it should be fine for our subsystems as well.

Instead of using micro-ROS at the microcontroller level, we could look at defining our own serial protocol that a custom ROS node read and then translates into messages for the topics. Doing this would mean that almost any microcontroller could be used at that point, not just the micro-ROS approved one.

Each subsystem could be developed and tested independently of everything else. It also means that different implementations of the subsystem could be swapped in so long as they match the set of messages and topics expected. Bart could have one hardware/software implementation for distance sensors, Homer could have a different hardware/software implementation. But with the same topics supported and messages generated.

I guess this sounds like a "duh, it's ROS stupid" sort of moment. This is exactly the kind of design that ROS is supposed to foster and support. I'm feeling that this is the most "true" to ROS kind of design that the ExampleBots should demonstrate. It might be a little much to have 3 or 4 Teensys, so design and write the code so that subsystems could be "grouped" on fewer controllers.

Thanks for reading, would like your opinion. Sorry if this "breakthrough" seems obvious to everyone.

-Mark

[Wayne C. Gramlich]

Mark:

I had this idea back in the late 90's. I called them RoboBrick's. Bill Benson
and I published our results in some of the early issues of Servo Magazine.
Back then the Basic Stamp was the king, so they were organized in a star network
that the Basic Stamp could poll. Each of the slave devices were PIC12's
and later on PIC14's.

Later on we switched to bus network using serial line protocol with CAN bus
transceivers. (CAN bus is slightly better than RS485, since you don't need
a direction pin on the transceiver.)

There still needs to be something that talks to the devices. There a
protocol is needed, error detection, correction. Some people like CANBus,
but it has its issues as well.

When I tried micro-ROS, I bounced. The documentation was weak. Some
people have gotten further than I did. My problem is that people still have
to write and debug some pretty seriously complex software on the micro-ROS
microcontroller. This is not particularly easy.

It is actually a good idea. It lets each person design their own board
using their own personal favorite microcontroller and plug it into the
communication fabric.

Getting people to agree on the details is very challenging.

Regards,

-Wayne

[Bob Smith]

On 1/14/22 2:37 PM, Mark Womack wrote:

> What if each subsystem (ie distance sensors, surface sensors, motor driver,
> power info) is it's own self sufficient component?

Mark
As Wayne mentioned, this was the basic idea of Wayne's RoboBricks.
It was then, and still is, a good idea. His use of RS485 or CANbus
lowers the cost of each board. Being able to daisy-chain the boards
makes interconnect really easy. You might ask Wayne about some of his
designs.
ROS on the boards would be overkill I think. Use a Raspberry Pi for
the interface to CANbus and his existing protocols. You'd have to be
able to multiplex the various boards out to different ROS nodes. (You
might be interested in https://github.com/bob-linuxtoys/eedd for a
start on the daemon.)


BTW: RoboBricks were the direct inspiration for my FPGA stuff. Instead
of CANbus and a daisy-chain, I hang peripherals off a Wishbone bus in
the FPGA and have a daemon that interrogates the FPGA to find out what
peripherals it has and then loads drivers for the list of peripherals
it finds. The daemon becomes the interface/multiplexer to the various
ROS nodes.

Bob

[Charles Sun]

I like the idea of an open-source ROS2 HBR ExampleBot as a group project.

My general suggestion:

1. Reusable/Extensible. not just for a single function or purpose.    

2. Easy to source.  No custom PCB boards, hard-to-find parts.

3. Complete, up-to-date documentation in one Github repository.

4. High fidelity simulation environment with full sensor support. 

Charles

--
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/CAF-TXgvRdX9tY2EfGBspxja%3DViinWaX6i%2BfG_hsj2B8HbHjtvw%40mail.gmail.com.

[Mark Womack]

Charles, 

Welcome to the discussion and design! 

I completely agree with everything you outlined, and most are part of the fundamental guidelines for the project. You can find them in this document.  There is also a design document here, but it is in much rougher condition. (Please feel free to suggest any edits in those documents, it is open to comments and suggestions.) We didn't include any mention of github because that has been assumed. At some point we are going to create the project and start organizing and checking stuff in. Camp has been playing around with simulation and I'm behind in working on it, but it is fundamental to the project. Even though I am going on about the design of the components and subsystems, I'd love to see the code and specification working in simulation before any physical robot is built.

We'd love to have you working on this project with us, the more the merrier!

-Mark

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

[Mark Womack]

Wayne and Bob,

Thanks for all this. I'm glad that you agree with the overall direction and sentiment. I do agree that micro-ROS seems a little overkill for these lower level systems. The reason I am leaning into them at the moment is because it ties the microcontrollers into the ROS environment very completely. While I am thinking we don't need to have a RTOS or anything like that, just a simple Arduino-like setup, micro-ROS allows one to subscribe, publish, see parameter changes, etc. We wouldn't have to jump through hoops or have limitations. And since the ExampleBots are all about ROS and ROS2, it just seems like we should check it out thoroughly.

I've been looking at some of the micro-ROS example code, and I dug into their transport layer a little bit (I even filed a bug for the default impl to not assume Serial...). The calls themselves seem pretty straightforward for the Arduino library. They can support serial, ethernet, and wifi for the transport. Of course, it requires a micro-ROS node on the Pi to manage the transport back and forth, which they provide.

That said...I think a first order activity would be to run some performance tests of micro-ROS and non-micro-ROS. Publish/push messages from the microcontroller to ROS on the Pi and see what the msg rate is on the topic. Mike Wimble has some code he uses to push data through using a JSON structure, I was going to ask him if he would mind providing it as the non-micro-ROS starting point. But I'm interested in other options, like CANbus, if they make sense. Any code pointers?

-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/8387e012-489a-9ed7-3705-ee553dbb20aa%40linuxtoys.org.

[Wayne C. Gramlich]

Mark:

I'm more than willing to contribute to this discussion, but really a new thread
should be started.

Regards,

-Wayne

[Mark Womack]

Please feel free to start a new thread!

-Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/e259682d-2d19-1328-8ed1-0d3a4e059a0e%40Gramlich.Net.