Robot Peripherals (was: ExampleBot Subsystem design)
441 views
Skip to first unread message
Wayne C. Gramlich
Jan 15, 2022, 2:02:02 PM1/15/22
to hbrobotics, Wayne Gramlich
Mark:
I didn't want to hijack your thread without some agreement.
I'm going to paste the major messages so far below and then trim the post and reply further.
Next post to follow soon...
Regards,
-Wayne
Here's the content so far:
Wayne's initial reply:
> 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.
Bob's Reply:
> 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.
Mark's reply to the messages above:
> 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?
Charles's reply:
> 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.
Mark's reply to 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.
> <https://docs.google.com/document/d/1gFfrrMrZ4ZPJ-SRzuViX5B-59AWDK95AomR9_E8CAbE/edit?usp=sharing>
> There is also a design document here
> <https://docs.google.com/document/d/1wxa2x0Tm9xONgTUZrIBZu4LOrlNEI9vaWj-uY3Ny3Wc/edit?usp=sharing>,
> 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!
I didn't want to hijack your thread without some agreement.
I'm going to paste the major messages so far below and then trim the post and reply further.
Next post to follow soon...
Regards,
-Wayne
Here's the content so far:
Wayne's initial reply:
> 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.
Bob's Reply:
> 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.
Mark's reply to the messages above:
> 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?
Charles's reply:
> 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.
Mark's reply to 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.
> <https://docs.google.com/document/d/1gFfrrMrZ4ZPJ-SRzuViX5B-59AWDK95AomR9_E8CAbE/edit?usp=sharing>
> There is also a design document here
> <https://docs.google.com/document/d/1wxa2x0Tm9xONgTUZrIBZu4LOrlNEI9vaWj-uY3Ny3Wc/edit?usp=sharing>,
> 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!
Wayne C. Gramlich
Jan 15, 2022, 2:27:45 PM1/15/22
to hbrobotics, Wayne Gramlich
Mark:
(I usually front post and trim thread discussions.)
The standard ROS (now ROS2) architecture is to run the ROS on a higher end machine
with standard operating system (e.g. Linux, MacOS, Windows.) For ROS2, the dominate
OS appears to be Linux.
The next issue is how to you connect your robot peripherals to the main processor.
The main processor has a variety of I/O sub-systems -- Ethernet and USB dominate,
with serial line protocol (RS232/RS485) next, followed by more specialized drivers
for I2C and and CANBUS, etc.
Most robots have a dedicated single microcontroller that they plug all of their peripherals
into (motors, sonars, servos, sensors, etc.) into. Programming and debugging the
the microcontroller code can be very challenging since it frequently has to have
an RTOS (e.g FreeRTOS) running on it to manage all of the concurrency. This software
complexity is daunting and makes it very difficult for most individuals to deploy
their robots.
The alternative design is some sort of bus/star network where each peripheral
has a dedicated processor that just interfaces to the peripheral. In this architecture,
the there is a ROS node that interfaces between ROS protocols (Topics/Services)
and the whatever physical layer used to talk to the bus/star. In general, whenever
possible all of the complexity is pushed into the ROS interface node (e.g. timeouts,
error correct etc.) because it is way easier to write and debug code that runs on
a real operating system.
There are cost trade-offs. If you are going to make a million of something, it is
feasible to minimize physical hardware costs and pay for the additional engineering
required to get all the software to work on a single low cost microcontroller. For
amateur robotics enthusiasts, spending a small amount more on physical hardware to
reduce overall development time is a good trade-off.
This is my summary of the problem space.
Regards,
-Wayne
(I usually front post and trim thread discussions.)
The standard ROS (now ROS2) architecture is to run the ROS on a higher end machine
with standard operating system (e.g. Linux, MacOS, Windows.) For ROS2, the dominate
OS appears to be Linux.
The next issue is how to you connect your robot peripherals to the main processor.
The main processor has a variety of I/O sub-systems -- Ethernet and USB dominate,
with serial line protocol (RS232/RS485) next, followed by more specialized drivers
for I2C and and CANBUS, etc.
Most robots have a dedicated single microcontroller that they plug all of their peripherals
into (motors, sonars, servos, sensors, etc.) into. Programming and debugging the
the microcontroller code can be very challenging since it frequently has to have
an RTOS (e.g FreeRTOS) running on it to manage all of the concurrency. This software
complexity is daunting and makes it very difficult for most individuals to deploy
their robots.
The alternative design is some sort of bus/star network where each peripheral
has a dedicated processor that just interfaces to the peripheral. In this architecture,
the there is a ROS node that interfaces between ROS protocols (Topics/Services)
and the whatever physical layer used to talk to the bus/star. In general, whenever
possible all of the complexity is pushed into the ROS interface node (e.g. timeouts,
error correct etc.) because it is way easier to write and debug code that runs on
a real operating system.
There are cost trade-offs. If you are going to make a million of something, it is
feasible to minimize physical hardware costs and pay for the additional engineering
required to get all the software to work on a single low cost microcontroller. For
amateur robotics enthusiasts, spending a small amount more on physical hardware to
reduce overall development time is a good trade-off.
This is my summary of the problem space.
Regards,
-Wayne
Chris Albertson
Jan 15, 2022, 4:44:53 PM1/15/22
to hbrob...@googlegroups.com
Busses sometimes make sense. But other times they don't.
Usiing a bus like CABbus can reduce the number of wires in a complex robot but can make a simple robot more complex then it needs to be.
If you have a 28 DOF humanoid robot powered by BLDC motors the direct wired method would have close to 100 wires coming back to the main controller. The average wirelenght for a human-size robot would be a meter, so you might if 100 meters of wire. This is impossible. You are force to use distributed control and a bus. But on a differential drive 'bot using a CAN bus almost doubles the amount of wire used.
Maybe after about a half dozen motors it makes sense to use a bus. I think it also maters the physical size. A larger robot saves more by using a but than a small one. With hoby robots I think you start getting into the need for something like CAN bas if you build a manipulator as those typically do have 6+ motors.
If this discussion is about a 6 inch diameter table-bot then every part you can possible remove from the design makes it better.
Pololu has made it REALLY easy to build an bog-standard example table robot with their Romi Chassis and their Adruino based board that stacks on a Raspberry Pi.
THis save the "rat's nest" of jumper wires and a mechanical mounting problem. The motors, encoders connect to the over board. You can run the robot with just this board, or later add a Raspberry Pi4. It is all just screwdriver assembly.
This is a good integrated solution as the Pi4, Aduino and Moter drivers are connected with no wires and the whole this is only $25.
OK, the argument if not using it is that "It is to easy". To answer then you have the larger "floor-bot" that tall enough to see a countertop and has an arm so it can do stuff with what it sees.
But for the low-end, I think you want, something that "just works" with a total cot of under $100 and only an hour or two for "screw-driver-only" assembly. Polou has this photo of a ROS-based robot with Pi4 and Arduino and dual motors, They have the simplest and lowest cost solution Most people could build this in less than an hour. See Photo. Yes, really this is all you need (plus the Romi Chass and their $10 encoder kit)
THey have full instructions and software online here https://www.pololu.com/blog/577/building-a-raspberry-pi-robot-with-the-a-star-32u4-robot-controller
As for the larger robot that is big enough to see a countertop and do things with what it sees. THAT is that is where to apply some creativity and brainpower. The table-bot beginner thing is a done deal.
I started a kitchen-helper, tabled busser robot design. Then money because an issue. The 'bot uses off the shelf parts except a few that can be either 3D printed or CNC machined. It uses tapered roller bearings and borrows the best ideas from the AR3 robot by Chris Annin. It has human-scale shoulders from 6 identical units. Using identical units keeps cost and complexity down. Only three parts need be made the red, gold and green ones. The rest are from Stepper Online or are standard hardware. I guess a payload at the hands of about a kilogram or more. This was going to set on top of a wheeled base and use a couple of lead-acid golf-cart batteries for ballast. The tan parts are "dummy" structures, not yet designed. I did the hardest part first, the human-size shoulders. The same parts (with better motors) could be used to make a walking humanoid robot. (Use industrial servos, not steppers.)
Chris Annin's best design feature is the BEARINGS. He got it right. All the wobbling and shaking on the low-end robot is usually due to the poor and undersized bearings. I borrowed his bearings and motors. And placed them in a lego-like brink that can be reassembled to hips, shoulders or whatever.
What I suggest is a wider range of examples. Start with a 1-hour build with no Raspberry Pi, just that $26 Pololu board and some plastic motors as in the photo. Then, later if you like, add a Pi4. It just connects with no wires by the header and now you have a ROS-capable robot, simulation in Gazebo, WiFi and so on.
The bigger bot is harder and should to push the state of the art in hobby-level robots up to a more professional level by getting into manipulators that can reach a countertop.
I think when people think of "robot" they think of one that has at least arms (if not also legs) But many builders are afraid of the complexity of arms. Help them get past this. Make an example that starts with a BIG base with FOUR wheels and is STABLE enough to add arms later then provide an example of arms.
You might also split the bigger robot into two projects. A builder can do just one project, then latter combine them. One is an arm mounted to a workbench. It can pick up and move stuff. Build just that. Then later a wheeled base.
--
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/74e13492-f6b8-9a1f-d627-b85be8d1ad57%40Gramlich.Net.
Chris Albertson
Redondo Beach, California
Wayne C. Gramlich
Jan 15, 2022, 6:39:01 PM1/15/22
to hbrob...@googlegroups.com, Wayne Gramlich
Chris:
For the table top robot, I think the Romi Base is the way to go.
(I've been saying this all along.)
Now that Pololu has the Romi 32U4 Control Board (https://www.pololu.com/product/3544),
a ROS table top bot is pretty much ready to go out the the box. Add a RasPi,
load up ROS, drop some code into the ATMega code, Done.
For a larger floor bot, a bus can make more sense.
Regards,
-Wayne
For the table top robot, I think the Romi Base is the way to go.
(I've been saying this all along.)
Now that Pololu has the Romi 32U4 Control Board (https://www.pololu.com/product/3544),
a ROS table top bot is pretty much ready to go out the the box. Add a RasPi,
load up ROS, drop some code into the ATMega code, Done.
For a larger floor bot, a bus can make more sense.
Regards,
-Wayne
> THey have full instructions and software online here
> https://www.pololu.com/blog/577/building-a-raspberry-pi-robot-with-the-a-star-32u4-robot-controller
>
> As for the larger robot that is big enough to see a countertop and do
> things with what it sees. *THAT* is that is where to apply some creativity
> https://www.pololu.com/blog/577/building-a-raspberry-pi-robot-with-the-a-star-32u4-robot-controller
>
> As for the larger robot that is big enough to see a countertop and do
Chris Albertson
Jan 15, 2022, 8:41:06 PM1/15/22
to hbrob...@googlegroups.com, Wayne Gramlich
On Sat, Jan 15, 2022 at 3:39 PM Wayne C. Gramlich <wayne.gra...@gmail.com> wrote:
Chris:
For the table top robot, I think the Romi Base is the way to go.
Yes, Pololu makes the table-bot a one evening project which is ideal for a first robot project. It is pretty much guaranteed to work.
The next question is how challenging the next step should be. I'd argue that a "bigger" Romi" is pointless as there is little technical difference, just more money and weight. For a robot to do more it needs more sensors and more actuators. I think "Arms" are the next thing an aspiring robot-builder needs to learn after learning wheels.
And you are right about a bus reducing wiring in larger 'bots
One thing I found is that differential drive no longer works when the robot count top tall. You need four wheels for stability and casters just do not work over bumps. All four wheels need power. Then you have to thnk about steering There are a few options
1) the robot turns like a tank be skidding, this works poorly on high friction floors like hardwood
2) Steer the front (or rear) wheels only. This is call Akerman" and is that most cars do.
3) Steer both front and rear wheels. This dramatically improves mobility but is twice as complex. But allows things like "spin in place" pr easy parallel parking is the robot can drive to a counter or table then turn all four wheel 90 degrees and move laterally. If the robot has an arm, four-wheel steering can allow the arm to have one or two fewer degrees of freedom.
As said the next step is to choose a level of difficulty. I'd argue the "bigger Roni" is too small of a step.
I'd argue for a modular approach. Design two sets of wheel (A) Fixed and (B) steerable. The can be attached to the same chassis. Then using two sets of (A) you have option (1) above. if you build one (A) and one (B) you have option (2) above. Building two of the (B) sets allow full four wheel steering
All would use the same motors and wheels you a person could start cheap then upgrade.
Make it big enough to move a 60-pound robot as you need that mass to lift (say) a coffee cup off a table if it is a couple of feet from the edge.
The key to success in such a project is clean interfaces. Simple things like establishing a bolt pattern for the arm to body to the two parts can be developed independently. For for the arm-to-hand and choosing a bus.
I'd contribute CAD work to such a project.
One thing I do NOT recommend to others is the Dog-bot project I'm working on. These under $500 dogs are only suitable for software development and testing ideas. The performance of these $20 motors is just not there. But as a development platform, they can work. The trouble is that the next step requires a mid four-digit budget, about 10x more than what I'm spending. There are no good mid-way solutions.
--
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/cc0e3692-c5cc-22f0-a32e-7ac2faa081db%40Gramlich.Net.
Wayne C. Gramlich
Jan 15, 2022, 9:07:32 PM1/15/22
to Chris Albertson, hbrob...@googlegroups.com, Wayne Gramlich
Chris:
I agree with pretty much everything you say with few additional comments spliced in:
On 1/15/22 5:40 PM, Chris Albertson wrote:
> On Sat, Jan 15, 2022 at 3:39 PM Wayne C. Gramlich <
> wayne.gra...@gmail.com> wrote:
>
>> Chris:
>>
>> For the table top robot, I think the Romi Base is the way to go.
>>
>
> Yes, Pololu makes the table-bot a one evening project which is ideal for a
> first robot project. It is pretty much guaranteed to work.
>
> The next question is how challenging the next step should be. I'd argue
> that a "bigger" Romi" is pointless as there is little technical difference,
> just more money and weight. For a robot to do more it needs more sensors
> and more actuators. I think "Arms" are the next thing an
> aspiring robot-builder needs to learn after learning wheels.
Pololu sells a 3DOF servo based arm for the Romi. The servos are 4 wire
with the 4th wire providing an analog voltage of actual position.
This gets people working on arms out-of-the box.
> And you are right about a bus reducing wiring in larger 'bots
There is another aspect to a bus architecture in that it can simplify your software
architecture as well.
> One thing I found is that differential drive no longer works when the robot
> count top tall. You need four wheels for stability and casters just do not
> work over bumps. All four wheels need power. Then you have to thnk about
> steering There are a few options
>
> 1) the robot turns like a tank be skidding, this works poorly on high
> friction floors like hardwood
> 2) Steer the front (or rear) wheels only. This is call Akerman" and is
> that most cars do.
> 3) Steer both front and rear wheels. This dramatically improves mobility
> but is twice as complex. But allows things like "spin in place" pr easy
> parallel parking is the robot can drive to a counter or table then turn all
> four wheel 90 degrees and move laterally. If the robot has an arm,
> four-wheel steering can allow the arm to have one or two fewer degrees of
> freedom.
There are many solutions in the larger robot space. Many robots are still
differential drive, but they have a superior suspension and carefully designed
castors. I am not aware of anybody selling there superior suspensions for anything
remotely close to a reasonable price. Usually the companies involved keep
them them private.
That said, I'm an all wheel drive kind of guy, for the same reasons you list.
* Real floor are actually not flat,
* Differential drive ends to encourage round bases which can get "tippy" in
comparison to rectangular bases that have wheels at all 4 corners.
Your comment about having a better base simplifying the arm complexity is spot on.
> As said the next step is to choose a level of difficulty. I'd argue the
> "bigger Roni" is too small of a step.
>
> I'd argue for a modular approach. Design two sets of wheel (A) Fixed and
> (B) steerable. The can be attached to the same chassis. Then using
> two sets of (A) you have option (1) above. if you build one (A) and one
> (B) you have option (2) above. Building two of the (B) sets allow full four
> wheel steering
>
> All would use the same motors and wheels you a person could start cheap
> then upgrade.
>
> Make it big enough to move a 60-pound robot as you need that mass to lift
> (say) a coffee cup off a table if it is a couple of feet from the edge.
>
> The key to success in such a project is clean interfaces. Simple things
> like establishing a bolt pattern for the arm to body to the two parts can
> be developed independently. For for the arm-to-hand and choosing a bus.
>
> I'd contribute CAD work to such a project.
These are all excellent ideas.
[snipped the rest of the post]
Regards,
-Wayne
I agree with pretty much everything you say with few additional comments spliced in:
On 1/15/22 5:40 PM, Chris Albertson wrote:
> On Sat, Jan 15, 2022 at 3:39 PM Wayne C. Gramlich <
> wayne.gra...@gmail.com> wrote:
>
>> Chris:
>>
>> For the table top robot, I think the Romi Base is the way to go.
>>
>
> Yes, Pololu makes the table-bot a one evening project which is ideal for a
> first robot project. It is pretty much guaranteed to work.
>
> The next question is how challenging the next step should be. I'd argue
> that a "bigger" Romi" is pointless as there is little technical difference,
> just more money and weight. For a robot to do more it needs more sensors
> and more actuators. I think "Arms" are the next thing an
> aspiring robot-builder needs to learn after learning wheels.
with the 4th wire providing an analog voltage of actual position.
This gets people working on arms out-of-the box.
> And you are right about a bus reducing wiring in larger 'bots
architecture as well.
> One thing I found is that differential drive no longer works when the robot
> count top tall. You need four wheels for stability and casters just do not
> work over bumps. All four wheels need power. Then you have to thnk about
> steering There are a few options
>
> 1) the robot turns like a tank be skidding, this works poorly on high
> friction floors like hardwood
> 2) Steer the front (or rear) wheels only. This is call Akerman" and is
> that most cars do.
> 3) Steer both front and rear wheels. This dramatically improves mobility
> but is twice as complex. But allows things like "spin in place" pr easy
> parallel parking is the robot can drive to a counter or table then turn all
> four wheel 90 degrees and move laterally. If the robot has an arm,
> four-wheel steering can allow the arm to have one or two fewer degrees of
> freedom.
differential drive, but they have a superior suspension and carefully designed
castors. I am not aware of anybody selling there superior suspensions for anything
remotely close to a reasonable price. Usually the companies involved keep
them them private.
That said, I'm an all wheel drive kind of guy, for the same reasons you list.
* Real floor are actually not flat,
* Differential drive ends to encourage round bases which can get "tippy" in
comparison to rectangular bases that have wheels at all 4 corners.
Your comment about having a better base simplifying the arm complexity is spot on.
> As said the next step is to choose a level of difficulty. I'd argue the
> "bigger Roni" is too small of a step.
>
> I'd argue for a modular approach. Design two sets of wheel (A) Fixed and
> (B) steerable. The can be attached to the same chassis. Then using
> two sets of (A) you have option (1) above. if you build one (A) and one
> (B) you have option (2) above. Building two of the (B) sets allow full four
> wheel steering
>
> All would use the same motors and wheels you a person could start cheap
> then upgrade.
>
> Make it big enough to move a 60-pound robot as you need that mass to lift
> (say) a coffee cup off a table if it is a couple of feet from the edge.
>
> The key to success in such a project is clean interfaces. Simple things
> like establishing a bolt pattern for the arm to body to the two parts can
> be developed independently. For for the arm-to-hand and choosing a bus.
>
> I'd contribute CAD work to such a project.
[snipped the rest of the post]
Regards,
-Wayne
Mark Womack
Jan 16, 2022, 5:35:24 PM1/16/22
to hbrob...@googlegroups.com
OK, I have a few comments to add. I am enjoying this discussion.
1) In regards to the bus, isn't the ROS pub/sub network essentially the "bus" we are talking about here? The microcontrollers are pushing their data into the ROS data/msg space and subscribing to msgs they care about. If the subsystem (like a complicated multi-servo arm) is internally complicated, it can choose how it wants to communicate between its parts. Maybe one large microcontroller connected to everything or a collection of smaller microcontrollers talking to each other over I2C or CANBus. But at the end of the day everything is driven by the ROS msg space. All that internal complexity does not need to be exposed to the wider set of nodes. Right now we are talking about a simple robot that is probably only going to react to cmd_vel messages. I don't know what would be required for an arm or two, but I would bet it will be on the same order - get the gripper to this x/y/z location. But my point is that ROS is a lot of things, and being the bus is one of them. How the components interface to ROS (ie micro-ROS or a custom protocol with accompanying ROS translation node) is left as an exercise to the reader. Which is us in this case. :-)
2) As I have said earlier, I'm glad that Pololu has solved the tablebot space and someone can buy and build Romi for under a hundred bucks and hit the ground running. But this is not that robot. If you don't care about a custom tabletop example bot and would rather focus on a floorbot, that's great. But that doesn't make the learnings that a beginner would take away from building their own version of Bart any less important. Not everyone is going to be able to start at the floorbot level. The parts are going to be much more industrial and the build itself more involved. It's going to be a great time, but sometimes folks need to start small before going big. If someone wants to start by building a Romi, I say go for it. Feel free to ask questions if you get stumped or don't understand something, we are all here to help and share. But Bart is going to be a bit less all-in-one, maybe a bit more extensible (or at least a good jumping off point).
3) Before you can walk, you have to crawl. The example bots as currently defined by the phases are just crawling. They can just basically move, navigate, find an object, do minimal manipulation. Just getting that to work is going to take some time and effort. I'm really looking forward to it. But I don't think immediately focusing on building a two armed robot that can serve drinks and carry trays is going to help anyone. That level of proficiency and what is required to address them is daunting, especially to a beginner. Now, if we want to add more phases, each one more involved and complicated than the last, I'm all in. If we want to say as part of the design, "we know the first three phases are kind of simple, but we want to make sure the robot is sturdy and maneuverable for the future phases, so we are using this form factor and platform...", then I am all in. If we want to say that Homer is meant to be a floorbot-based robot that can navigate a home environment and is able to assist a human in meaningful ways, which in turn requires the following things...I'm all in. But we have to crawl before we can walk, and walk before we can run. The phases should represent that and provide for a stable, useful platform for future development and jumping off.
-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/ff58a970-ecf3-3416-aede-e7831b1574fc%40Gramlich.Net.
Wayne C. Gramlich
Jan 16, 2022, 6:09:43 PM1/16/22
to hbrob...@googlegroups.com, Wayne Gramlich
Mark:
On 1/16/22 2:35 PM, Mark Womack wrote:
> OK, I have a few comments to add. I am enjoying this discussion.
I'm enjoying it as well (and there is much more to come...)
I am hoping to get a slug of time tonight to do a quick discussion
about robot peripheral interconnect topology (bus/star/tree) issues.
> 1) In regards to the bus, isn't the ROS pub/sub network essentially
> the "bus" we are talking about here? The microcontrollers are pushing their
> data into the ROS data/msg space and subscribing to msgs they care about.
> If the subsystem (like a complicated multi-servo arm) is internally
> complicated, it can choose how it wants to communicate between its parts.
> Maybe one large microcontroller connected to everything or a collection of
> smaller microcontrollers talking to each other over I2C or CANBus. But at
> the end of the day everything is driven by the ROS msg space. All that
> internal complexity does not need to be exposed to the wider set of nodes.
> Right now we are talking about a simple robot that is probably only going
> to react to cmd_vel messages. I don't know what would be required for an
> arm or two, but I would bet it will be on the same order - get the gripper
> to this x/y/z location. But my point is that ROS is a lot of things, and
> being the bus is one of them. How the components interface to ROS (ie
> micro-ROS or a custom protocol with accompanying ROS translation node) is
> left as an exercise to the reader. Which is us in this case. :-)
ROS primarily provides a publish/subscribe (pub/sub) and service (remote
procedure call==RPC) interface. Hooking your lower level hardware up has
been consistently difficult, particularly for beginners.
I think it is possible to have a peripheral system that you plug peripherals into
with the following behavior:
* The system can easily discover what is plugged into the peripheral system
and enumerate the peripherals.
* Each peripheral knows what kind of ROS topics/services it can deal with.
* The user just has to specify the binding from peripheral topics/services
to specific ROS topic/service names.
If we had such a system, I think there would be way more people dabbling in
amateur robotics.
> 2) As I have said earlier, I'm glad that Pololu has solved the
> tablebot space and someone can buy and build Romi for under a hundred bucks
> and hit the ground running. But this is not that robot. If you don't care
> about a custom tabletop example bot and would rather focus on a floorbot,
> that's great. But that doesn't make the learnings that a beginner would
> take away from building their own version of Bart any less important. Not
> everyone is going to be able to start at the floorbot level. The parts are
> going to be much more industrial and the build itself more involved. It's
> going to be a great time, but sometimes folks need to start small before
> going big. If someone wants to start by building a Romi, I say go for it.
> Feel free to ask questions if you get stumped or don't understand
> something, we are all here to help and share. But Bart is going to be a bit
> less all-in-one, maybe a bit more extensible (or at least a good jumping
> off point).
An important concept behind a peripheral system is to have examples of how
to add a new peripheral for a new actual/sensor. Again, historically,
people have had to figure it out on their own.
> 3) Before you can walk, you have to crawl. The example bots as currently
> defined by the phases are just crawling. They can just basically move,
> navigate, find an object, do minimal manipulation. Just getting that to
> work is going to take some time and effort. I'm really looking forward to
> it. But I don't think immediately focusing on building a two armed robot
> that can serve drinks and carry trays is going to help anyone. That level
> of proficiency and what is required to address them is daunting, especially
> to a beginner. Now, if we want to add more phases, each one more involved
> and complicated than the last, I'm all in. If we want to say as part of the
> design, "we know the first three phases are kind of simple, but we want to
> make sure the robot is sturdy and maneuverable for the future phases, so we
> are using this form factor and platform...", then I am all in. If we want
> to say that Homer is meant to be a floorbot-based robot that can navigate a
> home environment and is able to assist a human in meaningful ways, which in
> turn requires the following things...I'm all in. But we have to crawl
> before we can walk, and walk before we can run. The phases should represent
> that and provide for a stable, useful platform for future development and
> jumping off.
Total agreement with the paragraph above.
[snippage]
Regards,
-Wayne
On 1/16/22 2:35 PM, Mark Womack wrote:
> OK, I have a few comments to add. I am enjoying this discussion.
I am hoping to get a slug of time tonight to do a quick discussion
about robot peripheral interconnect topology (bus/star/tree) issues.
> 1) In regards to the bus, isn't the ROS pub/sub network essentially
> the "bus" we are talking about here? The microcontrollers are pushing their
> data into the ROS data/msg space and subscribing to msgs they care about.
> If the subsystem (like a complicated multi-servo arm) is internally
> complicated, it can choose how it wants to communicate between its parts.
> Maybe one large microcontroller connected to everything or a collection of
> smaller microcontrollers talking to each other over I2C or CANBus. But at
> the end of the day everything is driven by the ROS msg space. All that
> internal complexity does not need to be exposed to the wider set of nodes.
> Right now we are talking about a simple robot that is probably only going
> to react to cmd_vel messages. I don't know what would be required for an
> arm or two, but I would bet it will be on the same order - get the gripper
> to this x/y/z location. But my point is that ROS is a lot of things, and
> being the bus is one of them. How the components interface to ROS (ie
> micro-ROS or a custom protocol with accompanying ROS translation node) is
> left as an exercise to the reader. Which is us in this case. :-)
procedure call==RPC) interface. Hooking your lower level hardware up has
been consistently difficult, particularly for beginners.
I think it is possible to have a peripheral system that you plug peripherals into
with the following behavior:
* The system can easily discover what is plugged into the peripheral system
and enumerate the peripherals.
* Each peripheral knows what kind of ROS topics/services it can deal with.
* The user just has to specify the binding from peripheral topics/services
to specific ROS topic/service names.
If we had such a system, I think there would be way more people dabbling in
amateur robotics.
> 2) As I have said earlier, I'm glad that Pololu has solved the
> tablebot space and someone can buy and build Romi for under a hundred bucks
> and hit the ground running. But this is not that robot. If you don't care
> about a custom tabletop example bot and would rather focus on a floorbot,
> that's great. But that doesn't make the learnings that a beginner would
> take away from building their own version of Bart any less important. Not
> everyone is going to be able to start at the floorbot level. The parts are
> going to be much more industrial and the build itself more involved. It's
> going to be a great time, but sometimes folks need to start small before
> going big. If someone wants to start by building a Romi, I say go for it.
> Feel free to ask questions if you get stumped or don't understand
> something, we are all here to help and share. But Bart is going to be a bit
> less all-in-one, maybe a bit more extensible (or at least a good jumping
> off point).
to add a new peripheral for a new actual/sensor. Again, historically,
people have had to figure it out on their own.
> 3) Before you can walk, you have to crawl. The example bots as currently
> defined by the phases are just crawling. They can just basically move,
> navigate, find an object, do minimal manipulation. Just getting that to
> work is going to take some time and effort. I'm really looking forward to
> it. But I don't think immediately focusing on building a two armed robot
> that can serve drinks and carry trays is going to help anyone. That level
> of proficiency and what is required to address them is daunting, especially
> to a beginner. Now, if we want to add more phases, each one more involved
> and complicated than the last, I'm all in. If we want to say as part of the
> design, "we know the first three phases are kind of simple, but we want to
> make sure the robot is sturdy and maneuverable for the future phases, so we
> are using this form factor and platform...", then I am all in. If we want
> to say that Homer is meant to be a floorbot-based robot that can navigate a
> home environment and is able to assist a human in meaningful ways, which in
> turn requires the following things...I'm all in. But we have to crawl
> before we can walk, and walk before we can run. The phases should represent
> that and provide for a stable, useful platform for future development and
> jumping off.
[snippage]
Regards,
-Wayne
Wayne C. Gramlich
Jan 16, 2022, 11:37:11 PM1/16/22
to hbrobotics, Wayne Gramlich
All:
I'm going to assume that for larger robots, people can agree that having a Robot peripheral
strategy is worth persuing, I'm going to talk about the Topology issues first.
Some common topologies are:
* Bus: A linear bus that everything plugs into. Some common examples are:
* I2C:
* SPI:
* RS485:
* CANBus:
* Early Ethernet: Before 10BaseT happened. (This is FYI, nobody uses it any more.)
* Tree/Star:
* USB:
* Later Ethernet: 10BaseT, 100BaseT, etc.
* Oddball: I'm not going to talk about these.
* Token Ring:
* Current Loop:
Does USB and Ethernet make sense for robot use. Definitely. There are shipping
robots out there that use either or both of these technologies. Some further comments
about each are:
* Ethernet: This is a little pricey per node, since each end of the ethernet
cable needs to have RJ45 connector, magnetics, and an Ethernet Physical Layer
chip (called a Phy.) If you have high bandwidth requirements, this is a very
reasonable way to go. The microcontroller has to have an ethernet interface,
which tends to increase the cost some. Over time, I expect more and more
ethernet peripherals to show up in amateur robots.
* USB: This a bit cheaper since the connectors are less expensive, and many of the
low end microcontrollers have a USB sub-system. The major down side of USB is
on the software side of ledger. There are pre-written libraries of varying
quality for the microcontroller USB firmware. The also needs to be a corresponding
operating system driver. Each of the major operating systems needs to have a
semi-custom USB driver to talk to the other the device. Again, there are libraries
of varying quality to deal with the driver problem.
To date, I have not seen much traction in the amateur robotics space with custom
built USB/Ethernet peripherals. It would be lovely to some amateur robots do something
in this space, but it is not "trivial".
Far more common in amateur robotics are bus based topologies.
* I2C:
This is extremely common, but has a variety of issues. I2C is two wires Serial Clock
(SCK) and serial data (SDA) lines with a pull-up resistor for needed for each line.
To be correct I2C, the pull-up resistor needs to be adjusted to the I2C bus capacitance.
In addition, the I2C suffers from being more susceptible to interference. Given
the noise that a motor can throw off, it can be more susceptible to errors. That
being said, plenty of amateur robots have some I2C sprinkled in and it works.
* SPI: This is also a 4 wire interface Serial Clock (SCLK), Master Out Slave In (MOSI),
Master In Slave Out (MISO), and Slave Select (*SS). Again, this is sometimes used
in amateur robots with success. The two most common topologies are a star network
where the SPI master has a dedicated SS line and a ring topology where the data is
shifted through all of the devices and they share a common SS line. The star topology
seems to be a little more prevalent than the ring topology. Again, while SPI is used
in some amateur robots, it seems to be significantly less prevalent.
Both RS-485 and CAN-BUS are two very similar buses that are quite prevalent.
To be technically correct, CAN-BUS is a complete protocol stack layered on top of the
ISO-11898 physical layer specification. Basically, both standards have a differential
pair (usually called D+ and D-). Both ends of the differential pair need a termination
resistor to reduce signal reflections.
* RS-485:
On RS-485, only one device can transmit at a time. Typically there is a master device,
that sends a command onto the bus and the slave device responds. More complicated
protocols are possible, but they are, well, more complicated. If two RS-485 transceivers
transmit at the same time, they can potentially damage one another, but realistically
they rarely do unless you do it all the time.
* CANBUS:
ISO-11898 specifies a party line protocol where multiple devices can transmit at
the same time. This basically a wired-AND, where if any device sends a "0", the bus
is a "0". It is a "1" only if all of the devices are at 1. The bus idles at "1".
It should be mentioned that standard serial line protocol (i.e. 8N1 == 1 start bit,
8 data bits, No parity, 1 stop bit) works just fine on ISO_11898. The higher level
CANBUS protocol is more complicated and includes addressing, bus contention resolution,
error detection, etc.
I'm sure I missed some, but the list above covers most of the more common ones out there.
The nice thing about standards is that there are so many to choose from. If I missed your
favorite, please let me know.
For the Homer/Bart stuff the only two I would recommend are Ethernet for high bandwidth
communication and ISO-11898 for lower bandwidth communication. I'm heavily in favor
of 8N1 on ISO-11989, but that is my bias.
I'm going to stop here for now.
Regards,
-Wayne
I'm going to assume that for larger robots, people can agree that having a Robot peripheral
strategy is worth persuing, I'm going to talk about the Topology issues first.
Some common topologies are:
* Bus: A linear bus that everything plugs into. Some common examples are:
* I2C:
* SPI:
* RS485:
* CANBus:
* Early Ethernet: Before 10BaseT happened. (This is FYI, nobody uses it any more.)
* Tree/Star:
* USB:
* Later Ethernet: 10BaseT, 100BaseT, etc.
* Oddball: I'm not going to talk about these.
* Token Ring:
* Current Loop:
Does USB and Ethernet make sense for robot use. Definitely. There are shipping
robots out there that use either or both of these technologies. Some further comments
about each are:
* Ethernet: This is a little pricey per node, since each end of the ethernet
cable needs to have RJ45 connector, magnetics, and an Ethernet Physical Layer
chip (called a Phy.) If you have high bandwidth requirements, this is a very
reasonable way to go. The microcontroller has to have an ethernet interface,
which tends to increase the cost some. Over time, I expect more and more
ethernet peripherals to show up in amateur robots.
* USB: This a bit cheaper since the connectors are less expensive, and many of the
low end microcontrollers have a USB sub-system. The major down side of USB is
on the software side of ledger. There are pre-written libraries of varying
quality for the microcontroller USB firmware. The also needs to be a corresponding
operating system driver. Each of the major operating systems needs to have a
semi-custom USB driver to talk to the other the device. Again, there are libraries
of varying quality to deal with the driver problem.
To date, I have not seen much traction in the amateur robotics space with custom
built USB/Ethernet peripherals. It would be lovely to some amateur robots do something
in this space, but it is not "trivial".
Far more common in amateur robotics are bus based topologies.
* I2C:
This is extremely common, but has a variety of issues. I2C is two wires Serial Clock
(SCK) and serial data (SDA) lines with a pull-up resistor for needed for each line.
To be correct I2C, the pull-up resistor needs to be adjusted to the I2C bus capacitance.
In addition, the I2C suffers from being more susceptible to interference. Given
the noise that a motor can throw off, it can be more susceptible to errors. That
being said, plenty of amateur robots have some I2C sprinkled in and it works.
* SPI: This is also a 4 wire interface Serial Clock (SCLK), Master Out Slave In (MOSI),
Master In Slave Out (MISO), and Slave Select (*SS). Again, this is sometimes used
in amateur robots with success. The two most common topologies are a star network
where the SPI master has a dedicated SS line and a ring topology where the data is
shifted through all of the devices and they share a common SS line. The star topology
seems to be a little more prevalent than the ring topology. Again, while SPI is used
in some amateur robots, it seems to be significantly less prevalent.
Both RS-485 and CAN-BUS are two very similar buses that are quite prevalent.
To be technically correct, CAN-BUS is a complete protocol stack layered on top of the
ISO-11898 physical layer specification. Basically, both standards have a differential
pair (usually called D+ and D-). Both ends of the differential pair need a termination
resistor to reduce signal reflections.
* RS-485:
On RS-485, only one device can transmit at a time. Typically there is a master device,
that sends a command onto the bus and the slave device responds. More complicated
protocols are possible, but they are, well, more complicated. If two RS-485 transceivers
transmit at the same time, they can potentially damage one another, but realistically
they rarely do unless you do it all the time.
* CANBUS:
ISO-11898 specifies a party line protocol where multiple devices can transmit at
the same time. This basically a wired-AND, where if any device sends a "0", the bus
is a "0". It is a "1" only if all of the devices are at 1. The bus idles at "1".
It should be mentioned that standard serial line protocol (i.e. 8N1 == 1 start bit,
8 data bits, No parity, 1 stop bit) works just fine on ISO_11898. The higher level
CANBUS protocol is more complicated and includes addressing, bus contention resolution,
error detection, etc.
I'm sure I missed some, but the list above covers most of the more common ones out there.
The nice thing about standards is that there are so many to choose from. If I missed your
favorite, please let me know.
For the Homer/Bart stuff the only two I would recommend are Ethernet for high bandwidth
communication and ISO-11898 for lower bandwidth communication. I'm heavily in favor
of 8N1 on ISO-11989, but that is my bias.
I'm going to stop here for now.
Regards,
-Wayne
Chris Albertson
Jan 17, 2022, 12:32:21 AM1/17/22
to hbrob...@googlegroups.com
Wayne,
You left out one bus type that I expect will be used more and more by hobby robots. I certainly intend to use it. That would e the "Serial Buss Servo" bus. This is a three-wire system where there are two wires DC power and one bidirectional signal wire. It uses the normal hobby servo cable connectors but in this system one servo chains to the next. The bus only works for these servos. The servos are now a generic Chinese product, with several companies selling compatible units. Documentation is horrible, but you can find it and make sense of it if you try.
Dynamixel also has their own servo bus that I think (?) use four wires but the above bus will be used more because it works with generic $18 servos.
Does Wifi and Bluetooth count as a bus type?
--
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/ae26b59c-6902-405b-4d74-4653dc7a9fc3%40Gramlich.Net.
Mark Womack
Jan 17, 2022, 9:53:55 AM1/17/22
to hbrob...@googlegroups.com
Wayne:
On Sun, Jan 16, 2022 at 6:09 PM Wayne C. Gramlich <wayne.gra...@gmail.com> wrote:
ROS primarily provides a publish/subscribe (pub/sub) and service (remote
procedure call==RPC) interface. Hooking your lower level hardware up has
been consistently difficult, particularly for beginners.
I think it is possible to have a peripheral system that you plug peripherals into
with the following behavior:
* The system can easily discover what is plugged into the peripheral system
and enumerate the peripherals.
* Each peripheral knows what kind of ROS topics/services it can deal with.
* The user just has to specify the binding from peripheral topics/services
to specific ROS topic/service names.
If we had such a system, I think there would be way more people dabbling in
amateur robotics.
Here is a good example from the microROS github:
It initializes microROS, creates a publisher, attaches the publisher to an executor with a timer. I kind of feel that this is everything you mentioned above, except maybe the discovery (which I am not entirely convinced you need so long as the expected topic/msgs are around). Earlier versions of microROS were probably very rough, and I'm not sure there is enough actual documentation, but the code examples for galactic are very good. They have other good examples in that directory. If you ignore for a moment the microcontroller requirements and that we could probably push data faster without the overhead to run microROS, this is pretty straightforward, right? ("straightforward" in the sense that once you learn about ROS, this fits with that understanding. No new stuff, no custom stuff.)
An important concept behind a peripheral system is to have examples of how
to add a new peripheral for a new actual/sensor. Again, historically,
people have had to figure it out on their own.
I'm actually more worried that trying to provide an example of something "simple" is going to be way more complicated in ROS. Just to understand how ROS is doing things for a mobile robot you have to understand global frame, robot frame, theta, angular velocity, etc, etc. All important stuff to know, but it is alot to wrap your head around in the very beginning where you just want to make your robot move.
-Mark
Wayne C. Gramlich
Jan 17, 2022, 11:05:11 AM1/17/22
to hbrob...@googlegroups.com
Chris:
On 1/16/22 9:32 PM, Chris Albertson wrote:
> Wayne,
>
> You left out one bus type that I expect will be used more and more by hobby
> robots. I certainly intend to use it. That would e the "Serial Buss
> Servo" bus. This is a three-wire system where there are two wires DC
> power and one bidirectional signal wire. It uses the normal hobby servo
> cable connectors but in this system one servo chains to the next. The bus
> only works for these servos. The servos are now a generic Chinese
> product, with several companies selling compatible units. Documentation is
> horrible, but you can find it and make sense of it if you try.
> amazon.com/LewanSoul-Real-Time-Feedback-Position-...
> <https://www.amazon.com/LewanSoul-Real-Time-Feedback-Position-Temperature/dp/B073WR3SK9/ref=pd_bxgy_img_1/138-3766605-9765519?pd_rd_w=qKJ9A&pf_rd_p=c64372fa-c41c-422e-990d-9e034f73989b&pf_rd_r=XCJKXJTERG2N8F5DDV5Z&pd_rd_r=8db936af-4609-4d27-9dd3-71accf52a6f0&pd_rd_wg=6jqBI&pd_rd_i=B073WR3SK9&psc=1>
You are right, I forgot to mention servo buses. My recollection is that
Dynamixal has both "TTL", RS-485 buses and hybrid TTL/RS-485 bus. I put "TTL"
in quotes since the original Transistor-Transistor Logic stuff is long gone
has been replaced by the CMOS families with a blizzard of differing 74xx series
names, speeds, voltage levels, etc. It is a legitimate bus. I tend to think
of them as it as a "sub-bus", but they definitely count. Lot's of people use them.
> Dynamixel also has their own servo bus that I think (?) use four wires but
> the above bus will be used more because it works with generic $18 servos.
>
> Does Wifi and Bluetooth count as a bus type?
Both WiFi and Bluetooth count. I tend to treat WiFi as ethernet. Blue tooth
is a bonified separate bus. Wireless still needs to be powered either via power
wires or batteries.
Thanks for mentioning these.
Regards,
-Wayne
On 1/16/22 9:32 PM, Chris Albertson wrote:
> Wayne,
>
> You left out one bus type that I expect will be used more and more by hobby
> robots. I certainly intend to use it. That would e the "Serial Buss
> Servo" bus. This is a three-wire system where there are two wires DC
> power and one bidirectional signal wire. It uses the normal hobby servo
> cable connectors but in this system one servo chains to the next. The bus
> only works for these servos. The servos are now a generic Chinese
> product, with several companies selling compatible units. Documentation is
> horrible, but you can find it and make sense of it if you try.
> amazon.com/LewanSoul-Real-Time-Feedback-Position-...
You are right, I forgot to mention servo buses. My recollection is that
Dynamixal has both "TTL", RS-485 buses and hybrid TTL/RS-485 bus. I put "TTL"
in quotes since the original Transistor-Transistor Logic stuff is long gone
has been replaced by the CMOS families with a blizzard of differing 74xx series
names, speeds, voltage levels, etc. It is a legitimate bus. I tend to think
of them as it as a "sub-bus", but they definitely count. Lot's of people use them.
> Dynamixel also has their own servo bus that I think (?) use four wires but
> the above bus will be used more because it works with generic $18 servos.
>
> Does Wifi and Bluetooth count as a bus type?
is a bonified separate bus. Wireless still needs to be powered either via power
wires or batteries.
Thanks for mentioning these.
Regards,
-Wayne
Mark Womack
Jan 17, 2022, 11:19:03 AM1/17/22
to hbrob...@googlegroups.com
Chris:
On Sat, Jan 15, 2022 at 8:41 PM Chris Albertson <alberts...@gmail.com> wrote:
One thing I found is that differential drive no longer works when the robot count top tall. You need four wheels for stability and casters just do not work over bumps. All four wheels need power. Then you have to thnk about steering There are a few options1) the robot turns like a tank be skidding, this works poorly on high friction floors like hardwood2) Steer the front (or rear) wheels only. This is call Akerman" and is that most cars do.3) Steer both front and rear wheels. This dramatically improves mobility but is twice as complex. But allows things like "spin in place" pr easy parallel parking is the robot can drive to a counter or table then turn all four wheel 90 degrees and move laterally. If the robot has an arm, four-wheel steering can allow the arm to have one or two fewer degrees of freedom.As said the next step is to choose a level of difficulty. I'd argue the "bigger Roni" is too small of a step.
I'd like to follow this line of thinking and design a bit. What is the difference in the level of difficulty? Steering of wheels suggests a servo or multiple servos, some kind of mechanical connection to the wheels, etc. How easy would this be with easy-to-gather parts? (I'm not arguing it is too complex, I am trying to understand the space for someone coming to it after building Bart).
I'm also still interested in the "advanced casters" that Wayne mentioned. Is that ust casters with spring suspension?
I'd argue for a modular approach. Design two sets of wheel (A) Fixed and (B) steerable. The can be attached to the same chassis. Then using two sets of (A) you have option (1) above. if you build one (A) and one (B) you have option (2) above. Building two of the (B) sets allow full four wheel steeringAll would use the same motors and wheels you a person could start cheap then upgrade.
I like this idea, it would be a lot of options mechanically and software though. I feel like we would be better off choosing the best option for a home-based robot (see below) and go with it from the start.
Make it big enough to move a 60-pound robot as you need that mass to lift (say) a coffee cup off a table if it is a couple of feet from the edge.
I am thinking that there has been enough interest expressed in a home-based larger robot that we should make it an explicit goal of the Homer bot. When we were discussing earlier about know what exactly the robot would do, I think this starts to cover that base.
The key to success in such a project is clean interfaces. Simple things like establishing a bolt pattern for the arm to body to the two parts can be developed independently. For for the arm-to-hand and choosing a bus.
The physics are going to matter a lot more in this project because of the size and the tasks being considered, so I totally agree with this. Maybe we could design a general "deck" or "shoulder" that allows for lots of connection points. Kind of like the way the Romi base has so many places to run bolts and attach things.
I'd contribute CAD work to such a project.
Awesome! What would you add to the phases to capture this increased level of functionality and complexity?
-Mark
danie...@aol.com
Jan 17, 2022, 11:48:18 AM1/17/22
to hbrob...@googlegroups.com
Hi all,
Also important in the robotics' world is EtherCat.
An Ethernet host with a memory mapped payload that is sent to all slaves in a ring topology.
Custom slave ICs make this bus non-practical for hobby robots in general.
However, I have mimicked the memory mapped model using a high speed RS485 bus.
This converts the stochastic request/reply protocol into a more time deterministic protocol.
Wired as a star topology, each message is presented to all slaves. Each sensor equipped with an RS485
interface has a specific time slot/memory area within the packet in which to read/write information.
Packets are sent at a regular time basis. Each slave turns on it's transmission line only during
its assigned time slot if it has information to send.
This is just how I designed it in order to be low power, simple and deterministic.
To each their own.
I have also used this with 8N1. Like Wayne I am a bit old school.
RS232 is dead! Long live RS232.
Daniel
Regards,
-Wayne
--
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+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/655e40ec-4a33-65a7-77b8-a7168671562d%40Gramlich.Net.
Wayne C. Gramlich
Jan 17, 2022, 12:20:26 PM1/17/22
to hbrob...@googlegroups.com, Wayne Gramlich
Mark:
When it comes to ROS, it is a division of labor issue. microROS pushes the
ROS complexity down into the microcontroller. Other people do most of the
ROS complexity on the Robot host side and keep the message traffic with the
microcontroller(s) simple. There is no right or wrong here. I will comment
that debugging code on the robot host is generally way easier than debugging
code on the microcontroller.
Later tonight, I'll try and produce a post that talks about generic issues
across all topologies -- error detection/correction, latency, power distribution,
discovery, E-stop, debugging, etc.
Regards,
-Wayne
ROS complexity down into the microcontroller. Other people do most of the
ROS complexity on the Robot host side and keep the message traffic with the
microcontroller(s) simple. There is no right or wrong here. I will comment
that debugging code on the robot host is generally way easier than debugging
code on the microcontroller.
Later tonight, I'll try and produce a post that talks about generic issues
across all topologies -- error detection/correction, latency, power distribution,
discovery, E-stop, debugging, etc.
Regards,
-Wayne
Chris Albertson
Jan 17, 2022, 12:45:21 PM1/17/22
to Wayne C. Gramlich, hbrob...@googlegroups.com
I'm not against busses. As I type, I have a dog-bot prototype on my desk and it uses I2C bus. Yes, it simplifies the software. I got rid of an entire microcontroller.
There is another bus you could add to your list. Have you seen the new kind of low-cost serial bus servos? I plan to buy a couple as a sample to learn. Position feedback and control of the rotation rate are good features. Prices start at $17 with overnight Prime shipping.
I saw the Romi robot arm too. It seemed expensive at first. But, no, it comes with three modified servos, so the price is actually good. As an example project, Pololu nailed it. A table bot that can lift objects into a container for under $200
Going bigger is REALLY hard because all the interesting objects to see and move are at table or counter height from the floor. This vertical dimension is expensive to deal with.
As for a simulation environment. Everyone would think of rviz or gazebo. But I'm looking at PyBullet.
Chris Albertson
Jan 17, 2022, 6:34:45 PM1/17/22
to hbrob...@googlegroups.com
On Mon, Jan 17, 2022 at 8:48 AM danielemc2 via HomeBrew Robotics Club <hbrob...@googlegroups.com> wrote:
Hi all,Also important in the robotics' world is EtherCat.An Ethernet host with a memory mapped payload that is sent to all slaves in a ring topology.
Custom slave ICs make this bus non-practical for hobby robots in general.
There is an Open Source Ethercat implementation. The Master runs on Linux/Mac and Windows. It is used for industrial machine control. (Yes, there are many hobbyists who are doing this.) The advantage of Ethercat is that (1) the host computer likely already has Ethernet and (2) the maximum cable length is something like 100 meters and (3) many buildings have this cable installed already.
Ethercat is like Ethernet but with very deterministic timing
It would have a use in hobby robotics if the robot were an arm and your control computer was (say) a notebook PC that happened to have an Ethernet port.
danie...@aol.com
Jan 17, 2022, 8:21:21 PM1/17/22
to hbrob...@googlegroups.com
"It
would have a use in hobby robotics if the robot were an arm and your
control computer was (say) a notebook PC that happened to have an
Ethernet port."
Yes there are some great use cases for servo control. Usually in high cost factory scenarios.
Most hobby bots can't take advantage of EtherCat as an interconnect for all servos and sensors.
Each would need an ESC (EtherCat Slave Controller). Usually an expensive option for the hobbyist.But maybe a hybrid approach would work...IE. A quadruped with four limb control boards talking to a main controller via EtherCat.
There is a very good definition of EtherCat at https://dewesoft.com/daq/what-is-ethercat-protocol.
My quadruped development platform uses FD CAN. At 5 Mbs and a fault tolerant bus it does the job quite well.
FD CAN transceivers are comparably cheap.
But still EtherCat sounds cool and I want to try it some day.
-----Original Message-----
From: Chris Albertson <alberts...@gmail.com>
To: hbrob...@googlegroups.com
Sent: Mon, Jan 17, 2022 3:34 pm
Subject: Re: [HBRobotics] Re: Robot Peripherals: Topic Topology
From: Chris Albertson <alberts...@gmail.com>
To: hbrob...@googlegroups.com
Sent: Mon, Jan 17, 2022 3:34 pm
Subject: Re: [HBRobotics] Re: Robot Peripherals: Topic Topology
--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
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
Wayne C. Gramlich
Jan 18, 2022, 12:47:57 AM1/18/22
to hbrobotics
All:
Regardless of the Peripheral Topology, there are a number of common issues that
need to be dealt across all topologies. In no particular order:
* Power Distribution:
It necessary to provide power to each peripheral.
Some peripheral systems have power built in (e.g. USB), some have it optional
(e.g. Power over Ethernet), and others do not really discuss the issue (e.g. I2C).
* Local Voltage Regulation:
The further away the peripheral is from the main power source, the more important
it is to consider having local power regulation. In general, linear voltage
regulators are really cheap. While low drop out voltage regulators have a fairly
small voltage drop, it is non-zero. However, dropping 5V down to 3.3V is really
common.
* Rapid Current Change:
Ground bounce occurs when you have large swings in current running over thin
conductors. It occurs most commonly when you have a motor/servo stall.
It usually manifests itself by resetting the local microcontroller. (Yes,
many HBRC club members have had this problem.) The easiest solution tends to
be to give your high current devices a private power bus. Ultimately, wire is cheap.
* Shorts:
Sometimes shorts occur. When they occur does the robot halt and catch fire,
or does some sort of fuse blow or what? Fuses are cheap. The down side
is that when a fuse blows, it frequently does not give any visual indication,
so time can be wasted before the blown fuse is discovered. It just stares back
at you without telling you why it blew.
* Power Monitoring:
In general, it is a good idea to add some sort of power monitoring system
to your robot. Voltage ripple and current spikes are useful to identify
and correct.
* Motor Braking:
Sometimes when you actively slow down a motor using a 4 quadrant motor controller
(Forward/Reverse x Power/Braking), the extra power that is generated is dumped
onto the power bus. This can cause all sorts of problems. Sometimes the
right thing to do is to have a resistor bank that kicks in when the motor is
braking. Putting the resistor network on the motor controller is prudent design.
* E-stop:
Amateur robots don't really *need* E-stop, but when they are about to smash
into a table with the expensive vase on it, it is kind of handy to have.
The trick with E-stop is to be sure that it does not accidentally fail without
knowing it. A current loop system, where breaking the current loop causes
E-stop is pretty fail safe. If the E-stop button is broken, the vase gets to
meet the floor. It is nice if the E-stop just stops the robot, but does
not shut everything else down. Lastly, the host system needs to be informed
that robot is in E-stop so can stop retying to break things and instead ask
for outside help.
* Error Detection/Correction:
Sometimes a bit gets flipped. It is necessary to detect the flip with some
sort of CRC check. CAN-Bus hardware has it built in. Others, not so much.
When an error is detected, the packet needs to be re-transmitted. In general,
it is best to put this complexity on the robot host rather than into each
peripheral.
* Latency:
It can be hard to guarantee the maximum latency in most peripheral systems.
It is part of the design space of the peripheral system to understand what
latency issues are.
* Debugging:
This is a broad subject. There is the issue of how to debug the firmware that
is on each microcontroller. In addition, the software on the robot host needs to
be debugged as well, although that is usually easier. For a bus architecture where
every node on the bus sees the same packet, it is useful to be able to deploy a bus
logger/sniffer that records the packet traffic. Another aspect of debugging is
to monitor bus voltages and currents to see if there is any misbehavior going on.
Lastly, being able to debug software on the host side is important as well.
* Discovery:
Discovery is a powerful tool that lets the host robot scan the peripherals to
find out what peripherals are available. USB really shines in this space.
Ethernet has a more complicated system with a bunch of RFC's that generally
goes under the name "zero conf" that provide discovery. It works, but it is not
as solid as USB. Most other buses punt on the discovery issue.
* Connector Integrity:
Some connectors are more reliable than others. The biggest issue is whether the
connector can accidentally plugged in backwards or be off by one. This is a classic
problem with ribbon cable connectors. Shrouded/keyed connectors can help address
this issue. In theory, vibration could be an issue as well. If the connector
does not have a positive lock, it can potentially vibrate free. That being said,
for amateur robotics, vibration is not likely to be much of an issue.
* Cost:
In general, but not always, the more you spend the better the system. Historically,
amateur robotics has been very price sensitive. However, there are sometimes when
days are spent tracking down a problem that could have been solved by spending a
little more money in the first place. It is trivial to fall into a trap when
designing a peripheral system, of trying to save a few penny's at the cost of
making the entire system harder to use and deploy. I personally have fallen
into this trap multiple times.
* Peripheral Development Time:
Some peripherals are easier to build and deploy than others. The best ones are
ones that can be bought off the shelf. Unfortunately, sometimes the peripheral
you need is not yet available off the shelf. What is the level of effort to develop
a new peripheral? An ideal system would be easy to bread board and from there convert
into a custom PCB. Likewise, how hard is it to develop the firmware that runs locally
on the peripheral? Ease of development is a huge win.
With that, I'm going to stop for now.
Regards,
-Wayne
Regardless of the Peripheral Topology, there are a number of common issues that
need to be dealt across all topologies. In no particular order:
* Power Distribution:
It necessary to provide power to each peripheral.
Some peripheral systems have power built in (e.g. USB), some have it optional
(e.g. Power over Ethernet), and others do not really discuss the issue (e.g. I2C).
* Local Voltage Regulation:
The further away the peripheral is from the main power source, the more important
it is to consider having local power regulation. In general, linear voltage
regulators are really cheap. While low drop out voltage regulators have a fairly
small voltage drop, it is non-zero. However, dropping 5V down to 3.3V is really
common.
* Rapid Current Change:
Ground bounce occurs when you have large swings in current running over thin
conductors. It occurs most commonly when you have a motor/servo stall.
It usually manifests itself by resetting the local microcontroller. (Yes,
many HBRC club members have had this problem.) The easiest solution tends to
be to give your high current devices a private power bus. Ultimately, wire is cheap.
* Shorts:
Sometimes shorts occur. When they occur does the robot halt and catch fire,
or does some sort of fuse blow or what? Fuses are cheap. The down side
is that when a fuse blows, it frequently does not give any visual indication,
so time can be wasted before the blown fuse is discovered. It just stares back
at you without telling you why it blew.
* Power Monitoring:
In general, it is a good idea to add some sort of power monitoring system
to your robot. Voltage ripple and current spikes are useful to identify
and correct.
* Motor Braking:
Sometimes when you actively slow down a motor using a 4 quadrant motor controller
(Forward/Reverse x Power/Braking), the extra power that is generated is dumped
onto the power bus. This can cause all sorts of problems. Sometimes the
right thing to do is to have a resistor bank that kicks in when the motor is
braking. Putting the resistor network on the motor controller is prudent design.
* E-stop:
Amateur robots don't really *need* E-stop, but when they are about to smash
into a table with the expensive vase on it, it is kind of handy to have.
The trick with E-stop is to be sure that it does not accidentally fail without
knowing it. A current loop system, where breaking the current loop causes
E-stop is pretty fail safe. If the E-stop button is broken, the vase gets to
meet the floor. It is nice if the E-stop just stops the robot, but does
not shut everything else down. Lastly, the host system needs to be informed
that robot is in E-stop so can stop retying to break things and instead ask
for outside help.
* Error Detection/Correction:
Sometimes a bit gets flipped. It is necessary to detect the flip with some
sort of CRC check. CAN-Bus hardware has it built in. Others, not so much.
When an error is detected, the packet needs to be re-transmitted. In general,
it is best to put this complexity on the robot host rather than into each
peripheral.
* Latency:
It can be hard to guarantee the maximum latency in most peripheral systems.
It is part of the design space of the peripheral system to understand what
latency issues are.
* Debugging:
This is a broad subject. There is the issue of how to debug the firmware that
is on each microcontroller. In addition, the software on the robot host needs to
be debugged as well, although that is usually easier. For a bus architecture where
every node on the bus sees the same packet, it is useful to be able to deploy a bus
logger/sniffer that records the packet traffic. Another aspect of debugging is
to monitor bus voltages and currents to see if there is any misbehavior going on.
Lastly, being able to debug software on the host side is important as well.
* Discovery:
Discovery is a powerful tool that lets the host robot scan the peripherals to
find out what peripherals are available. USB really shines in this space.
Ethernet has a more complicated system with a bunch of RFC's that generally
goes under the name "zero conf" that provide discovery. It works, but it is not
as solid as USB. Most other buses punt on the discovery issue.
* Connector Integrity:
Some connectors are more reliable than others. The biggest issue is whether the
connector can accidentally plugged in backwards or be off by one. This is a classic
problem with ribbon cable connectors. Shrouded/keyed connectors can help address
this issue. In theory, vibration could be an issue as well. If the connector
does not have a positive lock, it can potentially vibrate free. That being said,
for amateur robotics, vibration is not likely to be much of an issue.
* Cost:
In general, but not always, the more you spend the better the system. Historically,
amateur robotics has been very price sensitive. However, there are sometimes when
days are spent tracking down a problem that could have been solved by spending a
little more money in the first place. It is trivial to fall into a trap when
designing a peripheral system, of trying to save a few penny's at the cost of
making the entire system harder to use and deploy. I personally have fallen
into this trap multiple times.
* Peripheral Development Time:
Some peripherals are easier to build and deploy than others. The best ones are
ones that can be bought off the shelf. Unfortunately, sometimes the peripheral
you need is not yet available off the shelf. What is the level of effort to develop
a new peripheral? An ideal system would be easy to bread board and from there convert
into a custom PCB. Likewise, how hard is it to develop the firmware that runs locally
on the peripheral? Ease of development is a huge win.
With that, I'm going to stop for now.
Regards,
-Wayne
Dave Everett
Jan 18, 2022, 6:20:10 AM1/18/22
to hbrob...@googlegroups.com
On Tue, 18 Jan 2022 at 03:19, Mark Womack <mwo...@gmail.com> wrote:
Chris:On Sat, Jan 15, 2022 at 8:41 PM Chris Albertson <alberts...@gmail.com> wrote:One thing I found is that differential drive no longer works when the robot count top tall. You need four wheels for stability and casters just do not work over bumps. All four wheels need power. Then you have to thnk about steering There are a few options1) the robot turns like a tank be skidding, this works poorly on high friction floors like hardwood2) Steer the front (or rear) wheels only. This is call Akerman" and is that most cars do.3) Steer both front and rear wheels. This dramatically improves mobility but is twice as complex. But allows things like "spin in place" pr easy parallel parking is the robot can drive to a counter or table then turn all four wheel 90 degrees and move laterally. If the robot has an arm, four-wheel steering can allow the arm to have one or two fewer degrees of freedom.
There is also synchronous drive. This is where all wheels steer and drive, usually under the control of only 2 motors so a simple Turn Velocity scheme can be applied.
This method requires mechanical linkages either through belts or chains, then mitre or bevel gears to change the angle of the rotation. While this is initially more complex, it results in the most stable and manouverable type of robot base possible at present.
RWI (Real World Interface) used to make these kinds of bases. The 30cm base had 3 wheels and the 40cm one had 4. I've always been more in favour of 3 wheels as this ensures ALL wheels are in contact with the ground. 4 wheels can result in an unstable base as uneven floors can cause the robot to pitch on 3 wheels.
Mark Womack
Jan 18, 2022, 10:02:06 AM1/18/22
to hbrob...@googlegroups.com
The three wheels would be evenly spaced out? How much freedom does each wheel have? 360 degrees?
If the electric motors are below the robot platform with a bar that extends up, then you just need a motor/servo to turn the bar for steering. No gear drive translation required?
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/CAG61pbfkyY-FujECc55paC41XbdPgFq3tn9jLuHhb6HQ6R1p3g%40mail.gmail.com.
danie...@aol.com
Jan 18, 2022, 10:52:09 AM1/18/22
to hbrob...@googlegroups.com
"With that, I'm going to stop for now."
Actually this is such good detailed advice maybe we should expand on it and add it to the HBRC website.
Regards,
-Wayne
--
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+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/f31178e0-2887-f42a-d413-5e4de1346bcf%40Gramlich.Net.
Dave Everett
Jan 18, 2022, 4:01:07 PM1/18/22
to hbrob...@googlegroups.com
On Wed, 19 Jan 2022 at 02:02, Mark Womack <mwo...@gmail.com> wrote:
The three wheels would be evenly spaced out?
Yes, all evenly spaced.
How much freedom does each wheel have? 360 degrees?
Yes, so you can point the base in any direction and move dynamically around obstacles.
The upper body also rotated with the steering motor so the robot always faces the forward vector.
I was looking around for some video to post, but this was all in the early to late 90s so no youtube then.
Here's a link to some photos. Sadly I missed out on buying this base, the only used one I ever saw for sale. New they were about $8000
Dave
Chris Albertson
Jan 18, 2022, 6:11:06 PM1/18/22
to hbrob...@googlegroups.com
Three wheels is not very stable, especially when a single wheel is in front. I seems like it might be stable but the problem is when you apply the brakes and are not facing exactly dead-forward. Even if a small stone gets under a wheel it has the effect of brakes. Notice they stopped making three-wheel ATVs like this because of the number of injured riders. It does work fine if the vehicle is much shorter than wide. You are also better if you place two wheels in front.
But many times a robot drives backward so you can't avoid a single wheel in front type tip-over.
But even if stopped on a flat floor, the size of the contact polygon is small compared to a square with equal length sides. The square gives you double the stability with only one more wheel. (We measure stability by the distance from the center of gravity to the nearest polygon edge.)
Both all this is premature. You first have to define the robot's workspace. It is at a home and with in 18 inches of the floor or is it rolling on the floor but working at counter-top level.
--
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/CAG61pbfnEzTvpuvvuKuh7SULkPm4TeuLWBU%2BafHzqZ1psWb7fg%40mail.gmail.com.
Chris Albertson
Jan 18, 2022, 8:41:56 PM1/18/22
to hbrob...@googlegroups.com
On Mon, Jan 17, 2022 at 8:19 AM Mark Womack <mwo...@gmail.com> wrote:
Chris:
I'd like to follow this line of thinking and design a bit. What is the difference in the level of difficulty? Steering of wheels suggests a servo or multiple servos, some kind of mechanical connection to the wheels, etc. How easy would this be with easy-to-gather parts? (I'm not arguing it is too complex, I am trying to understand the space for someone coming to it after building Bart).
There really is no optpn. You MUST provide some way to steer. "tank-track" steering is simply using two differential drive systems on one chassis. But ALWAYS with this system, two wheels MUST skid in a direction parallel to the axle.
If you don't like skidding then you have two options for the mechanics
(1) What almost all cars use including hobby size R/C cars. A pair of wheels is mounted on kingpins and connected with a tie rod and the tie rod is pushed and pulled to move both wees at the same time. This can be placed on one end or both. Some cars have four wheel steering. The problems with this system are (1) design and building require engineering skills and likely some custom metalworking and (2) the pivot point around which the robot drives has to be some distance to the side of the robot, not under it so the robot can drive a tight radius but not spin in place.
I have a robot like this, or rather I am slowly building one. It's purpose is driving on public sidewalks. The steering is very car-like and well suited to sidewalks.
The other steering system is to place each drive wheel on a caster-like mount that allows the wheel and its drive motor to turn around a vertical axis. I think the simplest way to build this is to (1) build half of a differential drive system with the motor and wheel UNDER a small platform. then mount a vertical axel to the platform. Then on the main robot chassis you make a hole the vertical axis fits through. and connect the vertical axis to a motor of some kind. Pulleys and belts, gears or direct coupling all work. You might want a sensor on this to measure angle It is just like a drive wheel.
You can make a tiny version of this with two hobby servos and some hot glue The first servo must be setup for 360 degree, continuous rotation and the second steering servo has its horn screwed to the chassis.
Back to the question. Relative to the Romi-based table-bot a four-wheel drive robot has 6 motors to control vs. two. If all four wheels steer then there are eight motors. But is it more complex? No, just more of the same parts. It is more work to build but it is still just motors.
SUSPENSION: This is hard to get right. When you have more than three wheels you'd want some way to keep all four in contact with the ground, even on imperfect floors. The simplest way is to use soft tires. Next, you could try springs between the wheels and the chassis. Both are bad for taller robots. If the robot is taller than it is wide then the body will lean and create a force on the spring and further compress it which makes it lean more. Only low to-the ground, light weight robots can use a full-spring suspension. You NEVER see this used on cars. Soft springs do not control body orientation.
The simplest to build four wheel suspension is the one used on almost all forklifts. They are like our robot in that they need all four wheel on the ground but absolutely they cannot to by allowed to lean, A forklift has the front wheels mounted solid to the chassis and the rear wheels mounted to a beam that is allowed to move on an axes that points for and aft. No springs are required
We think springs are required because our cars have springs but the real reason the car has springs is to absort impact energy. The Mar rover rides over very rough ground but has no springs. Springs are if you need to go fast.
A robot who's function is to load dishes off a table with an arm needs to have a forklift-like suspension. These can't lean by compressing springs.
Springs and soft tires only work if the robot is low to the ground or very light weight otherwise you MUST constrain the spring movement with tie-rod, hinges, levers or beams. All cars and trucks do this. Look under a car and you see the wheels are allowed to move only in a few fixed directions
The next step is "legs" If you want the best general purpose robot, make a humanoid.
I'm also still interested in the "advanced casters" that Wayne mentioned. Is that ust casters with spring suspension?I'd argue for a modular approach. Design two sets of wheel (A) Fixed and (B) steerable. The can be attached to the same chassis. Then using two sets of (A) you have option (1) above. if you build one (A) and one (B) you have option (2) above. Building two of the (B) sets allow full four wheel steeringAll would use the same motors and wheels you a person could start cheap then upgrade.I like this idea, it would be a lot of options mechanically and software though. I feel like we would be better off choosing the best option for a home-based robot (see below) and go with it from the start.Make it big enough to move a 60-pound robot as you need that mass to lift (say) a coffee cup off a table if it is a couple of feet from the edge.I am thinking that there has been enough interest expressed in a home-based larger robot that we should make it an explicit goal of the Homer bot. When we were discussing earlier about know what exactly the robot would do, I think this starts to cover that base.The key to success in such a project is clean interfaces. Simple things like establishing a bolt pattern for the arm to body to the two parts can be developed independently. For for the arm-to-hand and choosing a bus.The physics are going to matter a lot more in this project because of the size and the tasks being considered, so I totally agree with this. Maybe we could design a general "deck" or "shoulder" that allows for lots of connection points. Kind of like the way the Romi base has so many places to run bolts and attach things.I'd contribute CAD work to such a project.Awesome! What would you add to the phases to capture this increased level of functionality and complexity?-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/CAF-TXgv6R6cBANcn5RbXz92QONHVWP2MJJJQPLcGeg8tD2_jPw%40mail.gmail.com.
Wayne C. Gramlich
Jan 18, 2022, 8:59:59 PM1/18/22
to hbrob...@googlegroups.com, Wayne Gramlich
On 1/18/22 3:10 PM, Chris Albertson wrote:
> Three wheels is not very stable, especially when a single wheel is in
> front. I seems like it might be stable but the problem is when you apply
> the brakes and are not facing exactly dead-forward. Even if a small stone
> gets under a wheel it has the effect of brakes. Notice they stopped
> making three-wheel ATVs like this because of the number of injured riders.
> It does work fine if the vehicle is much shorter than wide. You are also
> better if you place two wheels in front.
>
> But many times a robot drives backward so you can't avoid a single wheel in
> front type tip-over.
>
> But even if stopped on a flat floor, the size of the contact polygon is
> small compared to a square with equal length sides. The square gives you
> double the stability with only one more wheel. (We measure stability by
> the distance from the center of gravity to the nearest polygon edge.)
>
> Both all this is premature. You first have to define the robot's
> workspace. It is at a home and with in 18 inches of the floor or is it
> rolling on the floor but working at counter-top level.
I would like to add here that there are two levels of stability. Static
> Three wheels is not very stable, especially when a single wheel is in
> front. I seems like it might be stable but the problem is when you apply
> the brakes and are not facing exactly dead-forward. Even if a small stone
> gets under a wheel it has the effect of brakes. Notice they stopped
> making three-wheel ATVs like this because of the number of injured riders.
> It does work fine if the vehicle is much shorter than wide. You are also
> better if you place two wheels in front.
>
> But many times a robot drives backward so you can't avoid a single wheel in
> front type tip-over.
>
> But even if stopped on a flat floor, the size of the contact polygon is
> small compared to a square with equal length sides. The square gives you
> double the stability with only one more wheel. (We measure stability by
> the distance from the center of gravity to the nearest polygon edge.)
>
> Both all this is premature. You first have to define the robot's
> workspace. It is at a home and with in 18 inches of the floor or is it
> rolling on the floor but working at counter-top level.
stability is when the robot is motionless and the center of gravity is in
the polygon of where the wheels touch the floor. (Just like Chris said).
Dynamic stability is when the robot is in motion. The higher the center
of gravity is, the larger the torques are that occur on the robot when it is
accelerating/decelerating. When the torque is too large, the robot tips
over. For fun, watch some fork lift fail videos where they turn over.
That is why operators lower the payload closer to the ground before zipping
around the warehouse.
Regards,
-Wayne
Richard Chycoski
Jan 18, 2022, 11:41:51 PM1/18/22
to hbrob...@googlegroups.com
Many FRC robots use 'West Coast Drive', six wheel, tank-drive to
run, where the middle wheel of each side is slightly lower than the
outside four wheels, such that the robot usually drives on the back
four or front four wheels (out of six). Think about what happens
during acceleration, where the robot leans back and the (currently)
rear and middle wheels make contact.
It is a massive attempt to get four-wheel-stability in most situations - and if you need to get a robot to move quickly, but not necessarily precisely - can work. It is less helpful in close-in situations. It does work well for many 2:30 FRC competitions. :-)
I bring this up because you need to consider the operating conditions where your robot is going to run when you pick a drive train. Don't pick something that you read that does not jive with your own operating conditions.
Find (or develop) a drive train that suits the needs of your particular operating circumstances. Fork lift drive may work well on a storage floor that is very flat, but fail spectacularly when some gravel, ice, or unleveled ramp appear.
- Richard, VE7CVS
It is a massive attempt to get four-wheel-stability in most situations - and if you need to get a robot to move quickly, but not necessarily precisely - can work. It is less helpful in close-in situations. It does work well for many 2:30 FRC competitions. :-)
I bring this up because you need to consider the operating conditions where your robot is going to run when you pick a drive train. Don't pick something that you read that does not jive with your own operating conditions.
Find (or develop) a drive train that suits the needs of your particular operating circumstances. Fork lift drive may work well on a storage floor that is very flat, but fail spectacularly when some gravel, ice, or unleveled ramp appear.
- Richard, VE7CVS
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHtk6b39xhGyBwPO1K795vuf3escf%2BgkjdBS3SRUMbYecQ%40mail.gmail.com.
Dave Everett
Jan 19, 2022, 4:36:51 AM1/19/22
to hbrob...@googlegroups.com
On Wed, 19 Jan 2022 at 10:11, Chris Albertson <alberts...@gmail.com> wrote:
Three wheels is not very stable, especially when a single wheel is in front.
Yeah that's why 3 leg stools fall over all the time and 4 leg stools never wobble :)
The key always is to keep the weight at the bottom, it's doesn't matter what type of drive you are building, keeping weight at the bottom is crucial. You can also determine a safe speed to accelerate and decelerate at to remove almost all tipover danger. In a telepresence robot I built some years back, I also used IMU data when the robot was going up or down a ramp to modify the accel/decel.
Chris Albertson
Jan 19, 2022, 1:35:25 PM1/19/22
to hbrob...@googlegroups.com
That is actually how to do it, use an IMU. If the vector points outside the support polygon then you are in the process of falling. As it turns out the IMU vector's direction can't know the difference between gravity, acceleration or if the robot is on a ramp. It just gives you the total combined effect.
A "balance bot" runs a PID loop to move the base such that the base is always where this vector points to. You can see many of the more sophisticated and tall robots doing this too. They can move quickly in the direction they are falling. I think we have all seen the videos by Boston Dynamics where someone shoves the robot with their foot or a hockey stick and the robot takes a few steps back to recover balance. It is just like a two-wheel balance-bot but only in two dimensions.
The advice to keep the weight low is good but impossible to follow if the robot's use-case is working with objects at table or countertop height. As soon as the robot lifts the beer from the fridge self it now has 12 oz of weight several feet off the ground. It was worse while it was moving the 2-liter soda bottle out of the way to reach the beer.
Yes the four legged stool rocks, that this why sysension is needed on four-wheel robots. The goal is to keep equal amount of weight on each wheel. It is probably best to copy the design used in forklifts.
--
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/CAG61pbdwzu2RE0kHQz00bsy%2Bx%3D6iC36qHzqPAbkDAzWFtika0Q%40mail.gmail.com.
Wayne C. Gramlich
Jan 20, 2022, 10:49:34 PM1/20/22
to hbrobotics, Wayne Gramlich
All:
Now that I have given a dump of what I know about robot peripheral subsystems,
the next question is "what next?"
In general technology keeps getting better and cheaper. Design decisions that
made sense a while ago may not make as much sense right now.
For low bandwidth peripherals, I went into this discussion with a definite leaning
towards my previous buses that used 8N1 on ISO-11898. As I have thought about it
some more, I have reconsidered my position.
I'll cut to the chase here, USB has gotten less expensive, more hackable, and
more available. When I look at the Raspberry Pi Pico, my general reaction is
$4 is really cheap!" Could a tree of Raspberry Pi Pico's do the trick?
It might just work!
So I bought a few RPi Pico's off of Amazon and did some initial experimentation.
* Installing MicroPython was drop dead easy. (I haven't tried C/C++ yet.)
* I plugged two into my laptop and `/dev/ttyAMA0` and `/dev/ttyAMA1` showed up.
* I can run two minicom's (minicom is a dumb terminal emulator) and talk to each
separately. I'm liking this.
I also bought the book "Get Started with MicroPython on Raspberry Pi Pico".
This book is definitely geared to towards younger people, but it hit the high points.
There is a library that lets you access all of the peripherals -- I2C, SPI,
UART, ADC, and GPIO. They support multi-threading, interrupt handlers, etc.
Again, it looks workable.
For each new peripheral, the Pico can have headers soldered onto it, plugged into
a standard breadboard and connected up with standard jumper cables. When all the
software is debugged, the breadboard design can be transferred to a PCB. The
RPi Pico's can be treated as a SOM (System On Module) board that can directly be
soldered onto PCB's using surface mount technology. (Yes, you can get reels of
RasPi Pico's that can be inserted into pick and place machines; my 3 Pico's were
cut off of such a reel.)
I want to be clear here. This architecture is not restricted to just the Pico.
It can work with any microcontroller that can talk to USB. Some people love other
microcontroller, they can fit in just as well. The bottom line is that electrically,
it could work.
Getting the software to work properly is just as important. My initial thought
is that there will be one ROS node for each peripheral (i.e. Pico). At startup,
a discovery process would find all of the Pico's (i.e. scan /dev/ttyAMA*), open
a connection, use a standard discovery protocol and start appropriate ROS node
for each peripheral. Once the dedicated ROS node starts up and connects to the
Pico, they can use whatever protocol that makes sense. The ROS node can publish
and subscribe to the appropriate ROS topics and use or provide ROS services.
There would be some mundane issues like recommending standard board sizes, mounting
hole positions, connector placements, etc.
Lastly, the one thing that USB does not really support is higher power for
servos/motors, etc. I would probably put power distribution on a 10-wire IDC
(Insulation Displacement Connector) with 8 wires for power and 2 wires for
E-stop, but that is just me. There are some interesting issues with ensuring that
there are no ground loops for the power distribution and the USB ground bus, but
that is pretty workable.
I'm going to stop here and see what other people think. The idea is not fully
cooked, but it has the potential to gel into something interesting. What I
really like is that the barrier to entry is cheap ($4 per Pico!).
Regards,
-Wayne
Now that I have given a dump of what I know about robot peripheral subsystems,
the next question is "what next?"
In general technology keeps getting better and cheaper. Design decisions that
made sense a while ago may not make as much sense right now.
For low bandwidth peripherals, I went into this discussion with a definite leaning
towards my previous buses that used 8N1 on ISO-11898. As I have thought about it
some more, I have reconsidered my position.
I'll cut to the chase here, USB has gotten less expensive, more hackable, and
more available. When I look at the Raspberry Pi Pico, my general reaction is
$4 is really cheap!" Could a tree of Raspberry Pi Pico's do the trick?
It might just work!
So I bought a few RPi Pico's off of Amazon and did some initial experimentation.
* Installing MicroPython was drop dead easy. (I haven't tried C/C++ yet.)
* I plugged two into my laptop and `/dev/ttyAMA0` and `/dev/ttyAMA1` showed up.
* I can run two minicom's (minicom is a dumb terminal emulator) and talk to each
separately. I'm liking this.
I also bought the book "Get Started with MicroPython on Raspberry Pi Pico".
This book is definitely geared to towards younger people, but it hit the high points.
There is a library that lets you access all of the peripherals -- I2C, SPI,
UART, ADC, and GPIO. They support multi-threading, interrupt handlers, etc.
Again, it looks workable.
For each new peripheral, the Pico can have headers soldered onto it, plugged into
a standard breadboard and connected up with standard jumper cables. When all the
software is debugged, the breadboard design can be transferred to a PCB. The
RPi Pico's can be treated as a SOM (System On Module) board that can directly be
soldered onto PCB's using surface mount technology. (Yes, you can get reels of
RasPi Pico's that can be inserted into pick and place machines; my 3 Pico's were
cut off of such a reel.)
I want to be clear here. This architecture is not restricted to just the Pico.
It can work with any microcontroller that can talk to USB. Some people love other
microcontroller, they can fit in just as well. The bottom line is that electrically,
it could work.
Getting the software to work properly is just as important. My initial thought
is that there will be one ROS node for each peripheral (i.e. Pico). At startup,
a discovery process would find all of the Pico's (i.e. scan /dev/ttyAMA*), open
a connection, use a standard discovery protocol and start appropriate ROS node
for each peripheral. Once the dedicated ROS node starts up and connects to the
Pico, they can use whatever protocol that makes sense. The ROS node can publish
and subscribe to the appropriate ROS topics and use or provide ROS services.
There would be some mundane issues like recommending standard board sizes, mounting
hole positions, connector placements, etc.
Lastly, the one thing that USB does not really support is higher power for
servos/motors, etc. I would probably put power distribution on a 10-wire IDC
(Insulation Displacement Connector) with 8 wires for power and 2 wires for
E-stop, but that is just me. There are some interesting issues with ensuring that
there are no ground loops for the power distribution and the USB ground bus, but
that is pretty workable.
I'm going to stop here and see what other people think. The idea is not fully
cooked, but it has the potential to gel into something interesting. What I
really like is that the barrier to entry is cheap ($4 per Pico!).
Regards,
-Wayne
Chris Albertson
Jan 21, 2022, 12:51:52 AM1/21/22
to hbrob...@googlegroups.com
I lot of peole, maybe even "almost everyone" actually uses USB to connect the microcontroller to the bigger computer. Yes it works well and is easy to do and both devices already have a connector made for this and you can buy the cables at Walmart.
About the lack of power, The world is moving to USB-C. There are a few of the $4 Picos now with USB-C. The current standard allows 100 watts over USC-C and this is changing to 240 W. You could run a medium sized robot motr over USB-C
The other good thing about USB, and one reason everyone use it is that you can plug it into a PC desktop computer and do the development and test.
The other thing that caught my eye was the suggestion of one ROS node per Pico. That would be a huge waste of a Pico and cause data to be ping-ponged through the cables and bridge nodes on the Pi4. For example if I have a Pico that is running a set of two or thee ultra sonic sensors. I need a node to run the sensors and broadcast the messages. But I also might want a node to listen to those messages and detects objects and figure out if the robot is getting closer or farther from the object. You would want those on the same Pico.
If nodes are on the same chip they now can use shared memory to communicate messages, so no data moves, just pointers. it is very fast compared to a round trip over USB. This is a good reason to place more nodes on the same chip
BTW, for others wanting to look at the Pico, Micro Pythone makes it dead easy. People think Python is slow. No. Even with Python it is an order of magnitude faster than Arduino. and 4X lower cost.
--
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/2f650bfd-d84b-3fb1-4c0a-a86da3e15909%40Gramlich.Net.
Wayne C. Gramlich
Jan 21, 2022, 1:48:35 AM1/21/22
to hbrob...@googlegroups.com, Wayne Gramlich
Chris:
On 1/20/22 9:51 PM, Chris Albertson wrote:
> I lot of peole, maybe even "almost everyone" actually uses USB to connect
> the microcontroller to the bigger computer. Yes it works well and is easy
> to do and both devices already have a connector made for this and you can
> buy the cables at Walmart.
No argument about the utility of USB, availability of cables, etc.
There are not many USB robot peripherals available right now, sonars,
TOF sensors, etc. If you find them off the shelf, use them rather than
build your own.
> About the lack of power, The world is moving to USB-C. There are a few of
> the $4 Picos now with USB-C. The current standard allows 100 watts over
> USC-C and this is changing to 240 W. You could run a medium sized
> robot motr over USB-C
I was only playing with the Pico which is micro-USB. USB-C is an acceptable
alternative to a separate power bus.
> The other good thing about USB, and one reason everyone use it is that you
> can plug it into a PC desktop computer and do the development and test.
Agreed. People tend to under appreciate the value of easy to use development tools.
> The other thing that caught my eye was the suggestion of one ROS node per
> Pico. That would be a huge waste of a Pico and cause data to be
> ping-ponged through the cables and bridge nodes on the Pi4. For
> example if I have a Pico that is running a set of two or thee ultra
> sonic sensors. I need a node to run the sensors and broadcast the
> messages. But I also might want a node to listen to those messages and
> detects objects and figure out if the robot is getting closer or farther
> from the object. You would want those on the same Pico.
>
> If nodes are on the same chip they now can use shared memory to communicate
> messages, so no data moves, just pointers. it is very fast compared to a
> round trip over USB. This is a good reason to place more nodes on the
> same chip
It's late an night. I've read the paragraphs above several times I can't make
sense of them right now. I'll try again tomorrow morning, when my brain
is a bit more functional.
> BTW, for others wanting to look at the Pico, Micro Pythone makes it dead
> easy. People think Python is slow. No. Even with Python it is an order
> of magnitude faster than Arduino. and 4X lower cost.
No argument about micro-python. For many, many applications it is more than
adequate.
Regards,
-Wayne
[snippage]
On 1/20/22 9:51 PM, Chris Albertson wrote:
> I lot of peole, maybe even "almost everyone" actually uses USB to connect
> the microcontroller to the bigger computer. Yes it works well and is easy
> to do and both devices already have a connector made for this and you can
> buy the cables at Walmart.
There are not many USB robot peripherals available right now, sonars,
TOF sensors, etc. If you find them off the shelf, use them rather than
build your own.
> About the lack of power, The world is moving to USB-C. There are a few of
> the $4 Picos now with USB-C. The current standard allows 100 watts over
> USC-C and this is changing to 240 W. You could run a medium sized
> robot motr over USB-C
alternative to a separate power bus.
> The other good thing about USB, and one reason everyone use it is that you
> can plug it into a PC desktop computer and do the development and test.
> The other thing that caught my eye was the suggestion of one ROS node per
> Pico. That would be a huge waste of a Pico and cause data to be
> ping-ponged through the cables and bridge nodes on the Pi4. For
> example if I have a Pico that is running a set of two or thee ultra
> sonic sensors. I need a node to run the sensors and broadcast the
> messages. But I also might want a node to listen to those messages and
> detects objects and figure out if the robot is getting closer or farther
> from the object. You would want those on the same Pico.
>
> If nodes are on the same chip they now can use shared memory to communicate
> messages, so no data moves, just pointers. it is very fast compared to a
> round trip over USB. This is a good reason to place more nodes on the
> same chip
sense of them right now. I'll try again tomorrow morning, when my brain
is a bit more functional.
> BTW, for others wanting to look at the Pico, Micro Pythone makes it dead
> easy. People think Python is slow. No. Even with Python it is an order
> of magnitude faster than Arduino. and 4X lower cost.
adequate.
Regards,
-Wayne
[snippage]
Wayne C. Gramlich
Jan 21, 2022, 11:36:42 AM1/21/22
to hbrob...@googlegroups.com, Wayne Gramlich
On 1/20/22 10:48 PM, Wayne C. Gramlich wrote:
> Chris:
[snippage]
>> The other thing that caught my eye was the suggestion of one ROS node per
>> Pico. That would be a huge waste of a Pico and cause data to be
>> ping-ponged through the cables and bridge nodes on the Pi4. For
>> example if I have a Pico that is running a set of two or thee ultra
>> sonic sensors. I need a node to run the sensors and broadcast the
>> messages. But I also might want a node to listen to those messages and
>> detects objects and figure out if the robot is getting closer or farther
>> from the object. You would want those on the same Pico.
>>
>> If nodes are on the same chip they now can use shared memory to communicate
>> messages, so no data moves, just pointers. it is very fast compared to a
>> round trip over USB. This is a good reason to place more nodes on the
>> same chip
>
> It's late an night. I've read the paragraphs above several times I can't make
> sense of them right now. I'll try again tomorrow morning, when my brain
> is a bit more functional.
[snippage]
I'm not half asleep now and I understand what you are saying...
I guess a better articulation would be that each Pico can only talk to one
ROS node because only one node can connect the the /dev/ttyAMAx port at a time.
There is no reason why one ROS node can not open multiple /dev/ttyAMAx port's
and talk to all of the at the same time.
I would modify the discovery service to be a Node that scans all of the /dev/ttyAMAx
(on Linux, Windows/MacOS are probably different) talks to each node in "discovery
protocol" and basically reads a JSON file from each Pico. It then provides a ROS
service that provides a dictionary of /dev/ttyAMAx to JSON file bindings. When
other ROS nodes want to connect to their /dev/ttyAMAx, they contact the discovery
service, read the JSON files, and figure out which ones it needs, and then they
open the correct /dev/ttyAMAx and start talking. The details are can be tweaked,
but the concept is that ROS nodes can find their Pico's and talk to them.
Regards,
-Wayne
> Chris:
[snippage]
>> The other thing that caught my eye was the suggestion of one ROS node per
>> Pico. That would be a huge waste of a Pico and cause data to be
>> ping-ponged through the cables and bridge nodes on the Pi4. For
>> example if I have a Pico that is running a set of two or thee ultra
>> sonic sensors. I need a node to run the sensors and broadcast the
>> messages. But I also might want a node to listen to those messages and
>> detects objects and figure out if the robot is getting closer or farther
>> from the object. You would want those on the same Pico.
>>
>> If nodes are on the same chip they now can use shared memory to communicate
>> messages, so no data moves, just pointers. it is very fast compared to a
>> round trip over USB. This is a good reason to place more nodes on the
>> same chip
>
> It's late an night. I've read the paragraphs above several times I can't make
> sense of them right now. I'll try again tomorrow morning, when my brain
> is a bit more functional.
I'm not half asleep now and I understand what you are saying...
I guess a better articulation would be that each Pico can only talk to one
ROS node because only one node can connect the the /dev/ttyAMAx port at a time.
There is no reason why one ROS node can not open multiple /dev/ttyAMAx port's
and talk to all of the at the same time.
I would modify the discovery service to be a Node that scans all of the /dev/ttyAMAx
(on Linux, Windows/MacOS are probably different) talks to each node in "discovery
protocol" and basically reads a JSON file from each Pico. It then provides a ROS
service that provides a dictionary of /dev/ttyAMAx to JSON file bindings. When
other ROS nodes want to connect to their /dev/ttyAMAx, they contact the discovery
service, read the JSON files, and figure out which ones it needs, and then they
open the correct /dev/ttyAMAx and start talking. The details are can be tweaked,
but the concept is that ROS nodes can find their Pico's and talk to them.
Regards,
-Wayne
Chris Albertson
Jan 21, 2022, 3:54:56 PM1/21/22
to hbrob...@googlegroups.com
Ho, you are proposing to place USB on each sensor and motor. I'm not sure I want a USB interface in the micro switch inside my crash bummer or one a single LED or even on an ultrasonic sensor.
The crash-bumper is a good example. A USB interface would be good if it worked at a high level. I have left and right switches on a front and rear bumper. A hard impact dead-on to a wall triggers both switches but if one one end of the bumper hits it triggers only one switch
A USB bumper that analysed where on the robot the impact occurred and send a message would be good. But I don't want one USB cable from each switch. The trouble is the analysis of where the impact happen is different for every robot. They all have different switches in different locations. So the solution is to wires all the switches to a Pico and then go USB from the Pico to the Pi4.
This is true with ultrasonics too. I don't want one USB cable per sensor and I want the micro to "know" where the sensor is pointed so it can add send the right mesage
But the Pico can do more, way not connect it to the ultrasonic sensors. What I ended up with was a "chassis sensor" controller that has a USB interface.
I did the same with the LIDAR, te uP runs a PID to control scanning speed and reformats the LIDAR data to ROS messages.
--
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/f65758fe-012c-da60-4781-8e3ef71b4aa6%40Gramlich.Net.
Mark Womack
Jan 21, 2022, 8:16:37 PM1/21/22
to hbrob...@googlegroups.com
On Fri, Jan 21, 2022 at 3:54 PM Chris Albertson <alberts...@gmail.com> wrote:
Ho, you are proposing to place USB on each sensor and motor. I'm not sure I want a USB interface in the micro switch inside my crash bummer or one a single LED or even on an ultrasonic sensor.The crash-bumper is a good example. A USB interface would be good if it worked at a high level. I have left and right switches on a front and rear bumper. A hard impact dead-on to a wall triggers both switches but if one one end of the bumper hits it triggers only one switchA USB bumper that analysed where on the robot the impact occurred and send a message would be good. But I don't want one USB cable from each switch. The trouble is the analysis of where the impact happen is different for every robot. They all have different switches in different locations. So the solution is to wires all the switches to a Pico and then go USB from the Pico to the Pi4.This is true with ultrasonics too. I don't want one USB cable per sensor and I want the micro to "know" where the sensor is pointed so it can add send the right mesage
I didn't interpret that as what Wayne was saying, but I guess he can speak up. I was thinking that all related sensors would be connected to a single Pico (or other type of microcontroller), not a Pico per sensor. But then, that is what I was talking about in an earlier thread. Subsystems of sensors running directly under a microcontoller which is then in turn wired (vi USB or Ethernet if supported) to send/receive ROS messages with the microcomputer (Pi4). So, maybe I am biased and reading into it. I was talking more about Teensy, Wayne is talking more about Pico. I have to say that I am intrigued. I guess I'll need to get a few to try out.
-Mark
Wayne C. Gramlich
Jan 21, 2022, 8:37:15 PM1/21/22
to hbrob...@googlegroups.com, Wayne Gramlich
All:
Mark is correct. Each Pico (or whatever) has the appropriate devices
connected it. For example, one Pico might be a dual H-bridge in conjunction
with a dual wheel encoder. It would be could be connected to a ROS node that
listens for ROS twist messages and convert them into left/right motor speed
targets. The Pico (or whatever) could choose to implement a PID loop that
implements PID control and Send encoder updates up to ROS to for odemetry
purposes.
All bus/tree architectures have some latency. For bump senors and sonars,
the latency is unlikely to matter. For others, the latency does matter.
This is all part of the fun of robotics.
Regards,
-Wayne
Mark is correct. Each Pico (or whatever) has the appropriate devices
connected it. For example, one Pico might be a dual H-bridge in conjunction
with a dual wheel encoder. It would be could be connected to a ROS node that
listens for ROS twist messages and convert them into left/right motor speed
targets. The Pico (or whatever) could choose to implement a PID loop that
implements PID control and Send encoder updates up to ROS to for odemetry
purposes.
All bus/tree architectures have some latency. For bump senors and sonars,
the latency is unlikely to matter. For others, the latency does matter.
This is all part of the fun of robotics.
Regards,
-Wayne
Mark Womack
Jan 21, 2022, 8:38:12 PM1/21/22
to hbrob...@googlegroups.com
On Fri, Jan 21, 2022 at 11:36 AM Wayne C. Gramlich <wayne.gra...@gmail.com> wrote:
I guess a better articulation would be that each Pico can only talk to one
ROS node because only one node can connect the the /dev/ttyAMAx port at a time.
There is no reason why one ROS node can not open multiple /dev/ttyAMAx port's
and talk to all of the at the same time.
I would modify the discovery service to be a Node that scans all of the /dev/ttyAMAx
(on Linux, Windows/MacOS are probably different) talks to each node in "discovery
protocol" and basically reads a JSON file from each Pico. It then provides a ROS
service that provides a dictionary of /dev/ttyAMAx to JSON file bindings. When
other ROS nodes want to connect to their /dev/ttyAMAx, they contact the discovery
service, read the JSON files, and figure out which ones it needs, and then they
open the correct /dev/ttyAMAx and start talking. The details are can be tweaked,
but the concept is that ROS nodes can find their Pico's and talk to them.
...and why is this not micro-ROS? As soon as you say the words 'discovery service', 'discovery protocol', and 'dictionary' it starts to sound very complicated and ROS-like. I'll have to spend my time learning this system when I could just use micro-ROS.
But...it might be worth it. Is it that micro-ROS adds many more layers than what is needed to provide publish/subscribe and procedure calls?
Chris Albertson, maybe you have done some performance tests with micro-ROS on Pico? What has been the hz rate when publishing a simple message from the Pico to ROS in a Pi?
Michael Wimble, do you have similar performance data for your custom JSON pushed from the Teensy 4.1 to ROS? I know you use the ethernet connection, but we could rig something for USB.
I can't say that my limited investigation in this area showed any great micro-ROS performance. I loaded a Teensy 3.5 with the micro-ROS publisher example that had been stripped down to remove the delays they had inserted. Then I ran rostopic hz on my Pi 3 to see how fast ROS was receiving the messages. It would start around 90 but usually settled down to less than 80. I need to get back to it and make sure everything was working as expected, but I was not very impressed. But to me, something to replace micro-ROS would need to do better than that at least.
-Mark
Mark Womack
Jan 21, 2022, 9:16:32 PM1/21/22
to hbrob...@googlegroups.com
And oh yeah, I forgot, my test wasn't even using a Pi3, it was using an UP Board which has better performance than a Pi3. Though to be fair, it is running a Desktop Ubuntu. But still.
Duh, I should have also asked you, Wayne, if you have performance to pushing data via JSON through USB.
-Mark
Chris Albertson
Jan 21, 2022, 10:40:04 PM1/21/22
to hbrob...@googlegroups.com
On Fri, Jan 21, 2022 at 5:16 PM Mark Womack <mwo...@gmail.com> wrote:
On Fri, Jan 21, 2022 at 3:54 PM Chris Albertson <alberts...@gmail.com> wrote:Ho, you are proposing to place USB on each sensor and motor. I'm not sure I want a USB interface in the micro switch inside my crash bummer or one a single LED or even on an ultrasonic sensor.The crash-bumper is a good example. A USB interface would be good if it worked at a high level. I have left and right switches on a front and rear bumper. A hard impact dead-on to a wall triggers both switches but if one one end of the bumper hits it triggers only one switchA USB bumper that analysed where on the robot the impact occurred and send a message would be good. But I don't want one USB cable from each switch. The trouble is the analysis of where the impact happen is different for every robot. They all have different switches in different locations. So the solution is to wires all the switches to a Pico and then go USB from the Pico to the Pi4.This is true with ultrasonics too. I don't want one USB cable per sensor and I want the micro to "know" where the sensor is pointed so it can add send the right mesageI didn't interpret that as what Wayne was saying, but I guess he can speak up. I was thinking that all related sensors would be connected to a single Pico (or other type of microcontroller), not a Pico per sensor.
Then I agree and I think this is what most peole do. It is kind of the "standard way" I think. One thing it allows is
to use a desktop PC for development. Funny I'm doing this now, testing robo-dog software on the mydesktop PC. I actualy forgot the code was physically runing on the workstation-class PC and was so impressed that a full 12 DOF inverse kinematic solution written 100% in Python would run at 4200 cycles per second. Then I remembered. I tried it on the Pi4. It's fast. I got about 2,000 per second.
I was talking more about Teensy, Wayne is talking more about Pico.
The real difference between Pico and Teensy is that the Teensy has floating point hardware. If you were going to do that
inverse kinimatics on the microcontroer, yo'd want the Teensy. But in all other cases the Pico wins on size and cost.
Look at the Pico's "PIO" They are like mico-micro-processors and there are 8 of them. You can do things like decode a set of
quadrature encoders with a PIO and not use any CPU time in interrupts. The other big win with Pico is the quality of the documentation. It is excellent and available for at different levels from beginner to profesional.
But you will need the Teensy if you need hardware floating point. But this is rare. I used the "blue Pill" STM103 board that has the same "M0" CPU core as the Pico but only one core and it has no problem at all running a PID loop to control a motor. All the floating point is in software but the loop only runs 20 times persecond. and there is only a handful of multiplies in the loop. Kinimatics is different, there are perhaps 100 trig functions inside the loop.
One other data point I got on Pico is from the SimpleFOC project. They have really good and easy to use BLDC motor controller software that runs on popular micros. The Pico is the low-end of what they support. The Pico has no problem running a normal stepper motor as a continuous motion (no steps) servo motor. It runs only about 3X slower than a Teensy
Finally one more god thing about USB is Adafruit's USB to anything cable. https://www.adafruit.com/product/2264
Then you can use a notebook PC or the like as the robot main controller or swap that out for a Jetson with just one cable. It is using USB-C.
--
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-TXgt1L4o4h5k%3DdKcQAYhtu5GAAkeXbyLiYEHhh4goAQxh8Q%40mail.gmail.com.
Michael Wimble
Jan 22, 2022, 2:30:55 AM1/22/22
to hbrob...@googlegroups.com
> On Jan 21, 2022, at 5:37 PM, Mark Womack <mwo...@gmail.com> wrote:
>
> Michael Wimble, do you have similar performance data for your custom JSON pushed from the Teensy 4.1 to ROS? I know you use the ethernet connection, but we could rig something for USB.
When I was running basic Ethernet communication tests, sending data from the Teensy 4.1 to a ROS Node on an AMD 3700X processor, I was able to get about a thousand frames a second, if I recall.
>
> Michael Wimble, do you have similar performance data for your custom JSON pushed from the Teensy 4.1 to ROS? I know you use the ethernet connection, but we could rig something for USB.
My Teensy is somewhat loaded in what it does on my Puck robot. It senses 4 SONAR sensor and 8 time of flight sensors, 2 motor current sensors, 2 motor temperature sensors, and a touch screen while also communicating with the RoboClaw motor controller over one of the UART channels, managing 8 power relays and runs an Ethernet server and an Ethernet client. The code uses edge triggered interrupts and timing to stagger the SONARs so they don’t interfere with each other and to stagger the time of flight sensors in order to achieve maximum throughput. Once all of that code is running in a loop, I think my master loop takes between 4 and 10ms to run, so even if the Ethernet communication is fast, the sensor data for all sensors is completely updated only a maximum of 100 to 250 times a second, which is sufficiently fast for my robot.
I use nearly every pin on the Teensy 4.1. There are level shifters on my board so the 3.3v Teensy can talk to the 5v relays and SONAR sensors. There in an I2C multiplexor to allow me to use one I2C channel on the Teensy to talk to the 8 time of flight sensors without having to deal with identical I2C device address limitations. The temperature sensors are analog devices going through a pair of analog to digital converters on the Teensy. The touch screen uses SPI communication. The RoboClaw uses high speed UART communication. The Ethernet dongle contains magnetics to interface between the onboard Ethernet chip and the external cable. The Ethernet chip provides an amazing number of built in services.
All in all, I’m extremely pleased with what my Teensy 4.1 brings to my robot with a small custom PC board.
Steve " 'dillo" Okay
Jan 22, 2022, 6:50:05 AM1/22/22
to HomeBrew Robotics Club
I've also started to move away from Arduinos on my rover and have been experimenting with Teensy 4.1 and Ethernet, esp. since the 4.1 has the onboard Ethernet controller. I've been thinking about hacking together a ROS1 pub/sub library for it because with the network interface it seems like a crime to just keep using serial/USB. It sounds like Michael or somebody else has already done this though. So I think my contrary opinion would be to get your nodes off Serial/USB and onto Ethernet :)
I spent a good bit of time last year getting a client's large pile of Realsense D435is to work with their picking/packing system and learned quite a bit about USB, device naming, udev rules, etc.
For one thing, it's important to realize that the most USB controllers have at most 4 ports on them. If there are more than 4 slots, that means there's another controller chip talking to the next group of 4 ports and so on.
This means you can't expect that the 5th device you plug in will show up as /dev/ttyACM4. It might, it might not. The Linux udev rules system will decide what it gets called and where it goes depending on which controller
its talking to. It will also (semi-) randomly assign you either your old port name or a new one, so it's important to create symlinks for your devices and use those in your launch files vs. hardcoding in /dev/ttyACM0 .
I did end up writing a complete naming system for those guys that would track USB devices across plug/unplug events and ensure that a given device would always wind up with the same name.
It was not so much clever as exhaustive and I ended up diving back into kernel space for the first time in about a decade and way more about USB and udev than I ever expected.
I should re-do it from scratch and release it, esp. since that's the non-proprietary part of that project.
I'd also love to know if somebody has ported/compiled the std. ROS1 messaging libs to the Teensy though(even though I knew we're all supposed to be moving over to ROS 2 and microROS)
It's hard to want to keep fiddling with USB when you could send the same data over a network.
'dillo
Pito Salas
Jan 22, 2022, 9:56:55 AM1/22/22
to hbrob...@googlegroups.com
Thanks Steve... A few questions:
> I'd also love to know if somebody has ported/compiled the std. ROS1 messaging libs to the Teensy though(even though I knew we're all supposed to be moving over to ROS 2 and microROS)
> It's hard to want to keep fiddling with USB when you could send the same data over a network.
>>>>>> I have. Take a look at linorobot.org. Their ROS1 is set up for teensy and it works fine.
Pito
p.s. I know this is a minority opinion but I am happily staying with ROS1 until it reaches end of life because anecdotally there are still lots of problems with it. And really the advantages of ROS2 vs. ROS1 as far as I can tell don't apply to me. They seem to have to do with security and scale. Of course I am one of the guys who stayed with Melodic a little longer before going to Noetic.
>
> I've also started to move away from Arduinos on my rover and have been experimenting with Teensy 4.1 and Ethernet, esp. since the 4.1 has the onboard Ethernet controller. I've been thinking about hacking together a ROS1 pub/sub library for it because with the network interface it seems like a crime to just keep using serial/USB. It sounds like Michael or somebody else has already done this though. So I think my contrary opinion would be to get your nodes off Serial/USB and onto Ethernet :)
Other than it being a crime, what are the advantages of ethernet for you?
> I've also started to move away from Arduinos on my rover and have been experimenting with Teensy 4.1 and Ethernet, esp. since the 4.1 has the onboard Ethernet controller. I've been thinking about hacking together a ROS1 pub/sub library for it because with the network interface it seems like a crime to just keep using serial/USB. It sounds like Michael or somebody else has already done this though. So I think my contrary opinion would be to get your nodes off Serial/USB and onto Ethernet :)
> I'd also love to know if somebody has ported/compiled the std. ROS1 messaging libs to the Teensy though(even though I knew we're all supposed to be moving over to ROS 2 and microROS)
> It's hard to want to keep fiddling with USB when you could send the same data over a network.
Pito
p.s. I know this is a minority opinion but I am happily staying with ROS1 until it reaches end of life because anecdotally there are still lots of problems with it. And really the advantages of ROS2 vs. ROS1 as far as I can tell don't apply to me. They seem to have to do with security and scale. Of course I am one of the guys who stayed with Melodic a little longer before going to Noetic.
Mark Womack
Jan 22, 2022, 12:04:16 PM1/22/22
to hbrob...@googlegroups.com
On Fri, Jan 21, 2022 at 10:40 PM Chris Albertson <alberts...@gmail.com> wrote:
The real difference between Pico and Teensy is that the Teensy has floating point hardware. If you were going to do thatinverse kinimatics on the microcontroer, yo'd want the Teensy. But in all other cases the Pico wins on size and cost.
Well, I don't think it is quite that cut and dry. Teensy 4.0 is about the same size, though it costs more. And the Teensys have a lot more options on the pins. They even have underside pads to provide all the options. But I can't argue against cost. And especially in this design we are talking about (ie subsystem/peripheral that is dedicated to a given group of sensors/controls), then the number of options provided by the Pico is sufficient. It supports 2 I2C buses which is sufficient to be a slave on one bus and master on the other bus. 2 serial ports should be sufficient. Etc. The Teensys are always an option for when more options are needed. I'm sure that whatever library we come up with here will be usable across microcontrollers.
-Mark
Chris Albertson
Jan 22, 2022, 12:10:52 PM1/22/22
to hbrob...@googlegroups.com
On Sat, Jan 22, 2022 at 3:50 AM Steve " 'dillo" Okay <espre...@gmail.com> wrote:
I'd also love to know if somebody has ported/compiled the std. ROS1 messaging libs to the Teensy though(even though I knew we're all supposed to be moving over to ROS 2 and microROS)
Short answer: Yes it is ported to Teensy. Hack ROS Serial, ArduinoHardware.h to use whatever physical link you like.
ROS Serial is the ROS message sub/pub library for use on microcontrollers in ROS1. It has not been maintained on some platforms but is maintained on Aruino IDE. If you are using Arduino IDE on Teensy then ROS Serial work should on Teensy. In fact the Teensy is mentioned in ROS Serial tororials. It runs for me on several different STM32 Cortex M0 and M4 boards under Arduino IDE.
If you want to use ROS Serial over some other physical link (like UDP over Ethernet or SPI or I2C) then there is a tutorial with a walkthrough here http://wiki.ros.org/rosserial_arduino/Tutorials/NodeHandle%20and%20ArduinoHardware
The standard ROS Serial has just one line of code in the read() function that needs to be replaced
return iostream->read();
Replace it with whatever you like then click "build".
My experience with editing ArduinoHardware.h is only use use other serial devices, not a network-like device. You might try programming it at the socket layer. Sockets are very serial-port-like. So you might end up only writing a half dozen lines of code. Open socket in init() and modify read() and write() to use the socket.
I think this would be very interesting in ESP32. ROS Serial over WiFi to BlueTooth.
What MicroROS does is make the Microcontroller a "first class" ROS node.
THe tu
It's hard to want to keep fiddling with USB when you could send the same data over a network.'dilloOn Friday, January 21, 2022 at 11:30:55 PM UTC-8 Michael Wimble wrote:> On Jan 21, 2022, at 5:37 PM, Mark Womack <mwo...@gmail.com> wrote:
>
> Michael Wimble, do you have similar performance data for your custom JSON pushed from the Teensy 4.1 to ROS? I know you use the ethernet connection, but we could rig something for USB.
When I was running basic Ethernet communication tests, sending data from the Teensy 4.1 to a ROS Node on an AMD 3700X processor, I was able to get about a thousand frames a second, if I recall.
My Teensy is somewhat loaded in what it does on my Puck robot. It senses 4 SONAR sensor and 8 time of flight sensors, 2 motor current sensors, 2 motor temperature sensors, and a touch screen while also communicating with the RoboClaw motor controller over one of the UART channels, managing 8 power relays and runs an Ethernet server and an Ethernet client. The code uses edge triggered interrupts and timing to stagger the SONARs so they don’t interfere with each other and to stagger the time of flight sensors in order to achieve maximum throughput. Once all of that code is running in a loop, I think my master loop takes between 4 and 10ms to run, so even if the Ethernet communication is fast, the sensor data for all sensors is completely updated only a maximum of 100 to 250 times a second, which is sufficiently fast for my robot.
I use nearly every pin on the Teensy 4.1. There are level shifters on my board so the 3.3v Teensy can talk to the 5v relays and SONAR sensors. There in an I2C multiplexor to allow me to use one I2C channel on the Teensy to talk to the 8 time of flight sensors without having to deal with identical I2C device address limitations. The temperature sensors are analog devices going through a pair of analog to digital converters on the Teensy. The touch screen uses SPI communication. The RoboClaw uses high speed UART communication. The Ethernet dongle contains magnetics to interface between the onboard Ethernet chip and the external cable. The Ethernet chip provides an amazing number of built in services.
All in all, I’m extremely pleased with what my Teensy 4.1 brings to my robot with a small custom PC board.
--
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/42615686-b451-4a52-9339-2f9a21b9de66n%40googlegroups.com.
Mark Womack
Jan 22, 2022, 12:11:38 PM1/22/22
to hbrob...@googlegroups.com
Your Teensy is starting to sound like a small microcomputer with all of this going on!
I think that whatever protocol/library we create out of this discussion, it would be great if it would work across USB/Ethernet/I2C. Which I think is the direction we are heading. It would require different ROS nodes obviously. Maybe other stuff.
-Mark
Chris Albertson
Jan 22, 2022, 12:27:08 PM1/22/22
to hbrob...@googlegroups.com
I agree about Teensy. It is on my short list of favorite boards. I was using STM's Nucleo boards but Teensy 4 can replace those.
I also used a few of the "Blue Pill" boards that sell for $3 on eBay. These have STM32 Cortex M0 chips and can be programmed on
the same Arduino IDE. But now Pico has replaced those.
For beginners or those who want to get stuff done quickly Micro Python is absolutely amazing and removes the need to write in C. There is a beginner level book that the Raspberry Pi foundation publishes that walks a beginner through using micro Python. People associate Python with the Pico because Pico is used in the books but I'd bet Micro Python works on Teensy.
I was actually going to use Teensy on the current robot but I found I don't need a microcontroller, at least not yet. I'm using all I2C interfaced devices to the P4.
--
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-TXgscEkYZUgZ8hT6Y76kwS3Tx0EktxNhBHCuXoLv%3DCvan8Q%40mail.gmail.com.
Chris Albertson
Jan 22, 2022, 12:35:19 PM1/22/22
to hbrob...@googlegroups.com
On Sat, Jan 22, 2022 at 9:11 AM Mark Womack <mwo...@gmail.com> wrote:
I think that whatever protocol/library we create out of this discussion, it would be great if it would work across USB/Ethernet/I2C. Which I think is the direction we are heading. It would require different ROS nodes obviously. Maybe other stuff.
As I just wrote. They made it easy. ROS Serial only touches the hardware in one class called "ArduinoHardware.h" All the I2C, or UDP socket related stuff goes there. So it is not a big ugly job where you have to modify the code in 100 places. My gues is all that is needed is a #include for the Ethernet stuff then a few function calls.
Then of course the ROS bridge node on the Pi/Jetson/PC has to be changed to match.
Mark Womack
Jan 22, 2022, 8:53:03 PM1/22/22
to hbrob...@googlegroups.com
I would like to reset this discussion somewhat.
I would like to suggest that we focus the goals of the Homer ExampleBot to be around home usage, primarily as some kind of assistant to those that need it. I think the first three phases of Homer stay the same, but with the end goal in mind the base is more built out than has been previously envisioned. This is to better support the future, yet to be determined phases. As has been suggested, I think a goal like this makes Homer more interesting and opens up more opportunities for useful extension beyond just a simple floorbot. I think we should discuss use cases that will inform phases beyond phase 3.
I have some ideas on the base that I would like to share, but I am going to stop there so we can discuss use cases first and see where it leads. No putting the cart before the robot, so to speak.
Here are a few use cases I have been pondering. I doubt they are anything earth shattering or surprising.
1) Carry items from point A to point B. In this scenario Homer acts as a personal butler, schlepping items the user wants to be transported. Homer doesn't collect the items, just navigates with the items in its possession. This is essentially Camp's drink cart. :-) The items should be accessible at a comfortable height.
2) Retrieve household item(s) from a described location and bring them to the user. In this scenario Homer is instructed to retrieve an object from a room and to bring it back to the user. There would need to be some kind of object recognition and maybe some kind of height adjustable arm/gripper to pick something up and place it on Homer. A simplified version of this scenario would be to get a can of Coke from the fridge.
3) Provide support to a user as they get up from a chair, walk to a different location, and sit back down. Homer should provide a stable base for a user to get up from a chair, and then act like a stable walker as the user walks to a different room. Then provide stable support as they sit back down once again.
4) Come to where the user is located when called. Homer could be in a different room charging or could be across the room inactive, but when the user calls them they go to the user.
5) Detect that the user is in distress and contact emergency services if instructed or after determining the user cannot, does not answer.
I would say another use case is to pick the user up without crushing any sensitive bits, but I think that is a bit aspirational right now. :-)
Please feel free to jump in here with other use cases or thoughts about these cases. But try to not solve them yet, except in very general swaths (ie that would probably require an arm with a gripper). Thoughts on how phases could be organized to achieve the use cases will be useful.
-Mark
Chris Albertson
Jan 22, 2022, 10:44:40 PM1/22/22
to hbrob...@googlegroups.com
A reasonable answer is "all of the above, except #3" They need not be all implemented on the same robot and they could be done one after the other.
First off #3, the walker seems like a lawsuit magnet. Also the payload is more then you might think and you need some big heavy parts and if you skimp on the engineering, don't implement quality control and testing you can get in trouble.
You can start with a motorized tea cart and make it do something simple like follow you, or a follow a QR code you pin to you backside. Later make it come when summoned with a cell phone app.
Some day later you add and arm to the cart and it can self load and self offload.
You can dismantle the project. You don't need a mobile base to demo self loading and you don't need something as big as a tea cart to come to you, see that you are one the floor not moving and call 911. A 250mm tall "robo-dog" could do that.
I think you have a good set of goals that start low and move up.
The tea cart size is larger then many floorbots but if the eventual goal is self-loading it needs to be be big to be stable at the tall height and likely needs a big computer and battery. I've never heard of this level of AI being done with a Raspberry Pi.
But "maybe" I just benchmarked my Pi4 last night. It can do a full 12 DOF inverse kinematic solution for a quadruped with 6 DOF body movment 2100 times per second. This is in 100% Python. I was shocked. I was crossing my fingers and hoping for at least 100 per second. No optimization at all. Just using Numpy. A Pi4 could drive the cart and runs and arm but lileky not the advanced AI at the same time. But a cart is big enough to haul a notebook PC.
One more question: Steering. 4-wheel steering is ideal for a self-loading arm as it is holonomic. But it is overkill for a tea cart robot. Carts typically have two rear casters. It would be good to have a design that can be upgraded in stages from two front powered wheels, to four wheel drive to full 4-wheel steering all with no need to throw away parts or even drill new holes
I think the two-wheel drive unit might have plastic spacer cubes under the casters. later versions replace the plastic blocks with ball bearing blocks. Just have to plan ahead so the screw holes line up and you can do a screwdriver-only upgrade.
The other question is what kind of construction technology are you going to allow. If you allow CNC metal you can build a very high performance machine but you exclude 99% of all builders. You can not build a full size cart with a 3D printer. Maybe add carbon fiber tunes of 2020 aluminum or somthing.
I think I might cross this line with my Robot Dog. I really with high precsion plastic and oversized bearings. Here is n experiment done a few days ago to see if I can make 3Dprints come out with 0.01mm tolerence.
Does one loose 99% of builders if this is required or do you have to make the part for others? Or do you just put up with parts that wabble. I will not know if the effort is worth it until a couple months
--
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-TXgsG1uxDK2BOr1R7m%2BCh75TpR5FLRahDeiD_E6VqjZ9YqA%40mail.gmail.com.
Richard Chycoski
Jan 23, 2022, 12:34:25 AM1/23/22
to hbrob...@googlegroups.com
I was going to say about the same about #3 - the load presented by
helping someone get out of and into a chair is an order (or two) of
magnitude higher - and more difficult - than the other.
As someone who is developing mobilty issues - and has had family and friends with serious mobility issues - I agree that this is an aspirational goal - for a future mobility-assisting robot - or two? ;-)
To have the robot fetch a cane or other mobilty-enabling device would likely be appropriate and attainable at this stage, though!
- Richard, VE7CVS
As someone who is developing mobilty issues - and has had family and friends with serious mobility issues - I agree that this is an aspirational goal - for a future mobility-assisting robot - or two? ;-)
To have the robot fetch a cane or other mobilty-enabling device would likely be appropriate and attainable at this stage, though!
- Richard, VE7CVS
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHt13AojD%3DCS9-46TbSB6idzX8td8ukLEd%3DaGxE3rjtrcg%40mail.gmail.com.
Dave Everett
Jan 23, 2022, 5:53:16 AM1/23/22
to hbrob...@googlegroups.com
On Thu, 20 Jan 2022 at 05:35, Chris Albertson <alberts...@gmail.com> wrote:
The advice to keep the weight low is good but impossible to follow if the robot's use-case is working with objects at table or countertop height. As soon as the robot lifts the beer from the fridge self it now has 12 oz of weight several feet off the ground. It was worse while it was moving the 2-liter soda bottle out of the way to reach the beer.Yes the four legged stool rocks, that this why sysension is needed on four-wheel robots. The goal is to keep equal amount of weight on each wheel. It is probably best to copy the design used in forklifts.
Suspension is a good idea. It adds complexity, but we can all imagine the experience of having a robot bring us a drink, and the glass is empty from spillage due to the robot bouncing around on small floor obstacles.
Either way, accel/decel is essential when moving anything. I would imagine any bench top activity would occur around the 1 metre height. On my robot I've tried to arrange things so the arm can pull items in over the wheels centre to help with balance. For transport it can be lowered down to about 40cm (about 16 inches) off the ground when moving the robot. I had an earlier design and the arm(s) when folded could be driven as low as 4 inches off the ground. I'd also looked at having a deep tray that items got stored in during travel, but this became an issue for other sensors and the arm lift as it currently stands. When the development goes to 2 arms that space will become available again.
Dave
Dave Everett
Jan 23, 2022, 6:06:50 AM1/23/22
to hbrob...@googlegroups.com
On Sun, 23 Jan 2022 at 12:53, Mark Womack <mwo...@gmail.com> wrote:
I would like to reset this discussion somewhat.
A good set of uses there. As others have said, the assistance mode sounds like the most difficult thing a robot could do. You need great power, but subtle movement of that power and incredible sensing to pull that off. I may be mistaken, but I assume you wanted the person to be alive at the other end, if not then it should be doable right now.
I looked up images of tea carts and this is a great size.
Chris, you are very keen on 4 wheel drive, I just don't know if you've considered the side torques on the wheels, motors and bearings during turning of a robot with decent weight. I'm thinking around 40-50kg here (88 - 110lbs). Do you recall the Artcec Gemini robot? Not very well known I guess and probably sold less than 10 units. It had 4 wheel drive and tended to suffer from slight jumping when turning on hard surfaces. On carpet it jumped less, but did wear the carpet where it turned.
Maybe setting a weight goal would be useful in this design too. Someone is going to have to lift and move it at some time.
A large battery is a must anyway I think. Not just for operational time, but for development time. It's very hard to develop a robot when it runs for 2hrs and needs 6hrs to recharge.
Dave
Steve " 'dillo" Okay
Jan 23, 2022, 1:58:16 PM1/23/22
to HomeBrew Robotics Club
"It just works" seems a bit of a cop-out answer, but it's the main one.
USB inevitably means rosserial and vice-versa, so if you're going to have a bunch of serial devices plugged into USB you need to deal with the port-assignment mess I talked about in a previous posting.
When Ethernet is available, that can all be thrown out the window.
Yes, it means you need to have a small switch on your robot and deal with network cables now, but if you have power for your robot and you have DHCP set up(or even static IPs assigned via your main board), it all comes up at power-on.
You never have to worry about your IMU showing up on /dev/ttyACM0 or /dev/ttyUSB0 the next, because your camera or LIDAR got assigned to /dev/ttyACM0 this time because (*handwaves at the Linux kernel and udev*)
You don't need to worry about writing udev rules or baud rates or how to handle multiple USB devices from the same vendor that may or may not have serial numbers encoded on them because the vendor cheaped out on the USB client chip on the board. I could do an entire HBRC talk on the joys and sorrows of getting a large # of USB devices to cooperate on a robot.
So if the choice is to get yet-another-microcontroller to reliably slot into the existing stable of rosserial devices on my robot or just plug in an ethernet cable, I will totally do the latter, even if it means I have to figure out how to re-implement the basic ROS messaging lib on said microcontroller.
I wish the network switches from botblox.io weren't so darn expensive because I think that's really the way forward.
'dillo
camp .
Jan 23, 2022, 2:25:49 PM1/23/22
to hbrob...@googlegroups.com
For me, the goal is what I call the "Smart Table." That is a tray table that can reliably get from one place to another in an unstructured environment. When we talk about robotics in the 21st century, for the most part, we're talking about mobile robots. A mobile robot is all about delivery. Even a vacuum cleaning robot basically delivers a brush and negative pressure to every inch of the house. I think the low-hanging fruit is telepresence, where you basically deliver a camera for communications, entertainment, and security. Beyond that, the Smart Table would be a generic human-assisted delivery system where you can put food, drinks, computer, whatever and send it from one place to another and with a high degree of confidence expect it to arrive there. I think this would be useful in the home or business. In other words, I'm all about that base. : ]
Thanks,
Camp
--
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
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
Steve " 'dillo" Okay
Jan 23, 2022, 2:33:43 PM1/23/22
to HomeBrew Robotics Club
On Saturday, January 22, 2022 at 6:56:55 AM UTC-8 pito...@gmail.com wrote:
[...]
p.s. I know this is a minority opinion but I am happily staying with ROS1 until it reaches end of life because anecdotally there are still lots of problems with it. And really the advantages of ROS2 vs. ROS1 as far as I can tell don't apply to me. They seem to have to do with security and scale. Of course I am one of the guys who stayed with Melodic a little longer before going to Noetic.
Hey, if it's not broke, don't fix it.
My background as a sysadmin places a fairly high value on stable, reliable systems that are doing useful things, for whatever value of "useful" matters to you.
Tenacity will unlikely leave ROS1 before EOL. There's too much that works well and fiddling with the infrastructure guts constantly is keeping me from working on more interesting stuff.
"The Next Robot" will, however, be ROS2. From scratch, it just makes sense to get onboard with the direction the platform is going in.
'dillo
Chris Albertson
Jan 23, 2022, 6:51:54 PM1/23/22
to hbrob...@googlegroups.com
Yes Ethernet works well on larger systems.
If you look in the universe of industrial robots and machine controls you see more use of Ehternet.
I have one of these cards on my short list of things to buy
The cost has come way down to under $100.
The way this works is they have software that asks you want is connected to each pin. It could be a micro-switch or a quadrature shaft encoder or an analog industrial seral or a stepper motor Or something connected with I2C or SPI.
Then you click "go" and get a bit-file that programs the FPGA and loads the bits into the chip.
Needless to say the FPGA solution is much more performant then any microcontroller as it is all done with logic gates
In the PC side you see software pins and functions that are connected in a kind of configuration file and this typically runs under a real-time version of Linux. These is a ROS1/2 interface to this. This is what you might find in a machine center where robots run a CNC mill and load and unload parts. It has been out of reach for hoby-budgets but now this stuff runs on Raspberry Pi and is affordable priced.
It is not sized for a toble top robot but if you have a human scale 'bot like a service robot that is big enough to see the top of a table then this stuff fits. (such a robot might have a dozen+ motors and as even more sensors.)
The above is just an example I used because I want to use one myself on a 4-axis mill. but you can find tons of this stuff
Once you have the data on an IP network, routing it around is easy. IP can go over any of several different physical media. Ethernet is just one of them. WiFi is logically the same thing. But Linx has "IP over USB". You can create an network with point to point USB cables. remeber that USB 3.1 can do 10 gigabits per second.
--
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/03c76e51-39ba-4319-b78f-5dbff3035f4an%40googlegroups.com.
Michael Wimble
Jan 23, 2022, 10:02:13 PM1/23/22
to hbrob...@googlegroups.com
No treble ?
Sergei Grichine
Jan 23, 2022, 11:22:53 PM1/23/22
to hbrob...@googlegroups.com
I am a little suprised that in 20 messages nobody has mentioned CAN bus.
Automotive industry long ago made the decision for us - how to query sensors and control actuators in large robots that we traditionally keep calling "cars".
While I personally haven't dealt with it yet, I definitely have CAN bus as a possibility for my next contraption. Does anybody have hands-on experience with it? Any thoughts?
Best Regards,
-- Sergei Grichine
-- Sergei Grichine
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHs3G6bieB_WgxOXyjJRTh0E1HyjcCstBLVR3uFssQ%3DCAA%40mail.gmail.com.
Wayne Gramlich
Jan 23, 2022, 11:38:37 PM1/23/22
to hbrob...@googlegroups.com, Sergei Grichine
Sergei:
It was mentioned in my earlier post "Probot Peripherals: Topic Topology".
I've used ISO-11898 (which is the CANBus physical layer.) I've never actually used
CANBus protocol running on top of ISO-11898. While most microcontroller families
have a CANBus interface, it tends to be the exception more than the rule. I'm
pretty sure that the Pico, Etsy, Teensy, etc. do not have CANBus interfaces.
Regards,
-Wayne
It was mentioned in my earlier post "Probot Peripherals: Topic Topology".
I've used ISO-11898 (which is the CANBus physical layer.) I've never actually used
CANBus protocol running on top of ISO-11898. While most microcontroller families
have a CANBus interface, it tends to be the exception more than the rule. I'm
pretty sure that the Pico, Etsy, Teensy, etc. do not have CANBus interfaces.
Regards,
-Wayne
> I am a little suprised that in 20 messages nobody has mentioned CAN bus.
>
> Automotive industry long ago made the decision for us - how to query
> sensors and control actuators in large robots that we traditionally keep
> calling "cars".
>
> While I personally haven't dealt with it yet, I definitely have CAN bus as
> a possibility for my next contraption. Does anybody have hands-on
> experience with it? Any thoughts?
>
> Best Regards,
> -- Sergei Grichine
> [snippage]
>
> Automotive industry long ago made the decision for us - how to query
> sensors and control actuators in large robots that we traditionally keep
> calling "cars".
>
> While I personally haven't dealt with it yet, I definitely have CAN bus as
> a possibility for my next contraption. Does anybody have hands-on
> experience with it? Any thoughts?
>
> Best Regards,
> -- Sergei Grichine
Chris Albertson
Jan 24, 2022, 12:02:59 AM1/24/22
to hbrob...@googlegroups.com
This entire discussion is theoretical. In real life you find a gadget you need to use then you see that is uses SPI or I2C or whatever then you use SPI. I2C or whatever to connect it. In a complex system you have "all of the above" some place.
Very few of use get to design PCB board from the basic chips. But even if we did what I aid applies. Let's say you really like CAN bus and are an expert at it. Then you find an IMU chip you like and these are almost exclusively I2C. So you now have a choice, either rin I2C to the controller or build a I2C to CAN translator. The translate seems a waste of space as it adds latency. Many of the parts are like this too. They all some with some kind of built in interface and you have to use what they got.
If you select serial bus servos for you robot then you are using serial bus protocol not CAN as it would be silly to build a translator for each servo.
Ethernet and USB work very well for connecting few microcontrollers to a main computer because buth can handle mixed packetized traffic and are very fast and every main computer support USB and Ethernet. But would you imagine a 28 DOF full size humanoid robot with 28 Ethernet interfaced servo controllers. Where would you place the 28+ port hub andhow to rout all those cat6 cable that each need a home run to the hub. CAN is perfect for this robot because you can daisy chain the cables. But this only works if you are building the motor controllers and can put on the CAN interface chips otherwise you have to use whatever is on the controller.
I've played with CAN. It is not hard. But you always need to buy the interface chips and use them on every device. Even when a microcontroller has pins labeled "CAN bus" and many STM32 chips have these pins you absolutely till need the driver chips. For mot people this means a little breakot board and jumpers on every place the CAN bus touches. The chips are not expensive an JLCPCB stocks then and will solder them to board you have them make. But microcontroller pins can never be physically connected. So SPI, I2C, USB and so on are nice in the the uP pin can be used directly
But CAN bus is very robust and imune to noise and you can route a CAN cable right near a BLDC motor that is running 100 amps
But like I said, you ue what you have. If a Teensy has Ethernet, use that otherwise it i USB. CAN i good if you are the ne designing the PCBs and you have a few dozen motors and sensors to hook up
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVPaJnOfD8ESk_aNTUbRayhK%2BuEuZv9d%3DRCFUYfAJwfoMw%40mail.gmail.com.
Michael Wimble
Jan 24, 2022, 12:25:46 AM1/24/22
to hbrob...@googlegroups.com
While most microcontroller families
have a CANBus interface, it tends to be the exception more than the rule. I'm
pretty sure that the Pico, Etsy, Teensy, etc. do not have CANBus interfaces.
The Teensy 4.1 has up to 3 CAN Bus interfaces. Ive never looked into them so I have no idea why they are interesting, so maybe someone can save me a lot of research and summarize the interface.
I have to say that the Teensy 4.1 is my go to microcontroller. Mine has 16MB of RAM, runs at 600 MHz, has floating point, tons of flash, a MB of high speed RAM, both USB client and host, supports ethernet, supports a touchscreen, etc., etc. It’s relatively small and relatively cheap. Add a few MOSFET level translators and it can pretty much talk to any current or voltage you want.
It didn’t take me long, from scratch, to learn how to use KiCAD to design a custom board to support locking connectors, I2C fanout, level translators and more, and then I fabbed up a few in about a week via China for just a handful of dollars. But, if you can just need the basics, just plug it into a breadboard and give it a USB cable.
And it’s hard not to evangelize avoiding the work of trying to support ROS (especially ROS2) packet protocol on a microcontroller. It hardly seems worth the effort to me. Just talk serial or Ethernet directly to the processor that is running ROS and let that big, bad boy convert the traffic to ROS. It’s pretty easy to do.
Teensy 4.1 highlights, for $27, from: https://www.pjrc.com/store/teensy41.html
- ARM Cortex-M7 at 600 MHz
- Float point math unit, 64 & 32 bits
- 7936K Flash, 1024K RAM (512K tightly coupled), 4K EEPROM (emulated)
- QSPI memory expansion, locations for 2 extra RAM or Flash chips
- USB device 480 Mbit/sec & USB host 480 Mbit/sec
- 55 digital input/output pins, 35 PWM output pins
- 18 analog input pins
- 8 serial, 3 SPI, 3 I2C ports
- 2 I2S/TDM and 1 S/PDIF digital audio port
- 3 CAN Bus (1 with CAN FD)
- 1 SDIO (4 bit) native SD Card port
- Ethernet 10/100 Mbit with DP83825 PHY
- 32 general purpose DMA channels
- Cryptographic Acceleration & Random Number Generator
- RTC for date/time
- Programmable FlexIO
- Pixel Processing Pipeline
- Peripheral cross triggering
- Power On/Off management
Chris Albertson
Jan 24, 2022, 1:58:54 AM1/24/22
to hbrob...@googlegroups.com
On Sun, Jan 23, 2022 at 9:25 PM Michael Wimble <mwi...@gmail.com> wrote:
While most microcontroller families
have a CANBus interface, it tends to be the exception more than the rule. I'm
pretty sure that the Pico, Etsy, Teensy, etc. do not have CANBus interfaces.The Teensy 4.1 has up to 3 CAN Bus interfaces. Ive never looked into them so I have no idea why they are interesting, so maybe someone can save me a lot of research and summarize the interface.
CAN is very much like ROS. Each node publishes some data and does not know who if anyone is reading it and any node can subscribe to the data values it needs. The bus give priority to the most important messages. Priority is data based, not node based. The clever thing is this is all enforced by hardware. The priority and filtering is all done by magic involving ANDing and tri-states and at the electrical level. The bus logic is in the chips, not your software. If two nodes try to send, the highest priority data wins and the other has to resend. So a smart car designer makes the brakes a high priority ID number and the gas tank level sensor a low number. So the brake dat cuts through and gets the bas also the gase gause display never sees anything but the tan level whenever it gets through
Like ROS the data is a continuous steam. If you want the motor to run at .5 RPM you have to keep sendnig ".5" on the correct channel the motor is listening to.
The Bus use a differential pair twisted wire and all nodes are wired in parallel. but typically four wires are run, Positive power, ground and data high and data low. Each node has two connectors wired in parallel so you daisy chain them. There is no "standard" connector, DB9 and JST and even screw terminals are all used.
There is a high speed version of CAN and a low speed version for when "bet your life" reliebilty is needed. for connecting say the brake pedal. Is is very reliable. If you press the brake it will start transmitting brake staus values over and over at some high rate with CRC and with priority and routing at the electrical level it is going to work (although all cars would have some kind of hydraulic backup)
As a bus it really is different because the ID you send to is not a node but to a data type. So it reminds my of publish/subscribe as in ROS.
all from memory. Some time ago I bought some breakout boards on eBay.
I have to say that the Teensy 4.1 is my go to microcontroller. Mine has 16MB of RAM, runs at 600 MHz, has floating point, tons of flash, a MB of high speed RAM, both USB client and host, supports ethernet, supports a touchscreen, etc., etc. It’s relatively small and relatively cheap. Add a few MOSFET level translators and it can pretty much talk to any current or voltage you want.It didn’t take me long, from scratch, to learn how to use KiCAD to design a custom board to support locking connectors, I2C fanout, level translators and more, and then I fabbed up a few in about a week via China for just a handful of dollars. But, if you can just need the basics, just plug it into a breadboard and give it a USB cable.And it’s hard not to evangelize avoiding the work of trying to support ROS (especially ROS2) packet protocol on a microcontroller. It hardly seems worth the effort to me. Just talk serial or Ethernet directly to the processor that is running ROS and let that big, bad boy convert the traffic to ROS. It’s pretty easy to do.Teensy 4.1 highlights, for $27, from: https://www.pjrc.com/store/teensy41.html
- ARM Cortex-M7 at 600 MHz
- Float point math unit, 64 & 32 bits
- 7936K Flash, 1024K RAM (512K tightly coupled), 4K EEPROM (emulated)
- QSPI memory expansion, locations for 2 extra RAM or Flash chips
- USB device 480 Mbit/sec & USB host 480 Mbit/sec
- 55 digital input/output pins, 35 PWM output pins
- 18 analog input pins
- 8 serial, 3 SPI, 3 I2C ports
- 2 I2S/TDM and 1 S/PDIF digital audio port
- 3 CAN Bus (1 with CAN FD)
- 1 SDIO (4 bit) native SD Card port
- Ethernet 10/100 Mbit with DP83825 PHY
- 32 general purpose DMA channels
- Cryptographic Acceleration & Random Number Generator
- RTC for date/time
- Programmable FlexIO
- Pixel Processing Pipeline
- Peripheral cross triggering
- Power On/Off management
--
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/850B0F9D-323D-4DB8-9252-E1306369A0AC%40gmail.com.
Sergei Grichine
Jan 24, 2022, 9:19:56 AM1/24/22
to hbrob...@googlegroups.com
Just wanted to mention "I2C Extender" technology in this thread, in case anybody needs to connect I2C devices over 30 cm distance:
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHvcQ%2BoZMoV5_u%3DQQVn-DRRtGRMokm2MVgP2egqkjajoCw%40mail.gmail.com.
Best Regards,
-- Sergei
Jim Phelan
Jan 24, 2022, 11:25:10 PM1/24/22
to hbrob...@googlegroups.com
Hi guys, new guy here.
Two options not mentioned are
mecanum https://en.wikipedia.org/wiki/Mecanum_wheel
or
omni https://en.wikipedia.org/wiki/Omni_wheel
wheels.
They're reputedly less energy efficient than other systems, but it may be worth it for the added maneuverability.
You can use 3 or 4 wheels.
A SIDE NOTE: Geometry of robotic scaling: as the linear dimension doubles x2, the area squares x4 and the volume cubes x8.
Strength is proportional to the cross sectional area. Mass is proportional to volume. Cost is proportional to volume.
That is why you can't scale a spider to elephant size without giving it elephant legs.
Larger size >> more weight, stronger frame, bigger wheels >> stronger motors >> bigger batteries >> more weight >>> repeat.
Jim Phelan
USAi Labs, Houston
Two options not mentioned are
mecanum https://en.wikipedia.org/wiki/Mecanum_wheel
or
omni https://en.wikipedia.org/wiki/Omni_wheel
wheels.
They're reputedly less energy efficient than other systems, but it may be worth it for the added maneuverability.
You can use 3 or 4 wheels.
A SIDE NOTE: Geometry of robotic scaling: as the linear dimension doubles x2, the area squares x4 and the volume cubes x8.
Strength is proportional to the cross sectional area. Mass is proportional to volume. Cost is proportional to volume.
That is why you can't scale a spider to elephant size without giving it elephant legs.
Larger size >> more weight, stronger frame, bigger wheels >> stronger motors >> bigger batteries >> more weight >>> repeat.
Jim Phelan
USAi Labs, Houston
--
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/6CF6F78E-4E0C-4515-A019-D99B7C6CE0F2%40gmail.com.
Carl Sutter
Jan 27, 2022, 7:44:29 PM1/27/22
to HomeBrew Robotics Club
FWIW, the First FRC devices and controllers often have CAN and they use it a lot for control.
I have used Roboteq controllers with CAN also. They support a couple standard protocols and have their own easy to use RoboCAN protocol - docs are all online.
As mentioned, for microprocessors like an Arduino without CAN built in, you would need a CAN to SPI (or some other) interface like this one: https://amzn.to/3u7yNkO. For a microprocessor with CAN support, like an ESP32, you still need a transceiver for the connection like this: https://amzn.to/3uaWcld
Chris Albertson
Jan 28, 2022, 1:48:49 AM1/28/22
to hbrob...@googlegroups.com, Wayne Gramlich
On Fri, Jan 21, 2022 at 8:36 AM Wayne C. Gramlich <wayne.gra...@gmail.com> wrote:
On 1/20/22 10:48 PM, Wayne C. Gramlich wrote:
> Chris:
[snippage]
>> The other thing that caught my eye was the suggestion of one ROS node per
>> Pico. That would be a huge waste of a Pico and cause data to be
>> ping-ponged through the cables and bridge nodes on the Pi4. For
>> example if I have a Pico that is running a set of two or thee ultra
>> sonic sensors. I need a node to run the sensors and broadcast the
>> messages. But I also might want a node to listen to those messages and
>> detects objects and figure out if the robot is getting closer or farther
>> from the object. You would want those on the same Pico.
>>
>> If nodes are on the same chip they now can use shared memory to communicate
>> messages, so no data moves, just pointers. it is very fast compared to a
>> round trip over USB. This is a good reason to place more nodes on the
>> same chip
>
> It's late an night. I've read the paragraphs above several times I can't make
> sense of them right now. I'll try again tomorrow morning, when my brain
> is a bit more functional.
[snippage]
I'm not half asleep now and I understand what you are saying...
I guess a better articulation would be that each Pico can only talk to one
ROS node because only one node can connect the the /dev/ttyAMAx port at a time.
There is no reason why one ROS node can not open multiple /dev/ttyAMAx port's
and talk to all of the at the same time.
It does not work like that. ROS nodes do not open connections to other ROS nodes. They broadcast messages. A simple node running in a Pico could decide to publish 4 different kinds of messages and 6 or 8 nodes on the Linux side could get the data get. Likewise, the Pico will get data from zero or more nodes that might be on other Picos or, who know, in some server room maybe.
I would modify the discovery service to be a Node that scans all of the /dev/ttyAMAx
(on Linux, Windows/MacOS are probably different) talks to each node in "discovery
protocol" and basically reads a JSON file from each Pico.
That is just not the way ROS works. ROS is better. nodes connect to data types not other nodes. They never "know" who sent the data.
So if you are using a ROS system and you need to send data to the motor controller node on the Pico. The sending node does not know what port the data goes over or even that the controller runs on a Pico. It just broadcasts velocity messages and the system routes them to every node that subscribes to "velocity". certainly, a motor control would subscribe. But also you have a spedometer display that also subscribes. Maybe a logger program too. But the sender of the data has no idea here those other nodes are.
It then provides a ROS
service that provides a dictionary of /dev/ttyAMAx to JSON file bindings. When
other ROS nodes want to connect to their /dev/ttyAMAx, they contact the discovery
service, read the JSON files, and figure out which ones it needs, and then they
open the correct /dev/ttyAMAx and start talking. The details are can be tweaked,
but the concept is that ROS nodes can find their Pico's and talk to them.
Again, ROS is a pubish/subscribe network so nodes don't know about other nodes they
connect to data and don't care where it comes from or goes to.
Mark Womack
Jan 28, 2022, 10:46:12 PM1/28/22
to hbrob...@googlegroups.com
I think it would be fine if someone wanted to develop and implement the various parts of Homer independently of the base (arms, suspension, etc). I also like the idea of things being "upgradeable", but I don't know if we understand enough to make that without extra work/replacement, etc. We could certainly start work on a larger base, and evolve from what comes out of the development and understandings from the other parts.
I'm not giving up on #3. I don't have a lot of experience, and I have some ideas that might not pan out after some experimentation, but I think this is a pretty big use case. Also, this is an experimental examplebot that is going to have the appropriate disclaimers, so I don't think we have to worry about liability. Caveat emptor.
As far as build materials and tools, yeah, expecting someone to have a CNC machine or high end 3D printer is not going to work. We'll need to think about that a bit more. The point is to make it accessible and support experimentation. Something between Camp's circular plywood and a perfectly CNC machined part. Anyone that decides to build a Homer as sophisticated as we are talking about will need access to some special tools, but we should try to keep it "off the shelf" as much as possible. Well, especially the base with that is supposed to be the platform for future extensions.
-Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHt13AojD%3DCS9-46TbSB6idzX8td8ukLEd%3DaGxE3rjtrcg%40mail.gmail.com.
Mark Womack
Jan 28, 2022, 10:47:53 PM1/28/22
to hbrob...@googlegroups.com
I think these are all good points. Do you have pictures to share of your robot? It sounds pretty cool!
-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/CAG61pbcwzzTAkU2VgDbj9eDF7b-55puBDXjyjnNcoLEBapzF_g%40mail.gmail.com.
Mark Womack
Jan 28, 2022, 10:50:02 PM1/28/22
to hbrob...@googlegroups.com
I think the use cases cover your goals. I think it would/should be a major goal for Homer.
-Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/1223215040.1582950.1642965945876%40mail.yahoo.com.
Mark Womack
Jan 28, 2022, 10:56:56 PM1/28/22
to hbrob...@googlegroups.com
Hey, new guy! :-)
I have heard of both of these, and I've seen the mecanum ones in action, and they are pretty cool. I'm sure someone here has experience with using them. I wonder how well they perform on varied terrain like carpets and such.
I have an idea on using 4 conventional wheels that I want to think through and maybe prototype. But if it works like I am thinking, it would allow for a high degree of maneuverability.
-Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CANmKH9H1K-4etwc6_wkav7v2vnjeZAX2mmpeeiBgY7t%2B9FX-fg%40mail.gmail.com.
James H Phelan
Jan 29, 2022, 8:23:54 AM1/29/22
to hbrob...@googlegroups.com
Team,
The question led me to do a Google search "mecanum wheels on carpet" with conflicting results.
No video demonstrations. Conflicting testimony from robot competition teams.
Some concern in a home setting about dirt and hair clogging the rollers.
I'm thinking large >5" solid rubber wheels with steering motors/servos that can turn 180o so the robot can drive "straight" in any direction.
This is the approach taken by one of our group for a "harvester" farm/greenhouse robot.
My project is the NASA/JPL Open Source Rover which can turn the front & back wheels 90o (45o either direction) so it can turn sharply, but not in place.
Jim
USAi Labs, Houston
James H Phelan "Nihil est sine ratione cur potius sit quam non sit" Leibniz "Here am I, the servent of the Lord; let it be with me, according to your Word" Luke 1:38
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgsu5fVSn9k2betBt9QpndKYpNM8ncfdFj_y4SkE68wqNQ%40mail.gmail.com.
don clay
Jan 29, 2022, 9:24:25 AM1/29/22
to HomeBrew Robotics Club
Have you all considered maybe incorporating Matter, the smart home unification standard into all this? Maybe it would
eliminate at least some of the cabling which you've been discussing.
On 1/28/2022 8:45 PM, Mark Womack wrote:
> I think it would be fine if someone wanted to develop and implement the various parts of Homer independently of the base
> (arms, suspension, etc). I also like the idea of things being "upgradeable", but I don't know if we understand enough to
> make that without extra work/replacement, etc. We could certainly start work on a larger base, and evolve from what
> comes out of the development and understandings from the other parts.
>
> I'm not giving up on #3. I don't have a lot of experience, and I have some ideas that might not pan out after some
> experimentation, but I think this is a pretty big use case. Also, this is an experimental examplebot that is going to
> have the appropriate disclaimers, so I don't think we have to worry about liability. Caveat emptor.
>
> As far as build materials and tools, yeah, expecting someone to have a CNC machine or high end 3D printer is not going
> to work. We'll need to think about that a bit more. The point is to make it accessible and support experimentation.
> Something between Camp's circular plywood and a perfectly CNC machined part. Anyone that decides to build a Homer as
> sophisticated as we are talking about will need access to some special tools, but we should try to keep it "off the
> shelf" as much as possible. Well, especially the base with that is supposed to be the platform for future extensions.
>
> -Mark
>
> https://share.icloud.com/photos/0cfKf_vzJ4cV3EimwJwNvjrZA <https://share.icloud.com/photos/0cfKf_vzJ4cV3EimwJwNvjrZA>
> hbrobotics+...@googlegroups.com <mailto:hbrobotics+...@googlegroups.com>.
> <https://groups.google.com/d/msgid/hbrobotics/CAF-TXgveL69g6MxBeF_%3DUfBYBuGt9mEz6Pri2X%3D2C1fiMGMpxw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
eliminate at least some of the cabling which you've been discussing.
On 1/28/2022 8:45 PM, Mark Womack wrote:
> I think it would be fine if someone wanted to develop and implement the various parts of Homer independently of the base
> (arms, suspension, etc). I also like the idea of things being "upgradeable", but I don't know if we understand enough to
> make that without extra work/replacement, etc. We could certainly start work on a larger base, and evolve from what
> comes out of the development and understandings from the other parts.
>
> I'm not giving up on #3. I don't have a lot of experience, and I have some ideas that might not pan out after some
> experimentation, but I think this is a pretty big use case. Also, this is an experimental examplebot that is going to
> have the appropriate disclaimers, so I don't think we have to worry about liability. Caveat emptor.
>
> As far as build materials and tools, yeah, expecting someone to have a CNC machine or high end 3D printer is not going
> to work. We'll need to think about that a bit more. The point is to make it accessible and support experimentation.
> Something between Camp's circular plywood and a perfectly CNC machined part. Anyone that decides to build a Homer as
> sophisticated as we are talking about will need access to some special tools, but we should try to keep it "off the
> shelf" as much as possible. Well, especially the base with that is supposed to be the platform for future extensions.
>
> -Mark
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hbrobotics/CAF-TXgsG1uxDK2BOr1R7m%2BCh75TpR5FLRahDeiD_E6VqjZ9YqA%40mail.gmail.com
> <https://groups.google.com/d/msgid/hbrobotics/CAF-TXgsG1uxDK2BOr1R7m%2BCh75TpR5FLRahDeiD_E6VqjZ9YqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> https://groups.google.com/d/msgid/hbrobotics/CAF-TXgsG1uxDK2BOr1R7m%2BCh75TpR5FLRahDeiD_E6VqjZ9YqA%40mail.gmail.com
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
>
> --
> 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 <mailto:hbrobotics+...@googlegroups.com>.
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
>
> --
> 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
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hbrobotics/CABbxVHt13AojD%3DCS9-46TbSB6idzX8td8ukLEd%3DaGxE3rjtrcg%40mail.gmail.com <https://groups.google.com/d/msgid/hbrobotics/CABbxVHt13AojD%3DCS9-46TbSB6idzX8td8ukLEd%3DaGxE3rjtrcg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> 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 <mailto:hbrobotics+...@googlegroups.com>.
> --
> 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
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hbrobotics/CAF-TXgveL69g6MxBeF_%3DUfBYBuGt9mEz6Pri2X%3D2C1fiMGMpxw%40mail.gmail.com
> <https://groups.google.com/d/msgid/hbrobotics/CAF-TXgveL69g6MxBeF_%3DUfBYBuGt9mEz6Pri2X%3D2C1fiMGMpxw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Wayne Gramlich
Jan 29, 2022, 11:04:45 AM1/29/22
to hbrob...@googlegroups.com, wayne.gra...@gmail.com
All:
Mecanum wheels are sub-set of a larger wheel catagory called omni-wheels.
The Wikipedia article on omni-wheels is a reasonable place to start.
In robotics, they omni-wheels work best when the floor is both very flat and very clean. They have all sorts of nooks and crannies in them that pick dust bunnies and jam.
I've tried using them as a castor. My living room floor has an electrical outlet in middle of the floor that is about 1/8in above the floor. The robot castor always found the electrical outlet and got stuck on it. (Murphy's law, I guess.)
These days I'm in the steerable wheels camp, with a strong preference for holonomic drives based on steerable wheels (e.g. the Willow Garage PR2.)
Regards,
-Wayne
>> https://groups.google.com/d/msgid/hbrobotics/CANmKH9H1K-4etwc6_wkav7v2vnjeZAX2mmpeeiBgY7t%2B9FX-fg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/hbrobotics/CANmKH9H1K-4etwc6_wkav7v2vnjeZAX2mmpeeiBgY7t%2B9FX-fg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
Mecanum wheels are sub-set of a larger wheel catagory called omni-wheels.
The Wikipedia article on omni-wheels is a reasonable place to start.
In robotics, they omni-wheels work best when the floor is both very flat and very clean. They have all sorts of nooks and crannies in them that pick dust bunnies and jam.
I've tried using them as a castor. My living room floor has an electrical outlet in middle of the floor that is about 1/8in above the floor. The robot castor always found the electrical outlet and got stuck on it. (Murphy's law, I guess.)
These days I'm in the steerable wheels camp, with a strong preference for holonomic drives based on steerable wheels (e.g. the Willow Garage PR2.)
Regards,
-Wayne
>> <https://groups.google.com/d/msgid/hbrobotics/CANmKH9H1K-4etwc6_wkav7v2vnjeZAX2mmpeeiBgY7t%2B9FX-fg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
Pito Salas
Jan 29, 2022, 1:49:54 PM1/29/22
to hbrob...@googlegroups.com
I'm sorry that I didn't follow this thread in close detail. I have a question about Wheels. The robot I have in mind will have to go outdoors in good weather. My criteria say that it should be able to travel on smooth outdoor surfaces, compatible for example with a wheel chair or baby carriage.
How would you think about using 4 wheels (on the big side) to a tracked undercarriage? What are the tradeoffs? I am more comfortable with four wheels but my partner is pushing of a tracks. What is the established wisdom around this question?
Thanks!
Pito Salas
Faculty, Computer Science
Brandeis University
Faculty, Computer Science
Brandeis University
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/07f7cb08-902a-4bb8-0dbb-995b378483f5%40gmail.com.
Chris Albertson
Jan 29, 2022, 2:00:21 PM1/29/22
to hbrob...@googlegroups.com
On Sat, Jan 29, 2022 at 5:23 AM James H Phelan <jhph...@hal-pc.org> wrote:
Team,
The question led me to do a Google search "mecanum wheels on carpet" with conflicting results.
No video demonstrations. Conflicting testimony from robot competition teams.
Some concern in a home setting about dirt and hair clogging the rollers.
I'm thinking large >5" solid rubber wheels with steering motors/servos that can turn 180o so the robot can drive "straight" in any direction.
This is the approach taken by one of our group for a "harvester" farm/greenhouse robot.
My project is the NASA/JPL Open Source Rover which can turn the front & back wheels 90o (45o either direction) so it can turn sharply, but not in place.
The mecham and omni wheel depend on predictable friction with the ground. You only have that on clean and very flat surfaces.
Two wheel drive with the other two wheels free to turn, like casters, is the simplest but two-wheel drive
has problems on uneven ground. Wheelchairs are like this.
With 2-wheel steering, you have an Ackerman system. The same as used on cars and trucks. Ackerman is very well understood and obviously, it works, but as we know, parallel parking is hard. and many times you need to back-up to turn in tight spaces.
But holonomic bases with their ability to move in all directions have problems too.
1) They use 8 moters and cost 4X more then simple 2 wheel drive caster systems
2) because they have more driving option, the planning software, needs to sort through more options.
My quadruped robot has even more flexibility than a holonomic base because it can move a small amount by leaning without moving the feet and the body can also move up and down the rotate in three directions while keeping the feet stationary. So how does the planner decide which to do? Does it lean, rotate then walk forward or sidestep? If it rotates, where is the center of rotation, body center, or between one of the leg pairs? Almost all the demos we see on Youtube are teleoperated where a human makes the decisions but a useful service robot has to decide on its own.
I watch my dog and she actually does "all of the above" simultaneously and this is probably what a robot should do, sidestep while pivoting to a head-forward orientation all while maintaining balance. A 4-wheel steering robot base should do the same. I'm saying this to point out that a holonomic path planner is not simple. You would think a more maneuverable robot would be easier to drive, No. it is easier if the opinions are limited.
Different people will want to build different bases. The 4-wheel steering system is expensive as it uses 8 motors and 8 drivers and requires sophisticated planner software. The two-wheel-drive system has a minim cost and drives like a table-bot. I think the only solution is to design a system that can be upgraded with only a screwdriver and a wrench. Figure out in advance where all the holes go and design a family of parts that can be assembled in six different ways. This is why they invented CAD.
Acttualy I thing you only need three different ways;
1) traction motor and the wheel is fixed to the chassis
2) traction motor and the wheel is allowed to pivot freely
3) traction motor and the wheel is allowed to pivot as above but the pivot is controlled by a second motor
Case #2 and #3 need a different wheel mount because #3 needs to hold the ground contact point directly under the pivot while #2 needs the contact displaced from the pivot.
One other mechanical design decision is if the wheels can be simply attached to the mother shafts. This works on a very lightweight robot but can result in bent motor shafts on a larger platform.
To keep all for wheel in ground contact when the floor is not perfect you need some kind of suspension.
Chris Albertson
Jan 29, 2022, 2:36:33 PM1/29/22
to hbrob...@googlegroups.com
Short answer: Buy the toy in the last link below for $100. Then buy an automotive car seat adjustment motor and attach it to the toy's steering rod in place of the toy steering wheel. Add a computer and you are done.
Longer answer.
Tacks have only one real purpose other then to look cool. tracks allow heavy vehicles to drive over softer ground where without tracks the wheels would push into the surface.
So what you do is look at the vehicle weight and the square area of the ground contact patches and see if this is over the load bearing capacity of the ground you want to drive over. By this criteria you'd think a small robot wold never need tracks. But maybe you are driving over very short ground like snow or the top of grass where you do not wish to crush the blades of the grass.
Disadvantage of tracks is
1) you get very poor fuel economy of battery life
2) they can only turn well on low fraction surfaces. They turn well in dirt and poorly on concrete. Turnng a track mines that parts of the track must side-skid.
For a rabot that has to travel outdoors on good surfaces, use wheels that are designed for those surfaces.
I am converting a toy ride-on kiddie-car to be a sidewalk-bot. The car is big enough for a 4 year old child to ride inside and it drives very well on the sidewalk or on grass and it is big enough to be powered by a lead acid marine battery and use an older notebook PC as the control computer. So I have "tons" of computer power with a dual core Intal CPU.
I would suggest finding some self-powered sidewalk toy, maybe not as large as mine but still one designed to support the weight of a small child. Buy is used if you can. They are cheap at years sales and craigslist.
This is like mine. Even at full asking price, you get a HUGE robot platform for cheap.
Parts are standardized of these and available on Amazon. If you do not like to buy the truck you can buy just the wheels and motors. They are sold as repair parts. These will power a 80 pound payload on a sidewalk at a fast walking pace. There is an industry standard, The motors and wheels go on a through axel and connect via that plastic convoluted spline. The price is right. This is all toy-quality construction but if you do not place 80 pounds on the wheels it might last for 10 years. If you do place the wight on, there are repair parts on Amazon. There are two kinds 12 volt and 24 volts. They seem to interchance.
Here is a smaller version a ready-to-go sidewalk robot chassis. This one uses 6 volt motors. They are not as fast asthe larger cars.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/5C7781B1-50F1-46AF-807F-634D8BE7478D%40gmail.com.
Chris Albertson
Jan 29, 2022, 2:41:32 PM1/29/22
to hbrob...@googlegroups.com
One more thing that has to be decided before any kind of collaboration can take place is the mechanics of collaboration. How is the design documented how are versions of the design and documents kept.
For example, let's say someone says, "We should drill a 10mm hole on this spot. to allow for batter cable routing" I assume this means someone proposes a change to a design file. then consensus develops and the 10mm hole idea is done or dropped. And something gets updated on a computer where everyone has access to the file.
If the base design is kept in Onshape then that system keeps history but I doubt you can make everyone use that. Perhaps the STEP files are stored in Github. That is more neutral. Are instructions kept on a Wiki or does someone maintain a Microsoft Word file on their own personal PC?
Getting this done is very hard. No one wants to think about it but nothing can even be started without this.
The very worst thing to do is use email threads where anyone and everyone posts attachments and then store them in the email readers.
My preference is to adopt Github and use it exclusively. And make a rule that all proposed changes by made on a "branch." and when the powers that be decide the idea is a "go" the branch is merged onto the main branch. EVERYTHING goes there documents, CAD files Schematics, assembly instructions, and whatever.
When issues come up, Github's issue tracker is used. And Github's wiki is sued to do collective editing.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgveL69g6MxBeF_%3DUfBYBuGt9mEz6Pri2X%3D2C1fiMGMpxw%40mail.gmail.com.
Wayne Gramlich
Jan 29, 2022, 3:17:13 PM1/29/22
to hbrob...@googlegroups.com, wayne.gra...@gramlich.com
All:
I am a huge fan of Git. I think it is an excellent collaboration tool.
* Software: Git was designed for software collaboration. 'nuf said.
* Documentation: If you put your documentation in markdown format, it works pretty well.
* Electronics: If you use KiCAD (recommended), they are text files and can be stored in git.
In general, only one person at a time can edit the PCB/schematic, but that is very workable.
* Mechanical: First you have to pick your MCAD system:
Various closed source MCAD vendors have "free" version for "hackers". They are "free" until
the somebody in the corporate management decides they are not "free" any more. The two
dominate open source systems out there are OpenScad and FreeCAD. OpenScad is really only a
3D modeling only and can only generate .stl files; CNC is not really on the table. OpenScad is
very sharable via git, since it is basically a textual program that is executed to generate the model.
FreeCAD is further along in CNC support, can input/export STEP files, etc. Internally, its file format
is textual. However the on disk format is in .gzip format. Storing large binary files on git chews up
disk space fast. If you use FreeCAD, they should be converted between .gzip format and .tar format
before uploading/downloading from the shared repository. I've written some Python code to do this,
if there is any interest. All MCAD systems have a serious learning curve. In general, most programmers
pick up OpenScad pretty fast. The choice of MCAD systems will have to be made by the people who
sign up to do MCAD. I suspect it will be a contentious discussion.
Regards,
-Wayne
> One more thing that has to be decided before any kind of collaboration can
> take place is the mechanics of collaboration. How is the design
> documented how are versions of the design and documents kept.
>
> For example, let's say someone says, "We should drill a 10mm hole on this
> spot. to allow for batter cable routing" I assume this means someone
> proposes a change to a design file. then consensus develops and the 10mm
> hole idea is done or dropped. And something gets updated on a computer
> where everyone has access to the file.
>
> If the base design is kept in Onshape then that system keeps history but I
> doubt you can make everyone use that. Perhaps the STEP files are stored in
> Github. That is more neutral. Are instructions kept on a Wiki or does
> someone maintain a Microsoft Word file on their own personal PC?
>
> Getting this done is very hard. No one wants to think about it but nothing
> can even be started without this.
>
> The very worst thing to do is use email threads where anyone and everyone
> posts attachments and then store them in the email readers.
>
> My preference is to adopt Github and use it exclusively. And make a rule
> that all proposed changes by made on a "branch." and when the powers that
> be decide the idea is a "go" the branch is merged onto the main branch.
> EVERYTHING goes there documents, CAD files Schematics, assembly
> instructions, and whatever.
>
> When issues come up, Github's issue tracker is used. And Github's wiki
> is sued to do collective editing.
>
[snippage]
I am a huge fan of Git. I think it is an excellent collaboration tool.
* Software: Git was designed for software collaboration. 'nuf said.
* Documentation: If you put your documentation in markdown format, it works pretty well.
* Electronics: If you use KiCAD (recommended), they are text files and can be stored in git.
In general, only one person at a time can edit the PCB/schematic, but that is very workable.
* Mechanical: First you have to pick your MCAD system:
Various closed source MCAD vendors have "free" version for "hackers". They are "free" until
the somebody in the corporate management decides they are not "free" any more. The two
dominate open source systems out there are OpenScad and FreeCAD. OpenScad is really only a
3D modeling only and can only generate .stl files; CNC is not really on the table. OpenScad is
very sharable via git, since it is basically a textual program that is executed to generate the model.
FreeCAD is further along in CNC support, can input/export STEP files, etc. Internally, its file format
is textual. However the on disk format is in .gzip format. Storing large binary files on git chews up
disk space fast. If you use FreeCAD, they should be converted between .gzip format and .tar format
before uploading/downloading from the shared repository. I've written some Python code to do this,
if there is any interest. All MCAD systems have a serious learning curve. In general, most programmers
pick up OpenScad pretty fast. The choice of MCAD systems will have to be made by the people who
sign up to do MCAD. I suspect it will be a contentious discussion.
Regards,
-Wayne
> One more thing that has to be decided before any kind of collaboration can
> take place is the mechanics of collaboration. How is the design
> documented how are versions of the design and documents kept.
>
> For example, let's say someone says, "We should drill a 10mm hole on this
> spot. to allow for batter cable routing" I assume this means someone
> proposes a change to a design file. then consensus develops and the 10mm
> hole idea is done or dropped. And something gets updated on a computer
> where everyone has access to the file.
>
> If the base design is kept in Onshape then that system keeps history but I
> doubt you can make everyone use that. Perhaps the STEP files are stored in
> Github. That is more neutral. Are instructions kept on a Wiki or does
> someone maintain a Microsoft Word file on their own personal PC?
>
> Getting this done is very hard. No one wants to think about it but nothing
> can even be started without this.
>
> The very worst thing to do is use email threads where anyone and everyone
> posts attachments and then store them in the email readers.
>
> My preference is to adopt Github and use it exclusively. And make a rule
> that all proposed changes by made on a "branch." and when the powers that
> be decide the idea is a "go" the branch is merged onto the main branch.
> EVERYTHING goes there documents, CAD files Schematics, assembly
> instructions, and whatever.
>
> When issues come up, Github's issue tracker is used. And Github's wiki
> is sued to do collective editing.
>
Mark Womack
Jan 29, 2022, 9:59:31 PM1/29/22
to hbrob...@googlegroups.com
git - Yes. I'm assuming we can get a project in the HRBC git repository.
KiCAD - I haven't used it but it has gotten a lot of great reviews here, so I'm in. We aren't aiming for custom PCBs, but a schematic is going to be critical and if someone wants to convert that to a PCB, then they will be more than halfway there.
OpenScad/FreeCAD/OnShape - I think the most important aspect for the project at this point is being able to visually represent the design in 3D. I think we should see how far we can get without resorting to CNC or high-end 3D printing. We may change our mind, but we need to make a decent attempt. I've used OnShape with some success, but I am open to a different consensus. The files need to be checked into git for versioning.
git reviewing KiCAD and CAD files...I don't know how that is going to work beyond what Chris A said in the parent thread: put the new/updated files in a branch and the reviewer has to open the files locally to check the changes (which will need to be explained in detail in the branch comments).
-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/cabac08c-cac4-bf5f-9db5-c6d73843864e%40gmail.com.
Mark Womack
Jan 29, 2022, 10:25:45 PM1/29/22
to hbrob...@googlegroups.com
OK, I'm going to float this now. I thought of it earlier this week, but wanted to think it through.
I was looking at a video about the holonomic motors and wheels, and it is pretty slick. But unless there is something different I haven't seen, I'm rather unconvinced that they will work great on different household terrain.
And Chris outlines a lot of options above, but I am wondering if it can be slightly simpler.
- Four regular wheels, each with their own motor for propulsion.
- The steering is done per wheel pair, but they are paired with their diagonal opposite (see picture).
- The wheel pairs are connected such that when they are turned, each wheel in the pair has the same angle. I think that makes it pretty easy to go along just about any path in a continuous motion or to stop, turn the wheels to a specific angle(s) and then go again. As an added bonus you can also arrange the wheels so that the robot can spin in place.
- You would need four motors for the wheels and 2 stepper motors for the steering. If you get the stepper motors that can do a full 360 wrap-around, it seems to me that you could have some very fluid motion. Some kind of chain on the stepper motors to make sure both wheels turn with no slippage (you wouldn't want them to get out of sync with each other).
I'm sure this isn't a completely new idea. I probably saw it somewhere and it is just bubbling up from my subconscious. Someone reading this thread is about to post a reference to the PhD thesis where this drive was first proposed and the robot that first implemented it. Or the patent number and inventors. One of the two.
I was going to try to build a prototype, but drawing and explaining is faster.
-Mark
Chris Albertson
Jan 29, 2022, 10:59:18 PM1/29/22
to hbrob...@googlegroups.com
You do not have to agree on a CAD system. You can use a common file format, "STEP". I don't think there is a 3D CAD system that cannot read and write STEP (*.stp) files.
As for custom PCBs, Yes it takes time to learn how to design one. But after one person does that, all a builder does is buy one. That said, there might not be a need for this.
One good tool for documenting wire and cable is "WireViz" It makes a kind of diagram you would use to build a wire harness or cable. A complex robot has tons of wires and a schematic is not enough
As for wheels, have you seen hoverboard wheels? They are standardized to by 6.5 inch diameter. They are very strong as they can hold an adult riding over bumps. The motor is strong too, at 350 Watts and it has a max speed about twice as fast as most people walk. Seems expensive until you see it has an encoder, motor, wheel, tire, and axel system designed for weight-bearing. You need a triple h-bridge and a microcontroller to drive it. Amazon sells then for $66
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgsYV9%3DraykB-yka8OdsgM82JaCtsb6nANPQ2cOkaPQqHw%40mail.gmail.com.
Mark Womack
Jan 29, 2022, 11:05:16 PM1/29/22
to hbrob...@googlegroups.com
So, have we reached any kind of consensus beyond Ethernet rules and we should all use it? (ok, those botblox ethernet boards are the BOMB, thanks for that pointer, Steve!)
It seems to me that we can agree that for ROS communication, some kind of USB/Serial solution may work best. Whether it is some sort of custom protocol with translation to ROS pub/sub/procedure call or micro-ROS seems to still be up in the air (with concerns about performance).
This communication is for subsystems, not the implementation of a subsystem. Internally a subsystem might use any bus system that makes sense for what it is implementing (I2C, SPI, canBUS, whatever).
So, a subsystem could be an arm with a gripper. Or a group of sensors.
I think we can also agree that a solution will allow for a subsystem to publish/subscribe to any given ROS topic(s). Topics subscribed to should be sent (in some manner) to the subsystem, and data the subsystem is generating should be sent out (in some manner) to the greater ROS environment. I guess the same would be true for procedural calls, but frankly I've never used that feature, so I don't know much about it.
The goal is to allow for the development of a subsystem with a common communication connection to make integration easier.
-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/CABbxVHu1%2Bg1WYz_WopsFtpBqgQfDBq-yE-2bcuW40t4HCh8oEQ%40mail.gmail.com.
Michael Wimble
Jan 30, 2022, 12:28:13 AM1/30/22
to hbrob...@googlegroups.com
As an example of WireViz, here is one of the wiring diagrams for my robot, Puck. It works rather well.
Wayne Gramlich
Jan 30, 2022, 12:54:37 AM1/30/22
to hbrob...@googlegroups.com, Mark Womack, Wayne Gramlich
All:
I have access to the HBRC repository. Contact me when you have agreed
on repo name.
Regards,
-Wayne
I have access to the HBRC repository. Contact me when you have agreed
on repo name.
Regards,
-Wayne
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgsYV9%3DraykB-yka8OdsgM82JaCtsb6nANPQ2cOkaPQqHw%40mail.gmail.com.
thomas...@gmail.com
Jan 30, 2022, 4:59:06 AM1/30/22
to hbrob...@googlegroups.com, wayne.gra...@gramlich.com
Your more than a fan. 😊
--
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/cabac08c-cac4-bf5f-9db5-c6d73843864e%40gmail.com.
thomas...@gmail.com
Jan 30, 2022, 4:59:30 AM1/30/22
to hbrob...@googlegroups.com
Your more than a fan. 😊
-----Original Message-----
From: hbrob...@googlegroups.com <hbrob...@googlegroups.com> On Behalf Of Wayne Gramlich
Sent: Saturday, January 29, 2022 12:17 PM
To: hbrob...@googlegroups.com
Cc: wayne.gra...@gramlich.com
Subject: Re: [HBRobotics] Collaboration (was Homer Base and Wheels)
-----Original Message-----
From: hbrob...@googlegroups.com <hbrob...@googlegroups.com> On Behalf Of Wayne Gramlich
Sent: Saturday, January 29, 2022 12:17 PM
To: hbrob...@googlegroups.com
Cc: wayne.gra...@gramlich.com
Subject: Re: [HBRobotics] Collaboration (was Homer Base and Wheels)
--
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/cabac08c-cac4-bf5f-9db5-c6d73843864e%40gmail.com.
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.
Mark Womack
Jan 30, 2022, 1:48:05 PM1/30/22
to hbrob...@googlegroups.com
Since one of the guidelines is to not require custom PCBs, I think it is WireViz FTW.
--
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/BEAD0D43-B617-4AB8-9F71-E380D03FED10%40gmail.com.
Mark Womack
Jan 30, 2022, 1:54:54 PM1/30/22
to hbrob...@googlegroups.com
This is a proposal, not a final determination:
HBRCExampleBots
Bart
Code (All source code is here, microcontroller and microcomputer)
Electronic (All Electronic design is here: WireViz, KiCAD, as appropriate)
Physical (All physical design is here: CAD)
Simulation (All configuration related to running as simulation)
README.md
Homer
Code
Electronic
Physical
Simulation
README.md
README.md
DISCLAIMER.md
Mark Womack
Jan 30, 2022, 1:56:11 PM1/30/22
to hbrob...@googlegroups.com
Oh, there probable needs to be a "Shared" directory at the same level as the bots since we are looking to use same/similar code for the bases.
-Mark
Chris Albertson
Jan 30, 2022, 2:01:03 PM1/30/22
to hbrob...@googlegroups.com, Mark Womack, Wayne Gramlich
I think it best to wait until someone actual has data in their own Git repository that people generally like. Then fork it to the hbrobotics repository.
The job of the hbrobotic repository's "gate keeper" is then to approve or not approve pull requests and to merge conflicts.
I would not start with an empty repository. That is a good way to make a mess. Wait until you have one that most people agree is well done and well organized. It need not be complete but you want to start with an outline that people can see
One very hard job is making it possible for beginners to turn a Git repository into a robot. Cloning a repository and committing changes back is second nature to many developers but the typical end-user expects to click "install" and everything just works. How to bridge that gap? Either use really good instructions and maybe even a video walkthrough or use Docker or a VM image.
Same with CAD files. You can place a 3D model of a motor mount in GitHub but many people do not know how to transform a *.stp file into a part that can be bolted to a robot frame.
The little table 'bot was easy, you simply buy every part from Pololu and follow the directions on the Pololu website. All you need is a screwdriver and about 40 minutes. But a big custom design robot is altogether harder. Wire harness diagrams, schematics, CAD files, and source code all have to be assembled into a working system.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/55831a4c-e2f6-361d-add8-c9964f4c4c1f%40gmail.com.
James H Phelan
Jan 30, 2022, 2:15:30 PM1/30/22
to hbrob...@googlegroups.com
Team,
FWIW:
The NASA/JPL Open Source Rover community
(and anybody who shares code) uses git extensively. I'm really
bad at it but learning slowly.
KiCAD for PCB design. I've used it and
it's not too difficult to learn.
Talk of moving to OnShape for mechanical. I've no experience there.
You may not need heavy duty CNC but 3D
printing of some custom part is almost inevitable.
In the NVIDIA AI/Robotics course -
(which I'm taking/helping through Houston
Community College which one of our group is teaching)
Jupyter notebooks alternate code blocks and markdown blocks which can include text, diagrams, photos, video....
Great for teaching, documentation. Going
to try to move to it.
JHP
USAi Labs, Houston
James H Phelan "Nihil est sine ratione cur potius sit quam non sit" Leibniz "Here am I, the servent of the Lord; let it be with me, according to your Word" Luke 1:38
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgsYV9%3DraykB-yka8OdsgM82JaCtsb6nANPQ2cOkaPQqHw%40mail.gmail.com.
Chris Albertson
Jan 30, 2022, 2:30:44 PM1/30/22
to hbrob...@googlegroups.com
That's a start. I got the comment about "shared". typically you have a "Bart" repository and a "Homer" repository and then all the common staff is abstracted to a third repository called perhaps "RobotUtilities" (or whatever) that contains infrastructure-like stuff or common sensors.
Assuming this is ROS-based there is nothing that goes into "simulation" except possibly URDF and related low-resolution STL files but I would logically place that with source as it defines the robot and is used for non-simulation purposes too and it needs to be together to work.
In the ROS universe, a simulation is just a few parameters changed in a launch file. The same binary control code works with no need to recompile.
Where most people will have trouble and stop, is setting up the infrastructure. Simply saying in the README "install Ubuntu 20 on the Pi4 than ROS2/Foxy. Make a workspace and clone this repository. Place it in your path and type "Homer" to start the robot." This is enough for an experienced developer but I have not yet seen even once, good enough instructions for a person starting from zero. Others have tried we need to figure this out. Test it on some inexperienced users.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgtJ9GG-X81HZmHDvHgD_A7BF2eyVHyT2P2b6Pxi0y3Oxw%40mail.gmail.com.
Wayne Gramlich
Jan 30, 2022, 2:37:24 PM1/30/22
to hbrob...@googlegroups.com
Mark:
That is a reasonable structure. Ultimately it is up to you folks to decide.
My only request/requirement is that no binary files be checked into GitHub.
It clutters up our GitHub repo fast.
Regards,
-Wayne
That is a reasonable structure. Ultimately it is up to you folks to decide.
My only request/requirement is that no binary files be checked into GitHub.
It clutters up our GitHub repo fast.
Regards,
-Wayne
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgtJ9GG-X81HZmHDvHgD_A7BF2eyVHyT2P2b6Pxi0y3Oxw%40mail.gmail.com.
Steve " 'dillo" Okay
Jan 30, 2022, 4:27:17 PM1/30/22
to HomeBrew Robotics Club
Tracks are great for outside or where you can guarantee that the floor inside will be durable. They will mark & scratch/wear just about anything else though, particularly the sort of flooring that is common in homes and offices.
I wouldn't want tracks for a robot of any sort of significant weight on a "nice" office floor or house/apartment.
'dillo
Chris Albertson
Jan 30, 2022, 8:51:33 PM1/30/22
to hbrob...@googlegroups.com
That method is a compromise. It is geometrically not perfect but much better than 4-wheel skid steering. With diagonally connected wheels you save the cost of three steering motors but then you need to add belts to connect the wheels. The other cost is not-perfect geometry.
It can drive on any straight line, so parallel parking is easy. But it can not drive along an arc without skidding.
Perfect steering is easy to define: The imaginary lines extended from all axels meet at one point. That point can be 50 feet to the side or under the robot. But for non-skid steering, they must all meet at the same point. With your proposed system the diagonally connected wheels will always be parallel. Parellel lines never intersect. But it is a decent approximation for a large turn radius. and is "perfect" in some cases like driving straight in any directions or spinning around the center.
But it can work because we have a computer to figure paths that do not skid. It can do "stop and spin" and k-turns and sideways translations to avoid driving small radius arcs.
My opinion? Motors are cheap now and belts are complex because they require tension adjustment, Also you have almost all the work of full 4-wheel steering done if the wheels can turn at all. So much of the design is the vertical axels and required bearings, You can turn vertical steering axels with something cheap like an automotive windshield wiper or window crank motor that have plenty of gearing.
A really like holonomic drives. Here is a high-end version of a home service robot with an arm and holonomic drive. Watch it scoot sideways as it drives into the shipping container. I think this design is possible but smaller on a hobby budget and of course with a more normal gripper. A human-size arm is about $1,000 to build plus the base. $2K is the high end of hobby 'bots but this is a far-end goal with the 2-wheel drive tea-cart being the entry point for Homer. https://youtu.be/yYUuWWnfRsk?t=51
As for construction technology, what about 2020 extrusions? All you need is a hand held hack saw and a miter box to guide the saw. A combination of standard brackets and 3D printed brackets. 2020 is good enough for a base with a 3 foot tall tray. But not good enough for an arm
--
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-TXgvPy1hEgCt32_kMbVjC-CQs%2B_%2B-rnUZZRpp5ruuP523Ew%40mail.gmail.com.
Mark Womack
Jan 31, 2022, 5:29:15 PM1/31/22
to hbrob...@googlegroups.com
I'll have to take your word on it about the skidding part. If the steering is reactive enough, I don't see how it would ever skid. And if it is a tight space, stopping and turning is going to be required anyways. I would like to try a prototype in the future.
That video cracks me up. I love Boston Dynamics. Google was pretty shortsighted to let that one get a way, but maybe they needed to leave so they could bloom under Hyundai. Anyways, both of those robots are on a very clean, cement surface. Almost no house I have ever been in has a surface like that. Show me a video of a holonomic drive working across a terrain boundary going from vinyl flooring to a rug. Add then show it working on a shag rug. Anyway, like I said, I think holonomic is slick, and it would work great in a warehouse (or even a tabletop or short rug), but I don't know about a house.
I was also considering this type of aluminum extrusion material that you mention. I think it would be a strong alternative for customized parts, and would allow for experimentation. Does anyone out there have experience using it?
-Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHvudVwh_2D4Xb%3DZXQvpRCW4E54rGGbVrogGgF3XzW88Sw%40mail.gmail.com.
Carl Sutter
Jan 31, 2022, 6:06:17 PM1/31/22
to HomeBrew Robotics Club
Similar to a Synchro Drive base: https://groups.csail.mit.edu/drl/courses/cs54-2001s/synchro.html
Michael Wimble
Jan 31, 2022, 6:42:51 PM1/31/22
to hbrob...@googlegroups.com
Puck is made with 20-20. For prototypes, it’s great.
> On Jan 31, 2022, at 2:29 PM, Mark Womack <mwo...@gmail.com> wrote:
>
>
> On Jan 31, 2022, at 2:29 PM, Mark Womack <mwo...@gmail.com> wrote:
>
>
Mark Womack
Jan 31, 2022, 7:16:04 PM1/31/22
to hbrob...@googlegroups.com
Yes. Very interesting. Though I don't understand the need to have one motor to drive all the wheels for motion. I'm having trouble imagining what that would look like. It sounds too complicated. I certainly would try that with Legos (like that page is thinking).
The pictures on this page make it look like each wheel has its own motor.
-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/064f9f1a-52ce-47db-9ebb-b683e24e8486n%40googlegroups.com.
Mark Womack
Jan 31, 2022, 7:19:27 PM1/31/22
to hbrob...@googlegroups.com
And now for the forgotten link...
It is loading more messages.
0 new messages