Tomauto1

I am creating a robot to manage a vertical greenhouse and I'm calling it Tomauto1. Before I get into a more technical description I need to mention a couple high level things about this robot.

First of all I need to address one of the main criticisms I get about this project. It goes something like this:

Tomauto1 is not sustainable and it's really unnecessary anyway because there are some great organic farming techniques out there that don't require a lot of work. In addition to this our obsession with technology is what got us into a lot of the mess we're in. Therefore Tomauto1 is kind of dumb and creates more of a problem than a solution.

This is a fair statement. And you could probably write a books supporting this argument and also countering it. But all I will say is this. No agricultural system in the history of humanity has lifted as many people off the farm as the current system. Approximately 70% of jobs in the USA were in the farming industry in the 1700s and today it is less than 1%. We also live in a world with 9+ billion people and (I'll take a wild guess) at least 90% of these people and probably more don't want to work on a farm and not only that are completely oblivious to how inefficient and polluting this very system is. They also want to live more sustainably but just don't know how and don't want to work for it. In order to get massive change, we need to appeal to these people. We have to show them that they can have organic food, produced in an environmentally friendly way, without them having to lift a finger and it can also be free. Is Tomauto1 the best solution for this problem? Probably not. But it is a solution shown on a small scale that could theoretically be scaled to thousands or even millions of acres. I said this on the introduction. This is more of an art project to show what can be done rather than presenting a gold standard solution. We can completely automate high capacity farming systems to produce 10s, 100s or maybe even 1000s of times as much food per square foot as traditional farming systems and do so in an environmentally friendly way and also completely free of pesticides and herbicides and then give it to people for free. Tomauto1 coupled with a specially designed greenhouse is a way to do that. OK, now to get into a description of the robot.

Limitations: What Tomauto1 can and cannot do

The robot is designed to operate in a very specific design of a greenhouse. It cannot operate in any old greenhouse and be effective. The design of the greenhouse is a work in progress and has not been published yet. Like the robot it will be open source with instructions on how to build it. Therefore I'm not selling anything and it would be on you to follow the instructions to get it built if you want to have a system like this. In addition, this robot is quite small which provides some benefits but also some limitations. The benefits are that it is cheap and easy to work with. Anybody can build one of these in about 2 hours from scratch. The current cost of the materials is around 2500$. If you think this is expensive, please keep in mind that buying a comparable proprietary robot from a profitable company will cost you easily 25,000$. Also this is the fully loaded robot with a trunk and robotic arm. I plan to create a smaller one without a robotic arm that is simply an inventory robot that can be built for under 500$, but that will come later.

The limitations of Tomauto1 are that it won't have a super high payload capacity. It will have to make many trips to drop off harvest at a location to make room for more. Another even more critical limitation is that it will not be able to reach above ~24 inches. This means that it can only completely harvest plants that produce fruits/vegetables that grow under this height. The robot is not going to deal with re-seeding or replacing dead plants, so manual work will be required by a human for this. However this is a solvable problem from a robotics point of view. It's just a lot of extra work that I am skipping for now. Because of this, perennial plants are the preferred type of plant to be harvested to reduce the amount of manual work, but you could easily work with annuals, just a little more work for you replacing the plants. The robot will be able to tell you however if a plant is dead or needs replacing. So eventually, you'll get notified. You could also have it work with plants over 24 inches, but it just won't be able to harvest anything above 24 inches. I really hope to build a scaled up one some day so it can work with some types wheat and corn. But for now it can only work with very small plants. Another limitation but this is actually more characteristic of the greenhouse, is the plants have to be able to be grown hydroponically. I know that basically anything theoretically can be grown hydroponically but some things are easier than others. There are various reasons for this, but the main one is, the goal is to create a super high capacity greenhouse and from what I want to do in terms of automating the work with this robot and with this high capacity, growing stuff in dirt is not an option. Therefore anything that can't be grown hydroponically or is over 24 inches in height will be incompatible with this robot/greenhouse setup. You might be wondering at this point then, well why are you harvesting tomatoes? The answer is I'm not. I just like the name Tomauto, so it is what it is. The first plant I will harvest is going to be strawberries. Lastly, the ability for the robot to harvest a particular fruit or vegetable requires that the robot is trained and configured for this. Once the robot is trained on the fruit or vegetable it should always be able to do work with it, but it does require that initial training. I am really hoping that the open source community will eventually help me with this because this is a lot of work.

The future possibilities

This is wishful thinking, dreaming but theoretically possible down the road capabilities of this robotics platform.

One of the minor criticisms I get about this idea is that it is not sustainable. It is a system that is dependent on capitalist structures so it is never possible for it to be sustainable and therefore not a good long term solution. I disagree with this idea.

This robot can be made sustainably and here's why I think this.The current design requires the structure to be built from about 90-99% aluminum parts. These parts are specially created using computer programs driving cnc machines and other machines that are capable of sub millimeter precision with their cuts. This consists of basically all of the surfaces and structure except for the computer components, battery and motors. I see no reason why this aluminum physical structure could not be replaced with bamboo or some other kind of flexible strong wood. Those machines can work on this material, and the tensile strength of aluminum is far greater than what this project requires and much simpler material could be used. Plant based plastics such as PLA using 3d printers is also a super viable option. In addition to this there are methods for creating joints using dowel and other basic woodworking techniques combined with super glues derived from plant based material that could replace the screws. Much of the plastic requirements for the various custom mounts, grippers and wheels have the same characteristic. They can also be derived from plastics derived from plant based material which are biodegradable and sourced from raw renewable resources. These plastics also have far less tensile strength than aluminum and some of the other components in this project, but that is OK because this robot is very light, is not fast and does not haul heavy loads.

This really just leaves the motors, computer components and batteries. I'll start with the battery since it is the simplest thing to explain. This robot with some clever engineering does not need a battery to operate. I am using one for now because it is the easiest thing to do, however some sort of a trolley system like electric busses (before battery powered busses became popular) have could easily be developed for this robot since it's navigation paths will not have to vary. It could very easily travel the exact same route each time for harvesting if such a system were in place. This is actually harder to do than using a battery with self navigation like what I have done with this robot which is why it's not being done, but it does not have to be like this. It does not need a lithium ion battery or any other battery. However, to create this trolley system I need help from very clever electrical and mechanical engineers. Until that time it will use a lithium ion battery and self navigation.

The motors require metals that conduct electricity. There is no way around this as far as I know. However using wiring to conduct electricity is one of those things that if you can take care of, it can last forever. Motors use electro magnetism to twist a shaft. These magnets like wires also need to be conductive of electricity. However the magnetic effects are created by passing electricity through metals such as iron, ferite, copper and steel and other metals. Like copper wiring these components and processes do not degrade. You could theoretically run an electro-magnet for 1000s of years with out it degrading, if you take care of the components during that time. The other parts of the motors such as the gears and casing can be made from metal but don't have to be. They can be made again from plastics derived from plant material,. The gears do wear out and have to be replaced, so making these things from such plastic such as PLA would be ideal and also a sustainable solution. Brushless motors are an alternative to brushed motors, they last a long longer because they don't have gears, but as far as I know these are only for continuous motors and not servos. This project requires servos. so that may not be an option. For these reasons I think the motors can be designed and engineered using sustainable supply chains. This absolutely can be done. So this would be a future project for somebody. It is worth mentioning that even its unsustainable form 10s of thousands of these robots could be created with the amount of plastic, aluminum and steel that exists in a Walmart parking long on a Sunday. 10s of thousands of these robots could theoretically manage hundreds of thousands if not millions of acres of vertical farm space.

This really just leaves the computer components. As a software engineer one of the most offensive things I have seen in my career is the planned obsolescence of computer components. For capitalistic reasons it seems that we need to buy a new phone and a new computer every few years to be able to continue doing the same things we've always done. Watch movies, check our email and surf the web. The usage of computers for most people has not changed in decades. A computer should last somebody a lifetime, not be what it is today. Computers also are built from silicon and various metals and plastics and unlike motors have no moving parts that can wear out. There is no reason a computer should not last you many decades except for capitalistic motivations of the companies that produce them and their insistence on making computers obsolete through ethically corrupt software design. The computer running Tomauto1 is a raspberryPi5. The price of these has recently sky rocketed recently due to ram chip shortages due to the explosion of AI. However I purchased the one for this project for 125$. It is running Ubuntu24.04 which is an open source operating system that is not designed by capitalists creating planned obsolescence in their products. For 125$ today, you can get a personal computer that was top of the line for consumers 15 years ago. And yes you can still check your email, surf the web, watch Netflix and play simple computer games on it. This computer with this operating system could last a century or longer if it is properly cared for.

With all that being said, I think the computing components and/or the motors are probably the least sustainable aspect of this platform but they can be made far more sustainably than how much of this is produced today. As a people and a culture we need to decide that we want computers to last a lifetime and develop robust recycling processes around them. Highly performant computers can be made incredibly cheap and orders of magnitude more sustainable than what your mac book pro or android phone currently is. This is really a cultural issue, not a technological one to create sustainability in this area.

So with all that being said. I do not agree that these robots are impossible to be made sustainably. This one currently is because I need to build something and I don't have the time or the resources to make this robot truly sustainable. But it 100% can be. This is one of the reasons I need help on this project. To work on this problem.

As mentioned previously, this robot has physical limitations, but this is only due to design decisions that had to be made. I decided to make a small robot to start with for a simple reason. It's cheaper and easier to work with and as I've stated many times already I am not trying to create an all encompassing solution to sell to people. I am only trying to show people what can be done. That being said, there is no reason this exact robotics system couldn't be scaled up to have a carry capacity of 100s of lbs and be able to reach 10 feet or more. The software would not have to change much, we would just have to get some different motors, assemble larger structural components and then train the robot to manage whatever large crop you want. You want to automate apple harvesting? Sure we could do that some day. We could also outfit the robot with some off-road wheels and make it 6-wheel drive for rough terrain in permaculture type conditions. You could also outfit the robot with a compass or even an RTK or PPP system to allow the robot to navigate very far distances in complex changing environments. However these kinds of systems would rely on satellites but could open up a world of opportunity in difficult terrain. All of this some day could be possible with this platform without a whole lot of change to the underlying system.

Anyways. I am just trying to explain that there are a lot of weaknesses with this current system, however they are not impossible challenges and in some cases actually relatively easy to solve. There are also incredible possibilities for scaling the robot's capabilities to operate with large fruiting trees and over huge distances if somebody had the resources and interest to do so. I chose to build the robot that I did because I have financial constraints, space constraints, time constraints and other constraints. This is not the best or only thing myself or anybody can do. We just need more people to start thinking about and working on these problems if we want this system to be better.

A Brief technical description of the physical robot

You can see a 3d model of Tomauto1 here. It is a custom robot. I use the gobilda platform provided by ServoCity. For anybody interested in building custom robots, I cannot recommend this platform enough, there simply is nothing else like it. One thing that I should mention though, is my robot is not using the motors or controllers from ServoCity. I chose to use Dynamixel motors from Robotis instead. I'll explain later about this, but checkout servo city in the meantime. There are some generic blocks that represent motors, battery, computer components etc. I didn't have 3d models for these things, so I created these generic blocks that are the correct sizes for what they represent and allow me to plan the space of the robot. If you check back from time to time, you'll see this model change over time.

As you can tell from this design, this robot is very much a work in progress. It cannot currently manage a greenhouse. The robot source code is developed enough that the 4 wheel drive robot can only operate in a simulator. Self driving is complete and is working in the simulator along side a working camera. Some of the things left to do before it is actually working in the greenhouse are:

1. Build a greenhouse complete with growing plants. The greenhouse has to be a custom designed that supports a self driving robot that fits the requirements of tomauto1.
2. Develop an automated irrigation system. While I have some ideas of how to do this, this is less developed at this point than the greenhouse managing robot. However it should also be alot simpler to implement.
3. Just completing step 1 and 2 would provide enough functionality to manage a greenhouse in terms of monitoring the inventory, keeping the plants nourished and watered etc. However a robotic arm is the next step to automating even more of the work required to maintaining a greenhouse.

Demo of Tomauto1 operating in the simulator

Here is a video of the robot working in a simulator. There are 2 visualizations of the robot. On the left is the simulation of the robot working in the environment. The program is called Gazebo. You can think of this as the view of the simulated world the robot is operating in. The environment in the video is quite large, significantly larger than the greenhouse area that I plan for it to manage. The robot itself in the image is the equivalent of a ~12 inch width and about a 13 inch length. The wheels themselves have about a 4.5 inch diameter., The window on the right shows what the robot knows about the environment. This program is called Rviz. This is why on the left you see a 3d sort of space, but on the right since the robot can really only understand it's environment in 2 dimensions via the lidar scanner it is a map with flat shapes indicating the silhouettes of the objects. Also if you look carefully you'll notice at about the 30 second mark in the video a green arrow briefly shows. This indicates that the robot has received a command to autonomously drive to the location. The arrow indicates the location to which the robot should drive to and what angle it should be pointed at once it gets there. Shortly after the arrow disappears the robot, very slowly drives to its location.

The robot software tracks the robot in the environment so that it knows where it is and can autonomously navigate. This demonstrates a solution to one of the 3 major technical challenges required for this project. Autonomous driving. The other 2 major challenges are to build an object detection system that can detect what state of development a particular fruit or vegetable is. In other words, how ripe it is and if it is ready to be harvested. The third major technical challenge is to manipulate a robotic arm to harvest a fruit or vegetable that is ripe. However these last 2 technical challenges have not been solved yet. Another cool feature that is visible is the integration of the camera. In the Gazebo window on the right side, if you look to the bottom left corner you can see that the camera is working. It shows you what the robot sees.

A Technical Explanation

I'll explain this robot for somebody who has never created robots before and for who this is a whole new topic. If you are a person who has experience designing, building and coding up robots, you may want to jump straight to the source code. The Tomauto1 source code is available here. Instructions for how to build and run the robot in the simulator as is done above is in the project's README file.

The project is coded with Python and C++. C++ and Python are 2 different programming languages that are industry standards. Both are general programming languages, meaning they can be used for many different kinds of applications. The main differences between the programming languages are really only ease of use and performance. Other than that, you can pretty much do whatever in either language. C++ is one of the more complicated programming languages that exists. It's difficult to learn and work with. But it is also extremely performant. For certain operations it might run 100s of times faster than other programming languages. Python is the opposite. It is much easier to use but it is less efficient and slower. There are few applications in the business that Python would be too inefficient to use. C++ is important for robotic systems because robotic systems usually have extreme physical constraints, mainly due to the space they have to carry a computer and also the carrying capacity of the robot. This is even more the case with aerial drones. For this reason using a super efficient programming language is important to maximize performance of the robot.

The project also uses ROS2. ROS is a framework for building robots. The framework solves many of the common problems that one encounters when building robots which is why it is good to use it. It makes it easier to build high performing robots. You can actually see 2 of the very important components that come with this framework in the above video. Gazebo and Rviz. Gazebo is the simulator tool on the left hand side and Rviz is the Robot Data visualization tool. Using these programs is extremely useful because it allows somebody to code up a robot entirely on their own computer and run it before even purchasing hardware. The framework also makes it relatively easy to swap back and fourth between mock software components and actual hardware interfaces.

Another majorly important feature that ROS2 provides which is probably not super obvious when you watch the above video but is being demonstrated is that it is a framework that helps the robot to really know what it's doing. The architecture for a ROS2 robot is centered around nodes and services. Basically a functioning robot will contain many nodes and services each of which is responsible for a particular piece of the functionality. When you build a robot with ROS2 you'll configure it to use some pre-made nodes that other software developers have provided and you'll also create your own. This project has custom nodes and uses pre-made ones too. The nodes communicate back and fourth with messages which is what helps the robot to know what it's doing and take the appropriate action.

For this particular robot there are a few key things that the robot needs to know about to operate effectively. It needs to know it's dimensions, it's surface area, where and what kinds of joints it has and other physical properties. There is a bunch of fancy math and what-not baked into ROS which will use this information to understand how the robot will move in it's environment. Another thing that it knows that is closely related to this is the state of the wheels. ROS provides an interface to the wheels whether the robots are using mock software components or real hardware it doesn't matter. The interface allows messages to be published to it regarding how to position the wheels. Because of the loose coupled architecture you can theoretically have multiple publishers. You could connect an xbox controller if you wish, you could also set it up to publish messages from your keyboard so you can control it like a computer game. However what is most relevant for Tomauto1 is to autonomously navigate, in which case we need to publish messages based on the logic of the harvesting software.

To autonomously navigate a few things have to be in place in addition to what was mentioned above. You need to have a map of the area which is what RVIZ (on the right in the video) has. In it you can see a 2d representation of the simulator world. You also need a lidar scanner. In the video above the map was generated beforehand and is loaded once the robot starts up. The map was actually manually created rather than and automatically using SLAM. The reason for this is SLAM does not work very well for the small simple worlds characteristic of the greenhouse that this robot will operate in. I'm just mentioning this for folks with more experienced robot experience, but if this is new to you, don't worry about SLAM for right now. Just know for this project it's better to just create the map by hand which is what I did. The map on the right, in RVIZ, represents what the world should look like, but really when you start the robot up with the map, you're just saying. "Trust me robot, this is the world you're in." If you give it a map that does not match the real world, the robot is going to have problems. This is a limitation of this method for doing autonomous navigating. However this limitation only exists if you don't have a strict definition of the environment for the robot. If you know exactly what the world looks like to the robot, then it makes self navigating a lot easier. And luckily for this project, this is the case. For this project we don't need SLAM but we do need NAV2.

After the robot starts up and the map is loaded it can begin to navigate. Using the physical data about the robot as mentioned above it can estimate where it is on the map. For example if the 4 wheels turn 360 degrees, it should know how far forward it has moved. But if it just has a map in memory and this information that clearly will not work by itself. For example, what happens if a person walks in front of the robot while it's operating and the robot crashes into the person's leg and is pushed back while the wheels are still spinning? This will create drift and the robot will slowly over time will be less and less accurate knowing its position on the map. This is where the lidar scanner comes into play.

The lidar scanner in the video is clearly a mock because it is a simulator. If you look closely in gazebo and RVIZ you can see its physical position. It's a little round grey cylinder on top and forward on the robot. But for your actual physical robot you'll have to buy one and attach it to the robot in this location. The lidar scanner emits many different rays of light in 360 degrees at a high frequency. Different lidar scanners operate at different frequencies so you need to make sure that what you have configured for your simulation matches your real scanner. The lidar is able to measure the distance that the light travels. This allows the robot to know at 360 degrees all of the surfaces that are around it and very precisely at what distance. It's important to note that this robot is equipped with a 2d lidar scanner. It knows about objects that can be represented in 2 dimensional space. This means that the lidar beam itself is very thin. This creates the problem where if the lidar scanner is situated on a robot 3 inches above the ground, and the robot is driving around and encounters a rock that is 2 inches in diameter, it will not detect that object which could push the robot off course. However there is a separate ROS node running which is reading this lidar data and comparing it with the loaded map. This mechanism along with some drift correction software is able to publish information to ROS about what is actually in the world and where the robot actually is on the map.

As you can see ROS provides a lot of functionality out of the box which makes building high performing robots much simpler compared to if we didn't have all of this per-made functionality provided to us for free.