HBRC ROS2 reference robot?

[Mark Womack]

Greetings Home Brewians,

I know it has been a long time since I last posted or popped my head out (years, I know). But I've decided to spend more time getting back into robots. And it occurred to me, looking at posts, that it would be really useful to anyone getting started in robots and/or ROS to have a "reference" implementation. A simple robot that could be simulated as well as physically built to spec. The reference could be implemented to do some basic task, like object avoidance or maybe something more complex.

I don't know if there is already something like this in ROS (ROS2 has moved the goal posts for my knowledge base), but I think that it would be something super useful for HBRC to create and maintain. It would allow all members and enthusiasts to have a target to build and maybe something to build on and extend. I'm working from my experience with the RoboMagellan Victoria project that I worked on with Gris Brooks, Mike Wimble, and Ralph Hipps. We had everything detailed in the git hub with instructions, etc. And while the robot itself was not easily reproducible since we were using a custom Husqvarna chassis, that could easily be addressed with a version that could be built to specs. I'm focusing on a mobile robot, but there could also be a "reference" robot for an arm or anything else. The more the merrier, and the more someone would learn.

What do you think? Is this something that would interest a group of HBRC'rs? Does HBRC maintain a github where projects, code, instructions, and specifications could be maintained?

-Mark

[camp .]

Hello Mark!

Good to hear from you. There's a lot to unpack here. We do have a GitHub, but it isn't very active: https://github.com/hbrobotics

 

    And there is a platform that Wayne and others have been developing: https://github.com/hbrobotics/hbrc_ros_robot_platform and I've been working with the Botvac platform: https://github.com/cpeavy2/botvac_node I consider Botvac to be the best platform as it's not a tabletop robot and has a lidar plus the potential for further development (simulation, bump-sensor, drop sensor) all the topics are being published. I'm currently in the process of making it into a Mock TurtleBot with a second Raspberry Pi, Pi Camera, and ultrasonics, which I do have running on ROS2 (Thanks to Mike, Ralph, and others). I also note the TurtleBot 4 coming down the pike from Clearpath: https://clearpathrobotics.com/blog/2021/10/clearpath-robotics-announces-turtlebot-4/

 

    That having been said I'm convinced 3" wheels aren't going to cut it. Two words: thick carpet. To that end, I am interested in pursuing a custom differential drive platform using wheels like this: https://www.dfrobot.com/product-1203.html on a 14" wood round with casters. These are the same gear motor wheels used on Big Orange: https://www.dfrobot.com/product-361.html

 

Join our Weekly Tuesday ROS Discussion Group this evening if you can. Dec 21, 2021 07:00 PM Pacific Time:

https://us06web.zoom.us/j/86997374105?pwd=Zi9xQ2xzSU5TelRZUERrZmtqZXFDUT09 

Meeting ID: 869 9737 4105, Passcode: 367850

 

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 https://groups.google.com/d/msgid/hbrobotics/CAF-TXgv_mOK7FnnzAYPEPR_JamGjYMWr%3DceHHGXu1uGzWEdsVg%40mail.gmail.com.

[Chris Albertson]

I think "Turtlebot" has been the "standard" platform for forever.   If you make yor own "standard" it will be really, really hard to convince all the people who write ROS2 software to verify their new code works on your platform.  But they will test on Turtlebot and fix things if it is reported broken.

THIS is the important point.  THEY have to accept the standard platform,  You or we can't decide what others using for test and validation.   You can call it a reference platform but if the next revision of the software breaks, then you reference no longs serves its purpose because it can only run patched code.

Turtlebot is very "vanilla" so if you need to see how something should be done you can always look at their github repository and just copy it.

If you want to own an actually Turtlebot.  they cost $500.   I doubt you could build on for that as the computer, lidar, meters and battery will add up to $500.

I read the comment about carpet.   My solution:  Look at the wheels used by the DF Robot "Wild Thumper" those will work on any surface and if my robot crashes into a wall it climbs the wall until it is vertical and flips over.   I've run over 2x4 luber and standard red brink.    Thw wheels stick so anything.   they have an internal 12mm (?) hex socket.  It is easy to make adaptors if you drill out a bolt. 

--

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-TXgv_mOK7FnnzAYPEPR_JamGjYMWr%3DceHHGXu1uGzWEdsVg%40mail.gmail.com.

--

Chris Albertson
Redondo Beach, California

[Wayne C. Gramlich]

Mark:

The HR2 (HBRC ROS Robot => HRR => HR2) is/was my latest attempt. It is based the
Pololu Romi platform with a custom PCB. Pololu has since come out with the Romi
32U4 which kind of makes my custom PCB pointless.

In general, a Romi Base + Romi 32U4 Arduino/Motor/Encoder Board + RasPi is probably
a better way to go. Add in a LD06 Lidara scanner and it is pretty good ROS starter
platform. All parts are off-the-shelf. Some basic soldering is required. If you
want to add in an a Pololu Romi Arm you can pick up small objects. If you want to
play around with vision, USB camera can be attempted.

All small team of people could use a common base and the weekly ROS meeting to talk
about and deal with issues. If a bunch of people wanted to get together and do a
group build (Covid is an issue), we can probably scrounge up some lab space on some
weekend.

Regards,

-Wayne

[Chris Albertson]

About wheels.  I said "DF Robot".  Sorry, they are "Dagu" and sold either direct from Dagu or from Pololu.  Link below.

https://www.pololu.com/product/1555

As said, they work indoors and out and will roll over a 2x4 laid flat

--
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/81d2da02-6609-aa93-b430-61416c43436d%40Gramlich.Net.

[Dave Everett]

I and 2 friends down here have been working on a home buildable robot for a few years now. We meet every week to work on it.

It is home sized, can self dock and charge, uses standard arduino modules and a mini-itx computer to run ROS. We were using Kinetic and have just upgraded to Melodic, this took 3 weeks.

The robot is built in stages. All 3 of us have built the same robot so any development works on the other's robots. It is constructed of 20x20x3mm aluminium angle. The mobile base holds the main battery, motors and RPlidar. It also has a fixed bumper with some cliff sensors and 2 IR and sonar for docking. The drive motors are from GoBilda in the USA and the wheels are about 6 inches in diameter from DFrobot. The rear caster is 100mm in diameter to avoid catching on small items or thick carpet. Battery power is a 12v 12AH battery, I chose a SLA battery as they are more readily available and heavy which helps for a tall robot.

The body was originally a single box, I have now redesigned that so it can rotate. The body also has a belt driven lift which raises or lowers the arm. The body holds the controllers for the body rotate, the mini-itx, power distribution, main power and motor power switches, power display, speakers and amplifier for the speech synth. This is not finished yet.

The arm (under construction) can reach the ground or onto a table or cupboard up to 900mm off the ground. The arm has 5DOF, culminating in a 3d printed parallel gripper that has finger sensors and a distance sensor in the palm for homing in on items. I used this idea in an earlier robot run from a mega, it could find empty drink cans and collect them with a gripper and deposit them in a bin.

The body lift will also carry a kinect 360 for object recognition.

The entire robot is constructed from readily available materials.

Currently the robot can make a map of the environment by itself, then it can be commanded to go to particular locations. Those locations can be assigned by the user through a GUI. We are still trying to resolve an issue with rotate recovery, it does not restrict itself to the rotation speeds we have set, instead spinning at about 4 radians a second which is completely useless as the RPlidar can't update that fast. Looks like it's in the C code for the recovery behaviour.

I just realised I have no photos of the robot, the best I can do at the moment is a screengrab from cad. My copy of the robot is at my workshop. Grab1 shows the arm deployed to pick something up off the floor. Grab2 shows it docked against the body for transport.

I've designed it so eventually there can be 1 arm per side and the body would then get rotated by 90degrees, setting an arm on each side.

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

[Wayne C. Gramlich]

Dave:

Your design reminds me a robot I worked on back around 2010:

https://www.youtube.com/watch?v=UnMxo0pFI7E

Having people work in small groups and share platforms is highly encouraged.
Please show up at an HBRC meeting sometime and show your robot to us.

Regards

-Wayne

>> <https://groups.google.com/d/msgid/hbrobotics/CABbxVHt5zchPSqkhvBRstsFXcXiFKBMQeLFOjCz%2BdfSOz0Q0QA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

[camp .]

Hello Dave,

   Would you please post pictures and whatever you have? My deal is I want a FloorBot; that is a robot too big for the table. My vision is an autonomous tray table; human-assisted delivery. I like the original TurtleBot form factor but feel the drive wheels from the Roomba, and the Botvac are too small for thick carpet and carrying any weight. Was unaware of https://www.gobilda.com/.

 

Thanks!

Camp

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

[Gmail]

That would be great. 

Thomas

-

Want to learn more about ROBOTS?

https://www.youtube.com/user/thomasfromriverside

On Dec 21, 2021, at 9:33 AM, Mark Womack <mwo...@gmail.com> wrote:



--

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-TXgv_mOK7FnnzAYPEPR_JamGjYMWr%3DceHHGXu1uGzWEdsVg%40mail.gmail.com.

[Mark Womack]

I don't know if you all discussed this further at the ROS SIG Zoom last night. Sorry I couldn't make it.  I think that there is some wonderful work from folks, and I learned stuff just browsing around.

By 'reference version' I didn't mean to imply that this would somehow become some official part of the ROS project. I don't know if any of us have that kind of sway. I meant more that this would become a reference for HBRC members (and beyond) to learn from and extend. It would be the mechanics, the electronics, and the programming all in one. :-) But using the latest modern stuff. A big part of the project would be in the documentation of how to get from point A to B: installation, hardware parts, assembly, debugging, operation, programming behavior, etc. It could also be used in future talks, or maybe even in future challenges. (I was pretty excited to find the various challenges associated with the turtlebot.) It might allow a larger group of people to follow along and try new things.  As with any of our projects, when ROS comes out with a new version of ROS2 I'm sure we'll have to spend time 'fixing' it until it works again. That's just par for the course with ROS2.

I guess TurtleBot does meet my definition of the 'reference version'. And I don't know if one could build a ROS robot with all the bells and whistles for less than the cost of a TurtleBot3. But I would submit that HBRC isn't about just buying an entire fully assembled robot off the shelf (though if you want to do that to focus on what you want to learn, like just the programming part, that's fine too!). It's about learning about robots by doing. I think having HBRC with its own 'reference' robot would foster more of this. It's just a gut feeling though. It may turn out that the hurdles are still pretty high.

So, given that there are already some interesting starting points, different ideas of what components would matter, and a plethora of components that could be included, I'd like to suggest a more modest goal to start: A reference version for a generalizable differential drive robot. This would be an implementation that could be used across a number of mechanical platforms so long as they use a differential drive. Customize it to the circumference of your wheels, the number of quadrature signals per rotation, the location of the wheels, distance between the wheels, and whatever else makes sense...and it will work with your mechanical platform to move the robot as expected. It could be demonstrated using the simple Pololu Romi design, but anyone in HRBC and beyond could use it as a starting point for their own robots. And we would validate its generalizability by using it on our own robots, making sure it does what it advertises. :-)

I say this is a modest goal, but just doing the locomotion for the robots will require a lot of work: Some computer to run ROS2, some microcontroller to run the motors?, quadrature counts, communication between the compoents, wifi connection for debugging, etc. I'm sure you guys are already aware, it's the same stuff we had to build from scratch when we built Victoria. It was a huge learning curve, at least for me.  And this is before we get to any kind of useful sensors. That comes later. Maybe as add-on projects. But I feel pretty confident given the amount of knowledge and experience we have that we could build this, and given enough documentation someone else could then use it to build their own robot. Either to spec (from what HRBC designates as the 'reference') or applied to their own custom robot.

Maybe some or all of this has been done before. That's kind of the point.

Interested if you are,

-Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/E41C23A5-9C88-4AE9-A8D7-82258565203B%40gmail.com.

[camp .]

    Okay, I'll bite. I'm not interested in another tabletop robot, but I get it. Folks are limited in space and money, so a tabletop version makes sense. Like other projects from the HBRC, I'd propose a full-size and a miniature version as well as simulated versions of both. I'll even go as far as give them a name "Homer" and "Homer Jr."

 

Wayne, how are you doing odometry on the Romi Chassis?

 

In terms of a starting place, I'm found these packages regarding differential drive:

 

diff_drive_controller

http://wiki.ros.org/diff_drive_controller 

 

eden-desta/ros2_differential_drive

https://github.com/eden-desta/ros2_differential_drive 

 

Please comment if folks have other suggestions regarding a starting place for differential drive.

 

Here would be the starting place for the simulation. Again if folks have suggestions, please comment.

 

URDF and the Robot State Publisher 

https://navigation.ros.org/setup_guides/urdf/setup_urdf.html 

 

    Documentation, yes, but I need a few iterations before documenting. Maybe it's just me, but generally, I build or write about building. I find it better to have something successful to document rather than waste time documenting dead ends. We will discuss this at the weekly ROS Discussion group. Join us if you are interested.

 
Thanks,
Camp

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgsw1OOrycPY7hebS9D%3DfmPVt6kPpA6jon6X-o0DADNr%3Dw%40mail.gmail.com.

[Wayne C. Gramlich]

On 12/23/21 12:55 PM, camp . wrote:
>
>     Okay, I'll bite. I'm not interested in another tabletop robot, but I get it. Folks are limited in space and money, so a tabletop version makes sense. Like other projects from the HBRC, I'd propose a full-size and a miniature version as well as simulated versions of both. I'll even go as far as give them a name "Homer" and "Homer Jr."
>
>
>
> Wayne, how are you doing odometry on the Romi Chassis?

Camp:

The Pololu Romi is both table top and floor (non carpet) capable.

The controller board is https://www.pololu.com/product/3544 .
I'm going to be handing my Romi stuff off to Rohan to play with
over the Christmas break before he runs off to do another semester
at school.

Thanks for the ROS discussion meeting, but I have a standing Tuesday evening
meeting that conflicts.

Regards,

-Wayne

>
>
>
> In terms of a starting place, I'm found these packages regarding differential drive:
>
>
>
> diff_drive_controller
>
> http://wiki.ros.org/diff_drive_controller
>
>
>
> eden-desta/ros2_differential_drive
>
> https://github.com/eden-desta/ros2_differential_drive
>
>
>
> Please comment if folks have other suggestions regarding a starting place for differential drive.
>
>
>
> Here would be the starting place for the simulation. Again if folks have suggestions, please comment.
>
>
>
> URDF and the Robot State Publisher
>
> https://navigation.ros.org/setup_guides/urdf/setup_urdf.html
>
>
>
>     Documentation, yes, but I need a few iterations before documenting. Maybe it's just me, but generally, I build or write about building. I find it better to have something successful to document rather than waste time documenting dead ends. We will discuss this at the weekly ROS Discussion group. Join us if you are interested.
>
> Thanks,
> Camp
>
> On Wednesday, December 22, 2021, 05:49:51 PM EST, Mark Womack <mwo...@gmail.com> wrote:
>
> I don't know if you all discussed this further at the ROS SIG Zoom last night. Sorry I couldn't make it.  I think that there is some wonderful work from folks, and I learned stuff just browsing around.
> By 'reference version' I didn't mean to imply that this would somehow become some official part of the ROS project. I don't know if any of us have that kind of sway. I meant more that this would become a reference for HBRC members (and beyond) to learn from and extend. It would be the mechanics, the electronics, and the programming all in one. :-) But using the latest modern stuff. A big part of the project would be in the documentation of how to get from point A to B: installation, hardware parts, assembly, debugging, operation, programming behavior, etc. It could also be used in future talks, or maybe even in future challenges. (I was pretty excited to find the various challenges associated with the turtlebot.) It might allow a larger group of people to follow along and try new things.  As with any of our projects, when ROS comes out with a new version of ROS2 I'm sure we'll have to spend time 'fixing' it until it works again. That's just par for the course with ROS2.
> I guess TurtleBot does meet my definition of the 'reference version'. And I don't know if one could build a ROS robot with all the bells and whistles for less than the cost of a TurtleBot3. But I would submit that HBRC isn't about just buying an entire fully assembled robot off the shelf (though if you want to do that to focus on what you want to learn, like just the programming part, that's fine too!). It's about learning about robots by doing. I think having HBRC with its own 'reference' robot would foster more of this. It's just a gut feeling though. It may turn out that the hurdles are still pretty high.
> So, given that there are already some interesting starting points, different ideas of what components would matter, and a plethora of components that could be included, I'd like to suggest a more modest goal to start: A reference version for a generalizable differential drive robot. This would be an implementation that could be used across a number of mechanical platforms so long as they use a differential drive. Customize it to the circumference of your wheels, the number of quadrature signals per rotation, the location of the wheels, distance between the wheels, and whatever else makes sense...and it will work with your mechanical platform to move the robot as expected. It could be demonstrated using the simple Pololu Romi design, but anyone in HRBC and beyond could use it as a starting point for their own robots. And we would validate its generalizability by using it on our own robots, making sure it does what it advertises. :-)
> I say this is a modest goal, but just doing the locomotion for the robots will require a lot of work: Some computer to run ROS2, some microcontroller to run the motors?, quadrature counts, communication between the compoents, wifi connection for debugging, etc. I'm sure you guys are already aware, it's the same stuff we had to build from scratch when we built Victoria. It was a huge learning curve, at least for me.  And this is before we get to any kind of useful sensors. That comes later. Maybe as add-on projects. But I feel pretty confident given the amount of knowledge and experience we have that we could build this, and given enough documentation someone else could then use it to build their own robot. Either to spec (from what HRBC designates as the 'reference') or applied to their own custom robot.
> Maybe some or all of this has been done before. That's kind of the point.
> Interested if you are,-Mark
> On Wed, Dec 22, 2021 at 1:34 PM Gmail <thomas...@gmail.com> wrote:
>
> That would be great.
>
>
>
> Thomas

> -Want to learn more about ROBOTS?

[camp .]

> The Pololu Romi is both table top and floor (non carpet) capable.
 

    For "Homer Sr." I'm thinking 5" wheels like this (which include encoders): https://www.dfrobot.com/product-1203.html
And perhaps the Roboclaw 2x15A Motor Controller: https://www.basicmicro.com/RoboClaw-2x15A-Motor-Controller_p_10.html
    I'm thinking to mount the gearmotors on 13" square plywood with rectangular sections cut out near the front and inwards for each wheel and balance it with one rear caster, similar to the bottom base on DFRobot's HCR - Mobile Robot Platform: https://www.dfrobot.com/product-63.html
 
    As for "Homer Jr." a Romi Base plus the Romi 32U4 Arduino/Motor/Encoder Board + RasPi does sound good. Along with Wayne's current documentation* I've found this: http://www.peterklemperer.com/blog/2019/05/02/introducing-romipi-a-ros-package-for-the-pololu-romi/  We're basically looking to ROSify the Romi.
 
    I am still considering the starting place for a differential drive controller, where one could plug in different values for wheel diameter and wheel separation.

 
diff_drive_controller
http://wiki.ros.org/diff_drive_controller
 
eden-desta/ros2_differential_drive
https://github.com/eden-desta/ros2_differential_drive
 

Problems, questions, and comments are welcome.
 
Thanks,
Camp
 

* https://github.com/hbrobotics/hbrc_ros_robot_platform

 

--
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/399b13b6-3221-43ef-a647-cedcf7fb6b7d%40Gramlich.Net.

[Mark Womack]

Camp,

I mentioned Romi because it is a simple frame to work with and Wayne had something already, but the goal would be to use this for any chassis so long as it is a differential drive. We should have a larger, different chassis as part of the reference to prove the point. Maybe Dave's robot that he mentioned. Or maybe a botvac.  It looks like you are on track with this with Homer Sr and Homer Jr! Not sure where the name Homer came from, but I am on board! Maybe we should name them Homer and Bart.

It might mean we don't use the Romi microcontroller. Maybe it is a hodgepodge of a microcontroller with a motor controller connected to a Raspberry Pi. Something like that, the hardware would be able to scale from small to large. Or maybe the code itself scales across microcontrollers. I don't know, I'm just spitballing. As long as the code can work, with proper customizations, then it provides a reference, and hopefully enough context to make changes if desired for a specific non-Homer application.

For Victoria we used a Teensy 3.5 for the microcontroller connected to the microcomputer via USB serial and communicating back and forth via rosserial_arduino.  We didn't use a Pi, we used an UpBoard (I don't remember the model), but the thinking was that we were going to eventually need more processing than the Pi could provide. Maybe that has changed now.  I'm not saying all this to make any platform decisions, just that there are options we can consider. There is a Teensy 4.1 that is even more incredible than the 3.5. I'd love to hear how others have integrated a microcontroller, motor board, and microcomputer for ROS2. I would like to take a closer look at Wayne's HR2.

As for documentation, yes, I agree we should document the final (current) product, not all of the options we considered or the directions we followed. That kind of stuff can be in a document specifically for that purpose if we want it. Sometimes it is useful to know what was considered and what was tried. But in a document specifically for that. But it can be confusing to have a discussion of the pros and cons of which microcontroller to use, as an example, when you are trying to figure out what you need to install for the arduino dev environment.

I'm sure we can pick this up again after the holidays. But I am really excited about working on this in the new year!

Happy Holidays!

-Mark

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/1505894410.1819195.1640313359610%40mail.yahoo.com.

[camp .]

> Maybe we should name them Homer and Bart.

 

Doh! I like it!

 

    As much as I prefer to do things physically perhaps Gazebo is the best place to start. "sam_bot" is the model they use in ROS2. Perhaps we play around with it and modify it to get started. One thing... and I've already made a big deal out of this some time ago, I think the castor wheel should be in the rear.  ;- )

 

Setting Up The URDF
https://navigation.ros.org/setup_guides/urdf/setup_urdf.html
 

Thanks,

Camp

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgsaQ%3Di8HkE_JS%3DwR5jaWqaUQqgfeuzPZH%2BS9bhnFkhnFA%40mail.gmail.com.

[Mark Womack]

    As much as I prefer to do things physically perhaps Gazebo is the best place to start. "sam_bot" is the model they use in ROS2. Perhaps we play around with it and modify it to get started. One thing... and I've already made a big deal out of this some time ago, I think the castor wheel should be in the rear.  ;- )

Agree on Gazebo. I was going to mention that having a Gazebo model to simulate should also be required for both Homer and Bart references.

I don't have a strong opinion on the castor position but I can see where a real castor would be more ideal. One design decision made without even trying! :-)

 

Setting Up The URDF
https://navigation.ros.org/setup_guides/urdf/setup_urdf.html
 

This looks very promising. A cursory first pass seems to suggest that it does require actual physical measurements. I'm pretty sure the Romi measurements are online, and Wayne might already have something Gazebo ready. You can make decisions about Homer based on the parts and dimensions you were suggesting, and we can finalize it later, if needed or if we change something.

While we are on this subject, what is the version of ROS2 that all the cool kids are using nowadays? I'll have to install it.

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

[Alan Federman]

I think the old Loki code still exists somewhere on the Ubiquity Robotics GitHub. This was a RPi 2/3 + Arduino + ROS 1 robot that was fairly advanced for it's time. I will have to check if the code is still there. The chassis was the Arduino carrier board, so it was similar in some respects to the old Arduino based DF table bot.

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

[Ralph Gnauck]

The sim_bot repo I just published a month ago has ROS2 (galactic) with simulation and navigation2.

https://github.com/gnaur/simbot

Its there for people to use - just swap out the base driver launch and you have a ROS2 robot.

(ok need to update the URDF dimensions etc) but this should be a good starting point for a ROS 2 robot.

Ralph Gnauck

https://groups.google.com/d/msgid/hbrobotics/767839010.263585.1640383294389%40connect.xfinity.com

.

[Steve " 'dillo" Okay]

On Wednesday, December 22, 2021 at 2:49:52 PM UTC-8 mwo...@gmail.com wrote:

I don't know if you all discussed this further at the ROS SIG Zoom last night. Sorry I couldn't make it.  I think that there is some wonderful work from folks, and I learned stuff just browsing around.

By 'reference version' I didn't mean to imply that this would somehow become some official part of the ROS project. I don't know if any of us have that kind of sway. I meant more that this would become a reference for HBRC members (and beyond) to learn from and extend. It would be the mechanics, the electronics, and the programming all in one. :-) But using the latest modern stuff. A big part of the project would be in the documentation of how to get from point A to B: installation, hardware parts, assembly, debugging, operation, programming behavior, etc. It could also be used in future talks, or maybe even in future challenges. (I was pretty excited to find the various challenges associated with the turtlebot.) It might allow a larger group of people to follow along and try new things.  As with any of our projects, when ROS comes out with a new version of ROS2 I'm sure we'll have to spend time 'fixing' it until it works again. That's just par for the course with ROS2.

A "Turtlebot 4" was announced at ROSWorld in October w/ a planned release date sometime next spring, based on the iRobot Create2(or is it 3 now ?)

So that's the "Official" ROS2 "Reference Robot" I think.

There's nothing stopping any of us from making our own or making a design that people could riff off of.

Lately, I've been thinking about building something like this little crawler that NASA is working on:
https://www.jpl.nasa.gov/news/a-cadre-of-mini-rovers-navigate-the-lunar-terrain-of-slope

I like the "cradle" style articulated frame and it seems like it should be all that hard to build.

Anybody else interested ?

'dillo

[Michael Wimble]

Galactic, Ubuntu 20.04 until next spring

[Jack Buffington]

For what it is worth, I have a robot that I am currently working on that I am open-sourcing and producing (the world's most boring) videos about the build process.  It is pretty similar to the turtlebot at the moment where it has differential drive and a lidar on top.   I have it to the point at the moment where it is mechanically and electronically complete.  I also have it so that it has ROS2 nodes for talking with the MCU, teleoperation, the RPlidar module, and to view the lidar scans (because I don't seem to have rviz on my computer for some reason)   If anyone is interested, I have everything except for the rplidar and visualization nodes on gitlab and have all of it documented between Google Drive and Gitlab.   I'll get the other stuff documented soon but have to take a two week detour to work on something else right now.   Once I have that documented and uploaded, it will basically be ready for anyone to build on their own and write whatever higher-level software that they want.  You can find the main project page at: http://www.robotbrigade.com/mappingRobot.php   That page has links to the github repository, the videos, and my Google Drive documents.

[Chris Albertson]

Basic questions:

1. What would it cost for a person to build, if they had to buy all new materials?
2. What is the structure made from?  Must the build know how to work with metal or is a 3D printer required?

I'm also doing this with a "dog bot" I started with the Spot Micro design but I'm finding mechanical design features that can be better.   To answer my own questions (1) under $500 and (2) this is an advanced 3D printing project.

--

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/b3a5bbd8-d505-4ecb-b647-e175d2593e2dn%40googlegroups.com.

[camp .]

> You can find the main project page at: http://www.robotbrigade.com/mappingRobot.php 

 

    Good stuff, Jack! Good to hear from you, seasons greetings and all that! Join our ROS Discussion Group on Tuesdays if you can make it. I post the link on the mailing list.

 
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

https://groups.google.com/d/msgid/hbrobotics/b3a5bbd8-d505-4ecb-b647-e175d2593e2dn%40googlegroups.com

.

[Jack Buffington]

My costs aren't super low even though that was a goal of mine.   Right now it is coming in at about $770.   Quite a lot of the cost is eaten up by the RPlidar module.   The structure is made out of acrylic sheets and standoffs so anyone who has a way to cut acrylic using a laser (As I did) or with hand tools could make it.  I kept that dead simple because I didn't want to spend much time on it.   I have a complete bill of materials in a Google sheet, which you can find from the project page:  http://www.robotbrigade.com/mappingRobot.php

[Scott Monaghan]

Hi All,

I'm working on a similar project right now called Ro-Bud, but I don't currently use ROS. That said, the design is based on ROS design principles: nodes publishing/subscribing messages, but instead of having the overhead of ROS I use Linux systemd services running python and Mosquitto MQTT messaging. I say that because it would be a fairly horizontal operation to port to ROS or ROS2.

I also have a goal of keeping costs low and I'm at just about $500, but a big part of that is trying to build it without a traditional LiDar module.

Here are the details if anyone is interested. If anyone is interested in contributing the project, or branching and using it to jumpstart something else, that'd be totally awesome.

Here's the project: https://github.com/ScottMonaghan/robud

Scott Monaghan

413.244.9344

scott.m...@gmail.com

www.linkedin.com/in/scott-monaghan

Resume: https://tinyurl.com/yxhq5eul

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/cbb37a0d-8213-4ce1-ba32-876f56805333n%40googlegroups.com.

[camp .]

This is awesome, Scott! Extremely well done. 

 

- Camp

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHtKdjZVM7yLkBmkv9w26_PRVboJ6HbBTzX%3DuT%2BSXg5-Jw%40mail.gmail.com.

[Mark Womack]

All,

Thank you for all of the pointers, input, suggestions, ideas, etc. It is just great to see what awesome projects are out there. I'm going to start taking some detailed looks!

While we are still hashing out ideas, I took the opportunity to gather up some of the goals and guidelines that I think we have agreed on. These are still open to discussion and refinement, and you are welcome to comment.

https://docs.google.com/document/d/1gFfrrMrZ4ZPJ-SRzuViX5B-59AWDK95AomR9_E8CAbE/edit?usp=sharing

This document doesn't discuss any detailed design except to say the robots will be differential drive, similar to each other except in size, and will use ROS2.

This is a Google Doc, but ideally would be a markdown document in git. I'll convert it if and when we create a git repository for the project. I'm not sure we are at that point yet.

-Mark

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

[Chris Albertson]

The default reference robot is Turtlebot.  It does exactly everything in the attached Goals document   It is not surprising because the intent of Turtle bot was to make a low cost, open source reference design.     The turtlebot 3 uses a 3d printable chassis system based on plates that screw together so you can make it larger later, by printing more plates.  I think this idea is unique.  Just add more tiles and make the robot wider,  add more "floors" and make it taller.   The taller part is an old idea, the wider part is a new idea.

Because it was designed to be a reference, it uses only"standard", easy to find parts and is very conventional.   One big advantage of Turtlebot is that all the ROS examples work "out of the box" because they were written for this robot.  The only objection to Turtlebot is the "high" price. But this is a well documented open source robot and you can build one yourself.

I would recommend against designing "yet another reference".   If you can afford $599, buy one that works out of the box but you can also buy the parts and assemble one and save $100 or $200.

The design scales.   The smallest one does SLAM navigation indoors and the larger one is big enough to become the base of a service robot that has manipulators (arms and hands) and enough power to move some weight.  You can convert a small turtle to a large turtle by swapping a few 3D printed parts.  It is a modular design

If some one wanted to design something I'd design an "ultra-low-cost" motor for the smaller Turtlebot that is a direct screwdriver-only replacement.   There is a potential to reduce the price by almost $200.     A couple cheap gear motors from China, a raspberry Pi Pico and a small h-bridge and some 3D printed parts.  But keep the screw mounting points in the same places so it really is a drop-in replacement.      Such a drop-in replacement would have wide popularity, not just for this robot.

Again if you go this route, you get what you want and with almost zero effort but most importantly the software "just works" with no configuration and someone else keeps it working for you.   Turtlebot is an open source design make for exactly your purpose and you have the option of building it DIY, printing the part and all or just buying a working robot.  It is currently the most popular and lowest cost robot that can run ROS and lidar-based SLAM out of the box.   Being "the most popular" means there is support available, thousands of people already own Turtlebots.    Of course Turtlebot runs in Gasabo  and there are iPhone and Andriod apps for remote control.  You can have a entry-level Turtle for about $400 if you shop around for parts.

Here is a good description of it.

https://www.robotis.us/turtlebot-3/

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

[camp .]

    The current Turtlebot is a tabletop robot. Great for learning (inexpensive, etc) but not capable of carrying weight. I like the original Turtlebot form factor which will be making a comeback as the Turtlebot4 from ClearPath using iRobots new Create3 but I've had it with 3" wheels on thick carpet. I'm under the impression something with 5" diameter wheels more along the lines of DFRobot's HCR (Home Care Robot) https://www.dfrobot.com/product-361.html is the way to go.

 

    Mark made a suggestion and I'm along for the ride. Among other things, we're talking about exploring simulation which I know a lot of us are very familiar with but I for one have had a hard time with it. To that end, I've revisited the Gazebo tutorials and can say this is a good place to start in simulation: http://gazebosim.org/tutorials?cat=guided_b&tut=guided_b3

I'm currently looking at: https://navigation.ros.org/setup_guides/urdf/setup_urdf.html and am considering the bridge from URDF to SDF and am thinking Sketchup is the place the start... I say this to point out that people have to find their own paths to understanding and while we'll consider the "TurtleBot3" in the same way we'll consider "Pololu Romi" and rolling our own for Bart.

 

    We're looking to explore design (differential drive specifically) in small form factor, large form factor, and simulation... and we are after all the "homebrew" club.

 

Thanks,

Camp

Setting Up The URDF — Navigation 2 1.0.0 documentation 

Setting Up The URDF — Navigation 2 1.0.0 documentation

 
Thanks,
Camp

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

[camp .]

    I am finding this (what appears to be) TurtleBot3 Waffle with ~5" wheels but I can't see the wheels for sale anywhere on the Robotis website. I assume they are being driven by a Dynamixel servo... maybe not.

 

TurtleBot3 Delivery Service Demo @ICRA2017 (2)

https://www.youtube.com/watch?v=u7qb8xiSiNg

 

Thanks,

Camp

https://groups.google.com/d/msgid/hbrobotics/1780225262.2733298.1640717442822%40mail.yahoo.com

.

[Chris Albertson]

Turtlebot can be buit small enough to run on a table.  But it is modular.  The wheels can be swapped out for tank-tracks.  You can print the tracks.

Here is a video

https://youtu.be/vndnwpVEpVE?t=63

You can also make Turbot large enough to be a stable platform for a manipulator.  Here is a larger Turtlebot, but fitted only with two "indoor wheels" that is running autonomously.  it is programmed to follow a line and use the arm to remove obstacles from its path.  

https://youtu.be/1q3-PFhm9Ks?t=252

Yes, it is dead-slow.   Raspberry Pi is not a fast computer and it is doing autonomous operation.

These 'bots can be configured as simple two-wheel differential drive, with the smallest examples being able to fit on a table top but also it can have four motors and be 18 inches wide with tank tracks.     It depends on how much money you have.  Most people go cheap and build a tiny version with no Lidar.

So I can imagine a new builder trying first a small table top robot with noLidar and just remote control.  Then he adds a LIDAR and places it on the floor.   Then buys more motosand the makes som tank tracks.    Then decides to print more chassis tiles and makes the robot wider for a stable base an adds an arm on tank tracks to pick up trash in a park.  It is still the same robot as the table top version.

Here is a short video of some small size versions and how they are all built from the same plan

https://youtu.be/r3oNIWex8a0

I think what is lacking is not the high-end as they sell some monster-size motors and you can buy four of them and build a very capable outdoor rover but what is missing is a way-cheap motor for us ONLY on the table for testing or for a beginner who is not able to commit to $400.    For that what is needed is a cheap gear motor n a 3D printed mount that fits the Turtle screw hole locations.   These work on hard surfaces well and are way-cheap.  

https://www.pololu.com/product/1523

Good larger size robot wheels are harder to find.    You find them up to about 120mm but then you are neededing to kid's bicycle wheels or something.   I designed a 3D printable wheel. that is at the lit of my printer's build plate.  about 8 inches with a TPU tire.     I find the hard part is the hub.   Plastic hubs have a life time measured in minutes.   I make steel hubs now and glue them to the plastic.   THese wheels use hubs made from a drilled out steel bolt with hex head.  They are about 200mm diameter

https://a360.co/3eBxMbq

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

[Chris Albertson]

Print your own wheels.   There really is no better way.  

The key to designing wheels is to understand that all the stress is at the hub and the rim has the least stress.      3D plastic is just not strong enough to hold on to a 6mm diameter shaft, let alone a 4mm shaft.

So one solution is to buy smaller wheels and print bigger wheels that fit over the small ones.     That works but now I make a 20mm diameter metal cylinder that fits the motor shaft and make the wheel with a 20mm hole in the center and use epoxy to put the two together.

A quick way to make a hub is to buy a 1/3 inch steel bolt at Home Depot cut it shorter and drill a 4mm hole down the center of the bolt.   Pres it into a hex-shape hole in the printed wheel.   I have machine tools to make better hubs but it can be done with hand tools and 3d printed jig to keep the drill aligned with the bolt.   

Print a block of plastic with a hole in it to hold a 3/4 bolt, screw the bolt into the plastic.   Use the plastic block to guide the hack saw.  Then to drill the holes for the motor and the set screws you have guide holes in the plastic.  You can't miss, even with a hand drill.  You push the hand tools through slots and holes in the plastic block.  You get good-enough precision results with no skill required.     I have a lathe and can do better but it is not required.

Actually I don't need many wheels.   I use this technique mostly for gears and timing pulleys.  I use steel hubs because the set screws hold really well in steel.  Soft steel is easy to thread with a hand tap.

3D printed wheel, even with cheap $16/spool PLA can be strong enough to hold 100+ pounds.   So print them light with 15% infill and .8  mm walls and save some time and money.

I think it should be possible to make 14 inch wheels that print 1/4 wheel at a time.    The four parts would have alignment tabs and you would use epoxy or CA glue.

I'd be happy to work with someone who needs big printable wheels but lacks skill with CAD.

Here is the link again to the last ones I designed https://myhub.autodesk360.com/ue29746f2/g/shares/SH35dfcQT936092f0e43efe8747a7be650cc

There depend on hubs that require a 4-axis milling machine and lath to make.  Most people would prefer something different.

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

[Chris Albertson]

Robotis publishes the CAD files for Turtlebot and all the parts.    You can buy a Turtle bot or print one.   Here is the design file for that standard wheel. 

https://cad.onshape.com/documents/2586c4659ef3e7078e91168b/w/14abf4cb615429a14a2732cc/e/37073aa11e41f9a3e9945210

It would not be total rocket science to modify the standard  wheel to a larger diameter then print it.   You could do this up to the size of your printer.     Plastic costs two cents per gram and a bigger 5" or 6" wheel would be about 100g or $2 each.  and take about 6 or 8 hours to print.

But note as in my other email, printed hubs take a beating and have a short life.   I've gone to using steel

if you don't want to use steel, you could make a 6" plastic disk and then use the CAD file of the standard wheel to "subtract" the shape of the standard wheel from the disk.   Print it and then you have a 6" disk that will snap over top of the standard wheel.  like a really tall tire.

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

[camp .]

I know I've mentioned this before, but the gearmotor/wheel combination I'm eyeing is this: https://www.dfrobot.com/product-1203.html 

 

I am not 3D printing yet, but it is on the list. My thoughts on the chassis are 1/4" plywood cut similar to the DFRobot base: https://www.dfrobot.com/product-361.html plus a 2" caster wheel. I'm intrigued by the idea of driving the above gearmotor/wheel with the Roboclaw 2x15A motor controller and its encoding input.

 

Please post if others are aware of good FloorBot-sized gearmotor/wheel combinations or motor controllers.

 

Thanks,

Camp

On Tuesday, December 28, 2021, 05:15:10 PM EST, Chris Albertson <alberts...@gmail.com> wrote:

Robotis publishes the CAD files for Turtlebot and all the parts.    You can buy a Turtle bot or print one.   Here is the design file for that standard wheel. 

https://cad.onshape.com/documents/2586c4659ef3e7078e91168b/w/14abf4cb615429a14a2732cc/e/37073aa11e41f9a3e9945210

It would not be total rocket science to modify the standard  wheel to a larger diameter then print it.   You could do this up to the size of your printer.     Plastic costs two cents per gram and a bigger 5" or 6" wheel would be about 100g or $2 each.  and take about 6 or 8 hours to print.

But note as in my other email, printed hubs take a beating and have a short life.   I've gone to using steel

if you don't want to use steel, you could make a 6" plastic disk and then use the CAD file of the standard wheel to "subtract" the shape of the standard wheel from the disk.   Print it and then you have a 6" disk that will snap over top of the standard wheel.  like a really tall tire.

On Tue, Dec 28, 2021 at 12:05 PM camp . <ca...@camppeavy.com> wrote:

    I am finding this (what appears to be) TurtleBot3 Waffle with ~5" wheels but I can't see the wheels for sale anywhere on the Robotis website. I assume they are being driven by a Dynamixel servo... maybe not.

 

TurtleBot3 Delivery Service Demo @ICRA2017 (2)

TurtleBot3 Delivery Service Demo @ICRA2017 (2)

TurtleBot3 Delivery Service Demo @ICRA2017 (2)

 

Thanks,

Camp

On Tuesday, December 28, 2021, 01:52:19 PM EST, camp . <ca...@camppeavy.com> wrote:

    The current Turtlebot is a tabletop robot. Great for learning (inexpensive, etc) but not capable of carrying weight. I like the original Turtlebot form factor which will be making a comeback as the Turtlebot4 from ClearPath using iRobots new Create3 but I've had it with 3" wheels on thick carpet. I'm under the impression something with 5" diameter wheels more along the lines of DFRobot's HCR (Home Care Robot) HCR(Home Care Robot) - Mobile Robot Platform with Sensors and Microcontroller-DFRobot is the way to go.

HCR(Home Care Robot) - Mobile Robot Platform with Sensors and Microcontr... DFRobot HCR(Home Care Robot) - Mobile Robot Platform with Sensors and Microcontroller is a two wheel drive mobil...

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHtg%2BKiMBfjr28%2BP-sexYGxXVEsS7Zxi3itaDaG4gJfvgg%40mail.gmail.com.

[Chris Albertson]

First off, buy a printer.  No need to spend a lot.  Keep it under $200.

If you learn how to press ball bearing units and brass thread inserts into the plastic, then you can make strong and durable machine parts that can have smooth, round organic shapes.

Those wheels by DF Robots look really good.  However I've found that differential drive only works well on hardwood floors for anything else, including carpet you need four wheel drive.   The transition wood to carpet or worse a collision with a shoe left on the floor (that is too low to be detected with the sensors) will tip the robot over on its face.  So ALL FOUR wheels need to be big, not just the drive wheels and it they are not all powered or a small object can halt the robot and the sudden stop will tip it over.   Get four of the largest wheels you can find.    Mass scales with the cube of the dimension and power requires scales with mass.  If the robot is twice a big it needs 8X more power so four drive motors is not unreasonable.

I have four of these motors and have used them on a 4 wheel drive platform that was maybe 16 inches square.   I used wheels from 1/8th scale R/C trucks.   the R/C truck tires canbe very high quality as people actually race their truck competivly.    Maybe 5 inch diameter with agressive treads.   

Problems:    (1) Big wheels place bending loads on motor shafts  On a small robot, just stick the wheels on the motor shafts and let the bearing that ar builtinto the motor take the load.   Thi si not good with a heavier 'bot as you can bend the motor shafts with big 8" wheels.   You need metal axels with bearings to take the s=weight and then flexible shaft couplers to  attach the mother to the shafts.   Doing all this with wood and hand tools is not easy .   A printer of CNC allows you to work in precise tolerences.

These and all other 36D ger moters have weak gear boxes that use spur gears.   The gearboxes are LOUD and are the weak link in the drive train.    Small gear moters really need to be the input to a belt reduction system.   This lets the gears run fast where they ca have more power and reduces the noise.   With direct to wheel drive yu break even the later 36D motors

Read Pololu's specs.  The large reduction motors are spec's for no more torque than the motors with less reduction.   The limit is the gear teeth.   So you do the last 61 or 101 with belts oe external printed gears.   Or try stepper motoers.  Steppers have maximum torque at zero RPM  But steppers are battery-hogs.

One other big-robot idea that is stalled at the moment.  A fisher-Price ride-on kiddie car.   These cars are large enough that two small children can ride inside the car  They are easy to find for $300 or even less,     I have one.  It moves with a 155 pound adult on it.  Here is a big hint --  Amazon sells repair parts for these cars.  A wheel with attached more is $50 or so.   They are noisy and cheaply made.  But the payload weight   Two of these units powers the car on a sidewalk or driveway at a normal walking pace with a 60 pound payload https://www.amazon.com/30000RPM-Gearbox-Electric-Motorcycles-Childrens/dp/B076Q3XTWB/ref=asc_df_B076Q3XTWB/?tag=hyprod-20&linkCode=df0&hvadid=312132431235&hvpos=&hvnetw=g&hvrand=1254917015880040983&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9031026&hvtargid=pla-624333849727&psc=1    I was lucky to get them free.

My solution?  Walking.    It will take a couple months for "first steps

Reduction?  Yes.  Big wheels need loads of torque and low RPM. 

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

[Chris Albertson]

Sorry I forget the best link.  If you want a really big robot, buy this as a base.  Notice it rated for 80 pounds of weight inside.   The body can be removed and replaced with a plywood top if you don't like the style.

https://www.hammacher.com/product/childs-electric-4x4-truck-ride-on?cm_cat=ProductSEM&cm_pla=AdWordsPLA&source=PRODSEM&utm_source=google&utm_medium=organic&utm_campaign=surfaces-across-google&utm_source=google&utm_medium=organic&utm_campaign=surfaces-across-google&gclid=CjwKCAiAiKuOBhBQEiwAId_sK0ey8Kj06tEhVYZs92hZXXn_RhsApystnsDm11SuQYS1XxIJQKNjyBoCm2gQAvD_BwE

[camp .]

> ...and am thinking Sketchup is the place the start...

 

Make that FreeCAD... I basically want to create a mesh file for the URDF.

 

- Camp

On Tuesday, December 28, 2021, 01:52:19 PM EST, camp . <ca...@camppeavy.com> wrote:

https://groups.google.com/d/msgid/hbrobotics/1780225262.2733298.1640717442822%40mail.yahoo.com

.

[Mark Womack]

I get it.  TurtleBot is the official reference.  We certainly don't want to replace it, or maybe even compete with it.  But I don't want to build a robot out of a kit with everything predetermined and pre-chosen. Even if it is super well designed, covers all the bases, and I can 3D print all the pieces. I want to learn by doing for myself. There's a limit to how much I want to do from scratch. I don't want to create my own motor controller. But I do want to put components together and understand how they play together with ROS in the mix. Maybe it means reusing large portions of the TurtleBot code, but understanding how it gets customized for the robot being built. Maybe it means writing some amount of new ROS code. Maybe it means at the end of the day I throw up my hands and buy a TurtleBot. I don't know yet. I guess that is more my point than it being an "official" reference or a competing reference. And someone else may look at it and decide that they don't want a robot out of "my" kit, but want to run off and do their own thing. If so, ok, maybe they learn something from the design or code. If anything this thread has shown there are a lot more robots out there.

I floated the idea of an "HBRC Reference" because I wanted to see if there were other like minded folks out there that might like to work on a robot as a group. Something that could be shared amongst the club, something that would be like a "reference". I know it might be crazy, but I would prefer to work on a robotics project as part of a team, not in solitary.  I'm way out in New York, so it's going to be a challenge at any rate. When I worked with Gris and Michael on our RoboMagellan I had a blast. And our robot didn't complete the course, but so what. I learned a lot and I enjoyed working with them, even if I had to drive out to Neato every weekend for two months. And I'm glad that Camp has jumped in with some enthusiasm, insights and ideas, and I look forward to working with him. But if it's just the two of us, I don't know if it will have enough momentum as an "HBRC" thing. Maybe it's just something we work on together.

At any rate, I'm going down this road some more. If anyone else wants to join in, you are welcome. At the very least I have updated my document replacing "Reference Robot" with "Example Robot" so there is much less confusion. If it turns out to not be an "HBRC thing", then I will update it further.

-Mark

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

[Dave Everett]

On Wed, 29 Dec 2021 at 10:01, camp . <ca...@camppeavy.com> wrote:

I know I've mentioned this before, but the gearmotor/wheel combination I'm eyeing is this: https://www.dfrobot.com/product-1203.html 

 

These are the wheels and hubs I have used on my club robot. However I found the motors underpowered for a robot that will carry any weight. This is because the gear ratio is wrong. Running faster than 40cm/sec is suicidal and these could run at more than double that. If they had a further halving of the RPM, it would be perfect for a home robot and have double the torque. In my experience, your robot spends more time at low speed negotiating around obstacles than travelling at full velocity. The motors I now use come from GoBilda. They are not perfect either , but they better fit the profile I needed.

I read the post about the wafflebot this morning and it was troubling me.This is a poor choice for a "reference robot" in my opinion. If it all works out of the box I don't see much use in the homebrew community. If the software is already tuned it would need a very thorough description of how that was done in order to be useful for expansion. I also see the waffle as an end product rather than the base to expand upon. Couple that with the poor documentation in ROS and you have a recipe for endless hours trying to troubleshoot the simplest of things.

When I set out on the current robot there were specific criteria.

1. sized to negotiate an average home, run over small obstacles and not shake about too much (no good carrying a drink if the glass is empty at the destination).

2. tricycle layout with differential drive. I have made robots with many different drive systems. This setup places the least stress on the robot, the surface it runs on and the odometric system.

3. an arm capable of manipulating many objects, with a quality gripper including inbuilt sensors.

4. a way to have the gripper reach the floor and up to at least a900mm tabletop.

5. Vision system with at least limited object recognition.

I also knew I did not have all the answers at the beginning so compromises had to be made to get going. But I designed based on a goal. The goal being a robot that can get an item from location A and take it to location B. That is about 90% of a home robot's job right there.

And to stress the point, without a goal, you are assembling sticks in the wind. I feel you must have clear goals or milestones to know you are making progress.

I had a look at the Turtle 3 video, again it seems a bit too small to be practical for further useful development, but I will look into the base in more detail over the next week or 2.

Dave

Virus-free. www.avg.com

[camp .]

> But if it's just the two of us, I don't know if it will have enough momentum as an "HBRC" thing.

 

    It's already an HBRC thing. As long as we have fun and learn, who cares? We've already got input from at least a half-dozen experienced robot-builders. Google Docs rocks, and the "HBRC Example Robot Goals & Guidelines" is just right. I've done some research that would not have been done otherwise because of this initiative and am looking forward to what others have to say this evening.

 

Thanks,

Camp

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

[Dave Everett]

On Wed, 29 Dec 2021 at 12:44, Mark Womack <mwo...@gmail.com> wrote:

I floated the idea of an "HBRC Reference" because I wanted to see if there were other like minded folks out there that might like to work on a robot as a group. Something that could be shared amongst the club, something that would be like a "reference". I know it might be crazy, but I would prefer to work on a robotics project as part of a team, not in solitary.

I'm up for that too Mark. I have long believed that what we need is a critical mass of development on the same platform. Of course I also realise that there will be many voices wanting different things from the project.

I had 2 projects going, the DMAbot, which is the home robot capable of doing something useful, and a desktop robot that could be lasercut and had some kind of arm and gripper (pictured). I never seem to have tome to work on them for long enough though , so working as part of a group always appeals to me.

Dave

Virus-free. www.avg.com

[Dave Everett]

Hi Camp,I might be crap at finding things, could you please post a link to that document?

And it turns out the ROS zoom is in about 30 minutes so I hope to be there.

Thanks,

Dave

Virus-free. www.avg.com

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

Virus-free. www.avg.com

[camp .]

> I had 2 projects going, the DMAbot, which is the home robot capable of doing something useful, and a desktop robot that could be lasercut and had some kind of arm and gripper (pictured).

 

    That's a good-looking robot, Dave! What does "DMA" stand for? And when you get a chance if you would post the gearmotor/hub/wheel combination you are using from goBILDA that would be great!  :- )

 

- 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

https://groups.google.com/d/msgid/hbrobotics/CAG61pbd_EK4Mu3h6ssZ0S%2BKADMzOQor2nz7jmgALWWQ0gvBMxQ%40mail.gmail.com

.

[Dave Everett]

It stands for Dave Mark Anthony :) The 3 of us working on it.

I use the DFrobot wheels and hubs:

https://www.dfrobot.com/product-1006.html

And from GoBilda, the 53:1 spur gear motors:

https://www.gobilda.com/5201-series-53-1-ratio-105-rpm-spur-gear-motor-w-encoder/

It's possible they don't do the spur gear motors anymore. I prefer them only because they are quieter. But they should have an equivalent in planetary.

Dave

Virus-free. www.avg.com

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

[Dave Everett]

Looking at the planetary motors, this one looks about right:

https://www.gobilda.com/5202-series-yellow-jacket-planetary-gear-motor-99-5-1-ratio-60-rpm-3-3-5v-encoder/

It would give a top speed of about 40cm/sec with the DF robot wheels and 132lg-cm torque, good for ramps.

I recall I did not change to these yet as I would have had to rebuild the base wider.

Dave

Virus-free. www.avg.com

[camp .]

> Hi Camp,I might be crap at finding things, could you please post a link to that document?

 

HBRC Example Robot Goals & Guidelines

https://docs.google.com/document/d/1gFfrrMrZ4ZPJ-SRzuViX5B-59AWDK95AomR9_E8CAbE/edit?usp=sharing

 

- Camp

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

[Dave Everett]

Thanks mate. Is this on a google drive for the HBRC? I had only found the github pages which did not include this document.

Happy to help where I can.

Dave

Virus-free. www.avg.com

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

[camp .]

Yes, we're just starting and Mark put this up as a starting place.

 

- Camp

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

[Steve " 'dillo" Okay]

Back when I first got my 3D-printer in 2017, I started printing myself a complete Turtlebot3, including the wheels.

I got as far as printing the hubs in PETG and tires in NinjaFlex. Then I went off to ROSCON and won a Turtlebot3 "Burger" in the ROBOTIS "drop your card in the fishbowl" raffle and that was kind of the end of that project :)

I converted the "Burger" into a "Waffle" model because by that time I had printed enough "Waffle plates" to do the conversion. I gave the rest of them away at an HBRC meeting not long after that.

I think the point of the Turtlebot3 was that your could completely print yourself one(minus the Dynamixel servos and electronics) and make a modular robot that could be used for different roles.

I seem to recall it took about 7 or so hours to print each "waffle plate" because all the holes in the plates result in a lot of retractions and travel moves.

The T3 "Waffle" model uses 24 plates. That's a week solid of non-stop, back-to-back printing for just the plates, probably more like a month from a practical perspective.

So, that's my thoughts about printing vs. buying.

'dillo

[Scott Monaghan]

For the waffle plates can you cut them from acrylic or wood using a laser cutter?

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/c36473bb-5397-4266-be00-9f53ec236c77n%40googlegroups.com.

--

[Chris Albertson]

The problem with laser cutting the waffle blocks is the blocks overlap horizontally at the places where the screws fit.  I think if you wanted to mass-produce 200 of  them for a club Injection molding is cheaper.

But do you really need these?  This is why I call Turtlebot a "reference".  Why would you print an exact copy of a waffle plate?  If you are building a specific robot you do not need the multi-use general purpose lego-block part.   Print or cut a block that is the same shape and has only the holes you need to use.    They supply the CAD files so you can simplify the part and make it easier to manufacture.  Why screw together small blocks?   Print or cut them in one piece in the assembled size.   Just keep the screw-hole locations the same.   So YES, laser cut the final assemble plate but do not laser-cut a dozen small plates.

They sell spare waffle blocks for $17 per set of two.   This is expensive but the company is US based and needs to pay a middle class income to it's employees here in California.  They offer the CAD files so you can modify the design to fit you needs.   So the link below.

https://cad.onshape.com/documents/2586c4659ef3....

The robot is open sourced so you can modify it to suit your needs. 

The waffle block is a lego set for robots but if what you want is robot for picking up trash in a park, print the whole robot chassis as one part, don't print each lego block.

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

[Pito Salas]

A little late to this very interesting thread. 

Have you looked at https://linorobot.org ? It's interesting because it is a flexible plan to create a ROS1 or ROS2 robot which allows you to pick (to some extent) some of the key components -- motor controller, lidar, processor, etc. I've built one and the instructions were quite good and effective.

I have a lot of experience with Turtlebot3  (I teach robotics and in our lab I have 5 of them, two heavily modified and 3 default. When I last checked, buying the components separately from Robotis was significantly more expensive than buying the whole "kit". In particular, the low level processor ("Arduino") is a propietary board called OpenCR which is far more expensive than an Arduino. It does add some functionality. And the Dynamixel motors while wonderful are also quite expensive.

Since I needed a mini fleet of beginner robots, I looked into what I could do that would come in at less than $300 per robot, and Linorobot fit the bill.

The first picture is of the modified Turtlebot3. We call it "Mutant" for (maybe) obvious reasons.

The second picture is of the Linorobot based robot. We call it "Bullet" because the enclosure is a waterproof amunition case from Harbor Freight.

Pito Salas
Faculty, Computer Science
Brandeis University

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHsZr63KWbF7Ejj%3DJ5jUOV48SN8nYRcnHDAWvRx-JqNrtw%40mail.gmail.com.

[Alan Federman]

for the original Turtlebot 1 clone I made, I used laser cut 1/8" plywood. FOR THE PLATES. SORRY MY PHONE IS STUCK CAPS ONLY.

[camp .]

> A little late to this very interesting thread.

 

If nothing else we're gathering a lot of interesting prototypes. Thanks for the Linorobot.

- Camp

Sent from Yahoo Mail on Android

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/6C25D351-E598-4500-A565-B19392856E0D%40gmail.com.

[Ralph Hipps]

if folks are looking to 'go big' on wheels & motors, one great source is SuperDroid Robots.

They have tires up to 10" (254 mm) in diameter of various flavors.

They have motors & mounts, hubs, ball bearings, etc., to build a complete chassis subsystem.

And great support, very responsive.

https://www.superdroidrobots.com/mechanical-parts/Wheels-Shafts/Wheel-Shaft-Sets

https://www.superdroidrobots.com/mechanical-parts/Gear-Motors

It all depends on what you're trying to do, how large, do you need to go off road, etc.

Built Marvin with a bunch of their hardware, went well, good ground clearance too.

[Chris Albertson]

I think what you are saying is that same as what I've been trying to say.  Nobody actually builds the "reference robot".  You build a modified version of it.

But the reference has to serve a range of builders.  Some are beginners and they will need to build a version that is very much like the reference.   More experienced builders and confidently make larger departures.   Beginners typically look for low-cost smaller robots and experienced builders might want a bigger robot that does real-world tasks like clearing a dinner table or sorting trash.

One if the sayings in my field was "It looks like you now have a job for life".  This was not a Good Thing.  It means ou created a design that will requires hours of your time every day to support because it is so complex users will not understand it and be calling you on the phone and sending you emails for the rest of your life.  No engineer wants a "job for life".  You want to finish and be done with it.   But if you create a "reference robot" you have a job for life.  The reference bot will need to be tested and updated for every new software releseand you have to support users.  It is a long term commitment.    This is good if you are charging money for support and need the income, bad if it is a no-pay job. 

The problem with Turtlebots is they use high-end and expensive components.  This is fixible.  Design lower-cost parts that still work like laster-cut or printed plates or gear motors to replace those serial interfaced servos.   

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/6C25D351-E598-4500-A565-B19392856E0D%40gmail.com.

[Chris Albertson]

The design of the kiddie ride-on car is interesting because is the very inexpensive and takes abuse and handles such a large payload outdoors.    How did they do it.?

Simple.  The parts are crude and low precision but clever.   The main thing is that with heavy robots you CAN NOT directly attach the wheels to the motors.  That is an expensive error.   Notice the presenter showing off is big robot has made bearing blocks using aluminum extrusions.   This is a good idea.

 

But Fisher price was working with a lower budget.  They used a single 24 inch long steel axel.  It is a 3/8 inch galvanized steel rod each wheel is attached to the rod but spins freely.   The wheel has a hole that is a little bigger than 3/8 inch.  The chassis also rests on this rod and the rod is held on with simple u-clamps made of plastic, assembled with self tapping screws.  The clamps keep the axel in place when you lift the car.  The wheels would fall off the ends of the axle except for a washer and cotter pin

So far you have a car that can hold 80 pounds of small children and roll on the ground and costs only about $20 to make but can't move.   The key idea is that the final drive gear also has a 3/8 inch hole and the axel fits through the drive gear.   The gear engages the wheel's side using a plastic spline.  The drives, and splines are sold on Aazon for $18 an $8 and would work with any large wheel you buy at Harbor Freight.  The wheel should come with it's own bearing.  The drives work with any axel size.

The idea that makes this really cheap is that the axel does not rotate.  It is fixed.  rotating axels are expensive precision parts.  Fisher priced used a cold-rolled steel axel with no machining.   These toys last for years and can be store outdoors in the rain and can haul a heavy load outdoors.  

The guy in the presentation took the opposite approach and build a nice, high precision robot drive but I bet he spent enough to buy two toy cars. I think it might be best to either "borrow" Fisher Price's ideas or if not buy the toy and hack it.     You can find these toy cars used on craigslist for maybe $50. but with dead batteries.   Or buy only the repair parts and fit to your own chassis.

Bottom line is that, as people have known for 2,000 years a single continuous axle that connects both wheels is very strong and easy to make.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/861f1aec-9aa9-4785-a8cc-65d3a2fbc560n%40googlegroups.com.

[Scott Monaghan]

Wow Pito!

Thanks for sharing! I have been working on a project called RoBud for several months now and one of the main project goals was to have all parts be readily available or easily printable for around $300. (github.com/scottmonaghan/robud)

I looked for a base to start with (JetBot, TurtleBot) but I wasn’t happy with any of the options so I’ve been rolling my own to mixed success.

Linobot looks like a “where have you been all my life” solution that I could use as a base platform for RoBud.

Can you share the bill-of-materials for your sub-$300 linobot?

Thanks!!

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/6C25D351-E598-4500-A565-B19392856E0D%40gmail.com.

[Dave Everett]

Great resource Pito.

Have you made any videos or posted anything about your versions of the Linobots?

Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/6C25D351-E598-4500-A565-B19392856E0D%40gmail.com.

[Ralph Hipps]

Agree about not mounting a heavy bot directly to the motor shaft.

One of my goals was to get higher ground clearance, so a solid axle across the bot at mid wheel height was suboptimal.

That's also why I went with 90 degree gearboxes to help keep the motors out of the way.

I spent about $350 on all the wheels, motors, mounts, bearings, etc., so not cheap, but I wanted something with better performance.

I have plans to mount a skid of some kind in front of the caster wheel to help with getting over tall obstacles as well.

[Pito Salas]

Hi Dave

Sorry, no nothing is posted about Linorobot. I do have working micro-sd images as well as many notes to myself where I was getting the thing up and running which I am happy to share. Also you can check out our github with lots of useful code albeit not packaged per se: https://github.com/campusrover

I addition we have this: https://campus-rover.gitbook.io/lab-notebook/ which is also a rich trove of information - I can't promise that things are up to date or working but there's a lot there.

I am happy for you to use any of it if you find it useful or answer questions about it!

Pito Salas

Faculty, Computer Science
Brandeis University

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

[Pito Salas]

Hi Scott,

I dug up our old BOM. The prices have gone up a little but here it is:

[Scott Monaghan]

Thanks Pito!!

On Thu, Dec 30, 2021 at 11:45 AM Pito Salas <pito...@gmail.com> wrote:

Hi Scott,

I dug up our old BOM. The prices have gone up a little but here it is:

--
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/0E6ED68B-E268-456A-8695-8C4F7F0C5B68%40gmail.com.

I think that $300 is still achievable. 

Pito Salas
Faculty, Computer Science
Brandeis University

On Dec 29, 2021, at 3:55 PM, Scott Monaghan <scott.m...@gmail.com> wrote:

Wow Pito!

Thanks for sharing! I have been working on a project called RoBud for several months now and one of the main project goals was to have all parts be readily available or easily printable for around $300. (github.com/scottmonaghan/robud)

I looked for a base to start with (JetBot, TurtleBot) but I wasn’t happy with any of the options so I’ve been rolling my own to mixed success.

Linobot looks like a “where have you been all my life” solution that I could use as a base platform for RoBud.

Can you share the bill-of-materials for your sub-$300 linobot?

Thanks!!

On Wed, Dec 29, 2021 at 11:12 AM Pito Salas <pito...@gmail.com> wrote:

A little late to this very interesting thread. 

Have you looked at https://linorobot.org ? It's interesting because it is a flexible plan to create a ROS1 or ROS2 robot which allows you to pick (to some extent) some of the key components -- motor controller, lidar, processor, etc. I've built one and the instructions were quite good and effective.

I have a lot of experience with Turtlebot3  (I teach robotics and in our lab I have 5 of them, two heavily modified and 3 default. When I last checked, buying the components separately from Robotis was significantly more expensive than buying the whole "kit". In particular, the low level processor ("Arduino") is a propietary board called OpenCR which is far more expensive than an Arduino. It does add some functionality. And the Dynamixel motors while wonderful are also quite expensive.

Since I needed a mini fleet of beginner robots, I looked into what I could do that would come in at less than $300 per robot, and Linorobot fit the bill.

The first picture is of the modified Turtlebot3. We call it "Mutant" for (maybe) obvious reasons.

--

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/0E6ED68B-E268-456A-8695-8C4F7F0C5B68%40gmail.com.

The second picture is of the Linorobot based robot. We call it "Bullet" because the enclosure is a waterproof amunition case from Harbor Freight.

--

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/0E6ED68B-E268-456A-8695-8C4F7F0C5B68%40gmail.com.

--

[Scott Monaghan]

Question: why have a separate mcu (arduino ternsy) control motors and capture sensor data? Why not use raspi GPIO/pwm/i2c? 

[Scott Monaghan]

Another question: what was the voltage of the battery? Was it 12v for the motors or did you run the whole system at 5v?

If you did have 12v, what did you do for voltage stepdown for the Pi/Teensy. I don’t see that in the BOM.

[Chris Albertson]

I'm looking at every one of these suggestions, the only difference seems to be what motor is used.   And what kind of box those motors are screwed too.  But other then that, they are all the same.

I think it is the motors that each builder would want to change because each is building a different size 'bot.    So what is the "reference" in the reference bot.  It is the motors that are hard to get right.   The hardest thing to get right is slow speed movement on uneven floors.    PIDs work poorly as they wind up then the motor springs forward and then has to be throttled down.  This is really easy if it is teleoperated with a joystick because humans drivers are good at this but but autonomous slow movements are hard,,, Making this the "exercise of the builder"  seems to conflict with the idea of a reference.

There is also an economic conflict.  The beginner is likey the one who want s to keep the price down but also the one who could most benefit from a sohiticaed mtor controller or even those $400 Dynamixel servos that Turtlebot uses.   Thos mother just do what they are commanded to do.

I'm going through this not with a "dog-bot".  I started with a common design and found it was not as well thought out as it seemed.  I've now make and printed multiple revisions and just decided I need to use a different idea to get the speed and range of movement I want.   Design work is hard and takes time and willingness to toss out less than optimal work.

Even with wheels, there is big tradeoff in cost, power, and controllability.  Controllability is expensive as it generally requires a big design margin and mechanical precision.   Everyone has different goals and chance willingness to spend on controlabilty.  For example what if you are wanting to build a robot with an arm attached.   Now precision maters.     

So this was my reason for suggesting something you KNW works and is scalable.   But this adds cost.

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

[Chris Albertson]

On Thu, Dec 30, 2021 at 4:11 PM Scott Monaghan <scott.m...@gmail.com> wrote:

Question: why have a separate mcu (arduino ternsy) control motors and capture sensor data? Why not use raspi GPIO/pwm/i2c? 

Because of very horrible real-time performance with Linux.   It is very hard to run a control loop at EXACTLY (say) 50 Hz. if using a general purpose operating system so you will notice that just about every Linux-based robot urse some kind of microcontroller.       OK, you can live with timing jitter of the 50 hz loop but the "killer" is handling quadrature encoders using Linux.   I don't know a way to do that.   You need either a microcontrollers of to buy a motor controller that has a microcontroller built-in (Roboclaw and the like) but either way you get a microcontroller.

Then the decision is "How do I get data to/from the microcontroller?"  You can (1) invent your own new wheel, (2) use ROS1 solution called ros serial or use the ROS2 solution called "micro ROS.    None of these are good because (1) reinventing wheels is not good, ROS1 has and end of life coming soon n ROS2 has a technical learning curve.

hen you also have to choose a microcontroller.   Some will say "see Arduino because it is dead easy for beginners"   Others will say the Rapsberry Pi Pico is 5X cheaper, 4x smaller and 20X faster than Arduino.   They are right but the Pico is one new thing to learn.     There are other arguments for the various STM32 chips.

Multiply the number of chips times the number of way to communicate with the chip and you have but a dozen ways to go.   If I were choosing I'd put microROS on the Pico.   The Pico is a tine $4 dual-core chip that is likely to still be relevant in 10 years. and all of us will e moving to ROS2, the only question is "when?"  The move may as well come with the start of the next major project.

I doubt yu will find everyone to agree with the above, everyone will go a different route

The second reason is that Rasp. Pit does not have have things like analog pins or

 

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAMzUCWPVX0B03%3D0J1KB%2BYu2DHC5f%3DNfYt2T5EWnDCOZ%2Bj%3DcXTQ%40mail.gmail.com.

[Dave Everett]

On Fri, 31 Dec 2021 at 11:40 am, Chris Albertson <alberts...@gmail.com> wrote:

I'm looking at every one of these suggestions, the only difference seems to be what motor is used.   And what kind of box those motors are screwed too.  But other then that, they are all the same.

I think it is the motors that each builder would want to change because each is building a different size 'bot.    So what is the "reference" in the reference bot.  It is the motors that are hard to get right.   The hardest thing to get right is slow speed movement on uneven floors.    PIDs work poorly as they wind up then the motor springs forward and then has to be throttled down. 

I don’t bother with PID. I start the motor values just below their start torque, then increase the PWM by 1 each timer interrupt until the commanded cm-sec speed is achieved, then I only go up/down by  1 or don’t change based on the returned cm-sec. This results in smooth acceleration. When commanded to stop, I reduce the PWM by 2-5 each time until zero is reached. I do this so s stop happens quickly but not instantly, however I can set a flag during stop to immediately go to zero if required.

I don’t get any wind up and there is no tuning.

Dave

This is really easy if it is teleoperated with a joystick because humans drivers are good at this but but autonomous slow movements are hard,,, Making this the "exercise of the builder"  seems to conflict with the idea of a reference.

There is also an economic conflict.  The beginner is likey the one who want s to keep the price down but also the one who could most benefit from a sohiticaed mtor controller or even those $400 Dynamixel servos that Turtlebot uses.   Thos mother just do what they n’t bother with PID.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHuvNspbTWWwApspKYs-Q3gau2Da4J7-GDQpu%3Du%2B2ZcTxQ%40mail.gmail.com.

[Chris Albertson]

On Thu, Dec 30, 2021 at 6:19 PM Dave Everett <daveev...@gmail.com> wrote:

I don’t bother with PID. I start the motor values just below their start torque, then increase the PWM by 1 each timer interrupt until the commanded cm-sec speed is achieved, then I only go up/down by  1 or don’t change based on the returned cm-sec. This results in smooth acceleration. When commanded to stop, I reduce the PWM by 2-5 each time until zero is reached. I do this so s stop happens quickly but not instantly, however I can set a flag during stop to immediately go to zero if required.

While you say you don't use PID you are in fact doing it.   Your algorithm is just using zero P and D but with a higher I gain set.    As your motor sits still the error integrated over time increases and the current you apply is proportional to the integrated error.   It's "PID" with P=D=0, I=1.    Many people do this, they change the gain based on the situation.   You avoid "wind up" by using a very low I gain value

Using custom tunned gains at startup like you do is smart as it aviods the problem of "infinate error" at time zero.  So you start with P=0 and I>0 then, I assume transition of P to a very low value of P   But you are defiantly using a classic PID algorithm but only with VERY low gains.

[Dave Everett]

Well if you consider using only 1 as PID :) I never use P, like I say, I increase or decrease PWM by 1 each time, so nothing proportional. It's so simple it usually upsets roboticists.

are we slower than desired cm-sec, yes, then increase PWM by 1

are we faster than desired cm-sec, yes, then decrease PWM by 1

are we exactly desired cm-sec, yes, well pat yourself on the back and do nothing.

Traditionally P would probably be a figure below 1 and this is one of the reasons I decided not to use a standard PID. The duty cycle can only change by integers, so why waste CPU resources calculating floating point numbers that the PWM driver can't use. Perhaps the fact I'm always crap at tuning PIDs has something to do with my aversion as well.

That is also why I work in cm-sec. ROS likes m/sec, but metres/second is suicide in most hobby situations. Using m-sec requires everything always be floating point., since you will always be running less than 1m-sec. Hey I'm an old assembler programmer, so I try to use integers where I can :)

Dave

--

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/CABbxVHu1FmHoyaymFA%2BWd9uUtui0_XV_jiTp8vYAx7JuEUs0kQ%40mail.gmail.com.

[Chris Albertson]

"PID" is spelled with three letters, only the "P" stands for proportional.   You have built what they call an "I controller" that happens to have very conservative tuning. 

  When a gain is set to zero, we drop the corresponding letter from the controller name.  "P" controllers are common as are "PI" and "PD" controllers and as you have an "I" controller.      These are old.  James Watt himself built the first "P" controller in the early 1800s

If people get upset it is because they see you are wasting the performance of your motor.  But even a well tuned PID is not optimal.  PID is a reactive controller and can NEVER be perfect.  It can only react to error.     Better controllers are predictive and look ahead in time and try to not produce the error in the first place. but these can burn up a lot of CPU cycles.   

It is fun to watch robots with predictive control. My favorite is SpaceX's booster landing.  Notice the turn and lean BEFORE it is needed so that the rocket lands on the spot.    Boston dynamics does the same thing.   

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAG61pbd9FRi4eAUBUpFguw%2B6uaSE0rQdiQVFid1OYrN%3DQfNEyg%40mail.gmail.com.

[Scott Monaghan]

I also do this in an unconventional way.

Instead of using the encoders on my wheels, I actually check the heading of my robot with my IMU. If the heading is off then I correct by increasing and decreasing the speed of the appropriate wheels proportional to the level of error. It works pretty decently for my purposes.

Scott Monaghan

413.244.9344

scott.m...@gmail.com

www.linkedin.com/in/scott-monaghan

Resume: https://tinyurl.com/yxhq5eul

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHs1ntFcW9_b4KDUzB9-W2AZe2RdF3Vw4YvE-4DOUm3XWQ%40mail.gmail.com.

[Dave Everett]

On Fri, 31 Dec 2021 at 17:23, Chris Albertson <alberts...@gmail.com> wrote:

"PID" is spelled with three letters, only the "P" stands for proportional.   You have built what they call an "I controller" that happens to have very conservative tuning. 

  When a gain is set to zero, we drop the corresponding letter from the controller name.  "P" controllers are common as are "PI" and "PD" controllers and as you have an "I" controller.      These are old.  James Watt himself built the first "P" controller in the early 1800s

Hey Chris, 

My I does not grow, as the value inc/dec is always 1. I'm not integrating anything, that was my point there. And since I do nothing proportional or derivative, I think it is better called an accel/decel method. I appreciate the comparison you are making though.

If people get upset it is because they see you are wasting the performance of your motor. 

What I meant is I get people telling me it can't work because it's too simple :) It's an old argument, so I always try first to use the simplest method available.  This reminds me of the great thesis by Ian Horswill about his robot Polly. At every stage, if he could strip down the functions further, then he did. It's a great paper even though it's from decades ago, still very relevant.

 

But even a well tuned PID is not optimal.  PID is a reactive controller and can NEVER be perfect.  It can only react to error.     Better controllers are predictive and look ahead in time and try to not produce the error in the first place. but these can burn up a lot of CPU cycles.   

Agreed, and while it is a problem that all robots are dealing with the past rather than the present, I feel making systems predictive is likely to be a problem as most mobile robot situations are dynamic.

It is fun to watch robots with predictive control. My favorite is SpaceX's booster landing.  Notice the turn and lean BEFORE it is needed so that the rocket lands on the spot.    Boston dynamics does the same thing.   

Well they both seem to be doing something right. I should take a closer look.

Dave 

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHs1ntFcW9_b4KDUzB9-W2AZe2RdF3Vw4YvE-4DOUm3XWQ%40mail.gmail.com.

[Dave Everett]

On Fri, 31 Dec 2021 at 17:57, Scott Monaghan <scott.m...@gmail.com> wrote:

I also do this in an unconventional way.

Instead of using the encoders on my wheels, I actually check the heading of my robot with my IMU. If the heading is off then I correct by increasing and decreasing the speed of the appropriate wheels proportional to the level of error. It works pretty decently for my purposes.

Nice. And at least you are using a real external sensor rather than hoping your odometry is accurate (which of course it isn't) I have a BNO055 in a labbot I helped build for UAH, I haven't had a chance to use it for heading correction yet, but it's definitely on my list.

The discussion about the BNO085 got me interested too as I was not aware of that one. I'll order one when they are available.

Dave 

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

[Chris Albertson]

Believe me, Adding a constant "1" at each increment of time actually does compute the error integrated with respect to time for a motor with constant error.   It's just very basic calculus, what is the integral of a constant with respect to time?  

When Watt invented his "conical pendulum" he did not call it a "P" controller but it absolutely was a "P" controller.   What happened is that mathematicians, later invented theory to describe what all these ad-hoc intuitive controllers did and came up with a generalization that today we call "PID".   

So all these rules of thumb people think they invent,  like "If I'm crossing a river I need to aim the boat a little bit upstream.  And if the current is strong, I aim a little more upstream."  This is the "D" gain in PID.       You, James Watt, the boat driver are all doing the same kind of control even if none of them every studied control theory.  If you are reacting to the current state you are running a kind of PID controller even if you neer hear on it.

 The PID control theory has little to do with motor encoders.  It talks about "estimating the error" and any kind of estimate will do.  A wind mill on the robot would work if you use the fan blade speed to estimate speed.  The IMU work too.

PID looks at up to three of the following, the current state, the integral of the current state or the derivative of the current state.  If the system reacts to any of that you've acticently created a PID control loop.   You don't even need an electric motor the algorithm is old than electric motor.,  As said, Watt made the first one without knowing it.   Later James Clear Waaxwell (better known for his electromagnetic field equations) looks at Watts control and tried to place it n a mathematical theory.  But the device was built be an invention who never heard of this theory the theory invited decades later. in the 1860's

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAG61pbcdsXUsXkux59sZesnMn5PjRFo%2B6OiVD6NysGwiwMN-7A%40mail.gmail.com.

[camp .]

This thread has generated a lot of good links. I have summarized them below:

 

------------------------------------------------ snip ------------------------------------------------  

Introducing RomiPi: A ROS Package for the Pololu Romi

http://www.peterklemperer.com/blog/2019/05/02/introducing-romipi-a-ros-package-for-the-pololu-romi/ 

 

Romi Chassis Kits

https://www.pololu.com/category/203/romi-chassis-kits 

 

Romi 32U4 Control Board

https://www.pololu.com/product/3544 

 

LIDAR LD06

https://www.inno-maker.com/product/lidar-ld06/ 

 

Dagu Wild Thumper Wheel 120x60mm Pair with 4mm Shaft Adapters - Metallic Red

https://www.pololu.com/product/1555 

 

gobilda

https://www.gobilda.com/ 

 

Rubber Wheel & Motor Kit

https://www.dfrobot.com/product-1203.html 

 

HCR - Mobile Robot Platform (Support Kinect)

https://www.dfrobot.com/product-63.html 

 

Setting Up The URDF

https://navigation.ros.org/setup_guides/urdf/setup_urdf.html 

 

gnaur/simbot

https://github.com/gnaur/simbot 

 

Open Source Mapping Robot

http://www.robotbrigade.com/mappingRobot.php 

 

ScottMonaghan/robud

https://github.com/ScottMonaghan/robud 

 

TurtleBot3

https://www.robotis.us/turtlebot-3/ 

 

TurtleBot 4

https://clearpathrobotics.com/blog/2021/10/clearpath-robotics-announces-turtlebot-4/ 

 

Beginner: Model Editor

http://gazebosim.org/tutorials?cat=guided_b&tut=guided_b3 

 

Setting Up The URDF

https://navigation.ros.org/setup_guides/urdf/setup_urdf.html 

 

Rubber Wheel 136×24mm (Kit)

https://www.dfrobot.com/product-1006.html 

 

5201 Series, 53:1 Ratio, 105 RPM Spur Gear Motor w/Encoder

https://www.gobilda.com/5201-series-53-1-ratio-105-rpm-spur-gear-motor-w-encoder/ 

 

5202 Series Yellow Jacket Planetary Gear Motor (99.5:1 Ratio, 60 RPM, 3.3 - 5V Encoder)

https://www.gobilda.com/5202-series-yellow-jacket-planetary-gear-motor-99-5-1-ratio-60-rpm-3-3-5v-encoder/ 

 

Linorobot

https://linorobot.org/ 

 

Wheel and Shaft Sets

https://www.superdroidrobots.com/mechanical-parts/Wheels-Shafts/Wheel-Shaft-Sets 

 

Gear Motors

https://www.superdroidrobots.com/mechanical-parts/Gear-Motors

------------------------------------------------ snip ------------------------------------------------

 

The HBRC Example Robot Goals & Guidelines Discussion DRAFT is here if you'd like to join in:

https://docs.google.com/document/d/1gFfrrMrZ4ZPJ-SRzuViX5B-59AWDK95AomR9_E8CAbE/edit
 

Thanks,

Camp

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

[Mark Womack]

The main reason is speed and frequency. The Arduino can be dedicated to read the sensors faster and more often. On our RoboMagellan we had the Teensy reading the various sensors and then publishing the data to the various ROS topics. You could also retrieve the data via I2C from the RasPi, and the Teensy would just give you the current values. You wouldn't have to wait for it to access the sensors etc.

-Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAMzUCWPVX0B03%3D0J1KB%2BYu2DHC5f%3DNfYt2T5EWnDCOZ%2Bj%3DcXTQ%40mail.gmail.com.

[Mark Womack]

The Teensy is Arduino compatible, so the learning curve there is reduced, though using stock libraries on the Teensy might require modification (since most libraries make assumptions about how many hardware serial ports or I2C buses there are).

I have used ros_arduino_serial on the Teensy 3.5 and it was very straightforward. I did a cursory check of microROS and Teensy is one of its supported processors. Would like to look at this closer.

The latest Teensy, Teensy 4.1, is a blazing chip with a Cortex-M7. I don't know how it compares to the Pico. But the level of flexibility in the Teensy chips is hard to beat. The 4.1 has 8 serial and 3 I2C, so you can connect it to a lot of devices, plus a ton of digital and analog pins.

-Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHt2btU1v8e8jNT3k6BVY%3DDzLo0aUxYZAdWYUfJmv%2B__dg%40mail.gmail.com.

[Mark Womack]

And believe me, I have a great appreciation of the depth of knowledge and enthusiasm to share and help. It feels like it is picking up some steam, and I am looking forward to working with everyone.

-Mark

On Tue, Dec 28, 2021 at 9:19 PM camp . <ca...@camppeavy.com> wrote:

> But if it's just the two of us, I don't know if it will have enough momentum as an "HBRC" thing.

 

    It's already an HBRC thing. As long as we have fun and learn, who cares? We've already got input from at least a half-dozen experienced robot-builders. Google Docs rocks, and the "HBRC Example Robot Goals & Guidelines" is just right. I've done some research that would not have been done otherwise because of this initiative and am looking forward to what others have to say this evening.

 

Thanks,

Camp

On Tuesday, December 28, 2021, 08:50:00 PM EST, Mark Womack <mwo...@gmail.com> wrote:

I get it.  TurtleBot is the official reference.  We certainly don't want to replace it, or maybe even compete with it.  But I don't want to build a robot out of a kit with everything predetermined and pre-chosen. Even if it is super well designed, covers all the bases, and I can 3D print all the pieces. I want to learn by doing for myself. There's a limit to how much I want to do from scratch. I don't want to create my own motor controller. But I do want to put components together and understand how they play together with ROS in the mix. Maybe it means reusing large portions of the TurtleBot code, but understanding how it gets customized for the robot being built. Maybe it means writing some amount of new ROS code. Maybe it means at the end of the day I throw up my hands and buy a TurtleBot. I don't know yet. I guess that is more my point than it being an "official" reference or a competing reference. And someone else may look at it and decide that they don't want a robot out of "my" kit, but want to run off and do their own thing. If so, ok, maybe they learn something from the design or code. If anything this thread has shown there are a lot more robots out there.

I floated the idea of an "HBRC Reference" because I wanted to see if there were other like minded folks out there that might like to work on a robot as a group. Something that could be shared amongst the club, something that would be like a "reference". I know it might be crazy, but I would prefer to work on a robotics project as part of a team, not in solitary.  I'm way out in New York, so it's going to be a challenge at any rate. When I worked with Gris and Michael on our RoboMagellan I had a blast. And our robot didn't complete the course, but so what. I learned a lot and I enjoyed working with them, even if I had to drive out to Neato every weekend for two months. And I'm glad that Camp has jumped in with some enthusiasm, insights and ideas, and I look forward to working with him. But if it's just the two of us, I don't know if it will have enough momentum as an "HBRC" thing. Maybe it's just something we work on together.

At any rate, I'm going down this road some more. If anyone else wants to join in, you are welcome. At the very least I have updated my document replacing "Reference Robot" with "Example Robot" so there is much less confusion. If it turns out to not be an "HBRC thing", then I will update it further.

-Mark

https://navigation.ros.org/setup_guides/urdf/setup_urdf.html 

 
Thanks,
Camp

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHs_ifutQr%2BuLqGaiuQybjDckd2Y0hziU8o_rqzrv74inw%40mail.gmail.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAF-TXgtJnZ4qksgqgkeG1im-Yagcja4_aa6SZs6jq6Je7fwviw%40mail.gmail.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.

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