Ground level detection


I encounter the challenge that the level of the ground is varying despite my efforts to make it smooth and plane. Are there any considerations for the issue in the community how to handle this?


1 Like

@jensGeorgsen We have seen third party projects that perform ground level detection. This one was posted a while back by a third party FarmBot enthusiast.

I have a generic VL53L1X (solid state laser distance chip) carrier board on order but I don’t know how to integrate a I2C board to motion controls yet. I intend to use soil probes so I figure distance will be necessary.

1 Like

@aronrubin Please let us know how it goes or if you require any changes to the platform to integrate the work. This is an area we have had our eyes on for some time but have not been able to pursue due to our small staff size.

The primary question right now is what is the best downstream communication and powering? I don’t think there is a RS485 bus. Serial, USB, WiFi?

@aronrubin Running a USB line would be feasible, though that might require us to re-compile FarmBotOS to support whatever drivers you need. If the USB line is a serial line, we might need to make some updates to how serial detection works (this discussion is a sign that it is time to update serial line detection anyway).

WiFi would also be interesting to see because you could theoretically create a system that works autonomously outside of FarmBot OS, giving you more control over your development environment. Credentials handling could be a challenge, though.

For things that require more power than what a USB line can offer (like this project) we’ve seen folks run a power line from the electronics box to the tool mount.

What would be a good solution from your point of view? If you needed changes to be made to the platform to support your idea, we would be interested to hear them. Distance detection is something we’re particularly interested in supporting.

Thanks for the comments! Just thinking about the best technology to use. I would imagine that IR might be disturbed by the sunlight while the Lidars I have looked at need min distances of a few decimetres. My idea was to use ultrasound, HC-SR04 might be a possibility. What is your opinion?


We actually have some top secret prototypes at the warehouse that use that sensor, so it is very much on our “radar” (pun intended). I can’t say much more than that unfortunately because as I’ve mentioned, I typically focus on the software aspects of the system. That’s a great question for @roryaronson and @Gabriel though.

Imagine this: A Farmbot Universal Tool with a Staples “Easy” button on the end - want to skip making sure the soil bed is completely leveled at -125 mm Z axis? EASY! Put on the new Easy Button tool, create a sequence that moves to the next plant in the planned plant group, the Z axis moves downwards until the easy button is pressed by the soil, (Farmbot Software saves variable as the plant’s Z axis).

You are now good to start a planting sequence to your plant’s required seed depth without needing to make sure the soil is level across the entire bed.

1 Like

“top secret prototypes” sounds great. The possibility to adjust the z-axis to the sensor seems to be a good idea - although there might be scenarios where you want to record the height for later use (let’s say for soil measurements when the plants are already obstructing the sensor). Does your comment imply that it might be worth to wait for your new sensor before starting something or would it be helpful to do experiments?

@aronrubin I’m exploring an API to support Digi’s XBee “ZigBee” devices on FBOS.

This could allow links to compatible XBee-enabled systems with actuators/sensors across a large urban “back yard” . . ( I’m thinking “Consumer-grade SCADA” ).

Hi @jsimmonds, xbee sounds like a good idea. I had a quick look and without understanding all the details of the different xbee types, I have the impression that the cost is rather elevated. If I understand correctly, we would need an 80$ xbee board to connect a 10$ ultrasonic distance sensor. Is that correct?

Experimentation is always welcome, given that FarmBot is an Open Source platform. If you are feeling curious and are willing to share your progress, we would be very excited to see what you find. Conversely, if you are unable to do such experiments, you can at least know that we’re already working on solutions for a future release. The main reason the distance sensor was not included in the 1.5 release was simply that there was already too much on our schedule and we felt that adding it would increase delays on higher priority features and commitments.

Hi @jensGeorgsen $90 / FarmBot Genesis v1.5 $4557 < 2% added cost :slight_smile:

@jsimmonds, sure, that’s definitely a point. Then the design would be to have some kind of microcontroller on the farmbot tool arm, collecting data from the possibly different sensors and sending it via xbee to the farmduino?

@RickCarlino I believe that a distance sensor would be a critical part to make the system fully automatic and usable for a broader user group. We have the intention to contribute but in order to optimize the progress of the project, we would like to avoid double work. So if you are working on this is, we might focus on a different area.

@RickCarlino, @jsimmonds, what about using an esp32 and Bluetooth for communication? I understand that the raspi has integrated Bluetooth and the esp32 has, too. Bluetooth should also be fine for the distance. Would that be okay for the system design or should all sensors go to the farmduino?

@jensGeorgsen Although we have no plans to use the ESP32 or bluetooth in official hardware, we might be able to add support for Bluetooth if you have ideas for a third party / DIY project. I can’t say much beyond that, but tinkering is always a possibility with open hardware designs.

I think RS485 or CAN bus would be typical for realtime control. Other alternatives are USB, ethernet, and RS232. “Wait a minute, Aron. All of those are wired!” Yes, well devices need to be powered too, so no matter what, wires need to exist to ensure reliable power. As many times as I want to go wireless-first, I run into that simple truth on robotics projects.

Speaking of power, that also needs to be solved here. In recent years we have really useful power delivery (PD) protocols have been integrated into both USB-C and Ethernet (aka PoE). USB-C PD chips have become reasonably priced but USB-C hubs/power-injectors seem pretty rare. At this point in time, I think running a lower gauge 12V or 24V line out to a set of regulators and USB hub on the Z-axis column would be the fastest and cheapest.

Ultimately the VL53L1X and many other devices use I2C, UART, or SPI. I also include lights, servos, and other actuators in that mix. I am going to use a Teensy 4.1 as the “hub” on the Z-axis column because I can trust its ADCs and PWM for the soil moisture and pH project. There are a few FTDI chips that would also be appropriate protocol bridges.

Hi @aronrubin,

I see your point about cabling and power supply - and this might exactly be the reason why wireless communication could be an advantage. If you pass 12V to the z-axis and convert to 5V or 3.3V there, a wireless connection might be better than a cable connection. What do you think?