[quanto]

Your intuition is quite correct that closed-loop means open-loop repeatability is not critical, but controlability (non-stickness, smallest possible controlled movement) still matters. Motors are well behaved and continuous, so even with some backlashes, you will be fine. There are also ways to compensate for backlashes from software (e.g. same approach angle for end effector).

Aloha is a fascinating project and would love to hear more about what you are thinking. Dynamixel indeed is too expensive

[Xmd5a]

First I'd like to reproduce the Push-T task of the policy diffusion paper (video here: https://diffusion-policy.cs.columbia.edu/)

Afterwards I'd like to tackle useful tasks related to gardening/botanical experiments: uprooting weeds, handling pests, harvesting small fruits. What's interesting is that you can develop new approaches to these problems. Uprooting stuff is difficult to do for a machine I guess. Maybe just cut the weeds with scissors every day, that'll teach them a lesson. Or remove aphids "by hand".

Another interesting thing is to do more scientific tasks such as handling a lot of tedious tasks on many, many plants. Example: creating polyploid plants is a lot of manual labor, what I'm talking about here is basically lab automation (doing flow cytometry on dozen or even hundred of samples).

Another aspect to explore in this space is continuous measurements (measuring photosynthesis efficiency for instance). I'm not a botanist but it seems that measuring devices either come in the form of a box you put the plant in, and you can get quasi-continuous measurements, or they are hand-held and you can only do punctual measurements (typical example: chlorophyll fluorometry). Also plants grow and change shape so putting a measuring device on a plant is in fact rather difficult. I think something like Aloha (even without the "Mobile" extension) could help tackle these situations.

[Xmd5a]

Stumbled upon this paper when exploring the topic of "visual servoing"

https://arxiv.org/abs/2208.11538

Visual Servoing in Orchard Settings

We present a general framework for accurate positioning of sensors and end effectors in farm settings using a camera mounted on a robotic manipulator. Our main contribution is a visual servoing approach based on a new and robust feature tracking algorithm. Results from field experiments performed at an apple orchard demonstrate that our approach converges to a given termination criterion even under environmental influences such as strong winds, varying illumination conditions and partial occlusion of the target object. Further, we show experimentally that the system converges to the desired view for a wide range of initial conditions. This approach opens possibilities for new applications such as automated fruit inspection, fruit picking or precise pesticide application.

[Joel_Mckay]

Or you could just try a classic library yourself:

https://visp.inria.fr/

http://wiki.ros.org/visp_ros

https://github.com/lagadic/visp

example:

https://github.com/afonsocastro/larcc_interface

YMMV =3

[Joel_Mckay]

"closed-loop means open-loop repeatability is not critical"

Hobby servos have limited repeatability especially as they wear, and when swinging an arm with shifting center of mass the errors will be quite obvious.

One may want to look at the UR5 platform design before wasting time and money. Best of luck =3

[quanto]

> Hobby servos have limited repeatability especially as they wear, and when swinging an arm with shifting center of mass the errors will be quite obvious.

Your statement is correct by itself, but it is not completely applicable to what the GP comment (not my comment) said. Aloha uses optical encoders (which themselves are far better than hobby-grade potentiometer servo encoders) and in fact also compensates for inaccuracies in the optical encoder.

I have no experience with UR5 but looks interesting. Any reason why you recommend this?

[Joel_Mckay]

"Any reason why you recommend this?"

Pre-built 3D simulation models for easier software development, official ROS support from the company, and better physical safety with advanced force-sensing motion systems.

"optical encoders" have their own set of issues... usually require quadrature encoder tracking FPGA or dedicated ASIC features in the mcu. i.e. you now have 2 problems to solve, and higher costs.

Best of luck, =3

[Xmd5a]

Related optical encoder project I found a while back that used to rely on an FPGA but doesn't anymore:

https://github.com/JamesNewton/HybridDiskEncoder