PyRobot

I appreciate the effort here though - ROS feels like it's become harder to use due to stale documentation, and there's value in providing a simple python API that abstracts the underlying bringup.

However looking through the wrapper and its documentation, it doesn't feel like it's making it much simpler by hiding away standard ROS tools.

This gives the owner of the project a large amount of weight not only in the direction of the project's code, but also in the community as a whole, which can have some substantial negative impacts I believe.

With many open source projects started by non-companies, you end up with community leaders who are a few people in the scene who started the project or contributed to it heavily and care about the space a lot. Most importantly, their views are affected largely by the community -- they're "one with the community" so-to-speak.

With the introduction of large companies managing OSS projects, there is a new aspect in which sub-communities grow. This allows for one side of the community (almost never the company's side) to become "a group of people to communicate our changes to" rather than a group of people to actually collaborate with.

I could list several examples of this happening, but I don't want to anger anyone from these companies against me personally and don't feel like creating a throwaway account.

Treating OSS projects as communities and code has some nice qualities, and certainly having paid engineers from companies working on these projects has nice properties, too, but we're not honest with ourselves about the downsides and risks and people regularly give _more_ weight to projects created by companies without warrant (I've seen 20% projects by Google on the front page of /r/programming without even so much as a README -- something that would never happen if it wasn't "created by a FAANG")

There was a REALLY good comment on FOSS vs. closed source commercial software that was brought up a couple weeks ago, which I wish I could quote verbatim but unfortunately you'll have to deal with my paraphrased version:

> "In early UNIX days, we got things done on computers using lots of small tools that did one thing well because compute resources and developer talent were both in scarce supply. Nowadays, software companies can put together teams that can manage huge monoliths of software. In order for FOSS to thrive, we need to put less time into trying to beat these companies at their own game (e.g. code behemoths like the ones you see on Linux desktop projects) and focus more on making great tools that do one thing really well (e.g. cURL, GNU Readline)"

ML/AI is also really hard because it requires people to establish much stronger interfacing standards between the important steps of the data analysis process AND the substeps within those steps. Keras[2] was an enormous step forward in this regard, but the creator now works at Google and I assume he isn't very interested in continuing to make Keras the standard frontend for Deep learning model specification.

HuggingFace[1] Is an awesome counterexample to this trend of AI/ML being lead by FAANG. I'm fiending for an opportunity to check out Thinc, but I'm quite occupied with security coursework these days.

1: https://angel.co/company/hugging-face 2: https://keras.io/

I'm excited for the time in the near future when a useful robot arm costs roughly as much as a good laptop i.e. ~1k USD.

At that point, it'll become feasible for hobbyists to get one each and start playing around. Which will lead to an explosion in the variety of things tried, and will positively feed back into creating a healthy community, tons of software which makes it easier for the next set of people to get involved, etc. Much like the PC revolution in the 80s/90s.

At the moment, they're kinda like overpriced toys (for a home user / enthusiast point of view) without a killer app.

(Not affiliated, just have friends that work there)

Even with things like pre-defined movement areas and collision boxes, arm planning software sometimes completely freaks out and produces weird plans that would probably break things. So it's always good to visualise before sending the commands to the physical system.

Gazebo is a common environment: https://community.arm.com/developer/research/b/articles/post...

You can find the majority of hardware and electronics you need for basic robotics from the following sites:

https://www.pitsco.com/

https://www.vexrobotics.com/

https://www.andymark.com/

http://www.revrobotics.com/

https://www.servocity.com/actobotics

The high costs come into play when you have to deal with high precision servos with high torque. The Trossen Robotics site gives you an example of high precision servos and pricing.

https://www.trossenrobotics.com/

You can find cheaper robotics options at the following site

https://www.robotshop.com/

When you run a team you start with a budget in the low Ks and build out the equipment inventory over several years. There is high attrition in many of the electronic parts (Servos, Controllers, Sensors) when you compete.

Building basic robots is not complex. Basic navigation using techniques such as dead reconing, etc are not complicated. What is complex is advanced software techniques for navigation, motion planning, etc which rely on some complex math.

Have Fun!