New Tool: Laser distance sensor

I want to build a tool for measuring the distance between the tool head and plants or soil beneath it. I ordered a TOF10120 laser distance sensor for the task which should arrive any day. The module can communicate either via UART or i₂c.

My question is: What is the best way to transfer the measurement to the FarmBot?

I see the following options:

  • Add a Arduino Nano to the tool which reads the sensor data and uses its PWM output to generate an analog signal which is transferred to the farm bot on the same analog pin which is used by the soil sensor.
  • Connect some two additional pins of the UTM to connect the sensor directly via i₂c. I fear the cable needs to be too long for a clean connection. But I have never tried such long i₂c cables and there are chances that it works with very slow speed.
  • Connect some two additional pins of the UTM to connect the sensor directly via UART. UART is also not designed to work over long cables and the sensors baud rate of 9600 might be too much for long unshielded wires.
  • Add a Arduino Nano to the tool which reads the sensor and which transfers the measurement over a very slow serial connection on two additional pins of the UTM. This would have the benefit that the arduino could transfer additional measurements for example from a temperature sensor. Two sensors could share one tool this way.

Please let me know which of these options is the best in your eyes.
I’m also open to additional ideas how the sensor could be connected.

Why do I want such a tool?
With the laser sensor I could measure a grid of distances over the whole beet. The highest measurement in the range of a plant would be a good guess for the height of the plant (a useful information for a careful watering sequence and for evading collisions during optimized movements). The measurements in between the plants would be accurate measurements for the soil height.
I also hat problems with the weeder which easily produces dents in the soil. The new tool could measure the depth of the dent and adjust the weeding sequence accordingly.
Another usecase is more scientific: In theory the camera should be sufficient to make a depth estimation for every captured pixel in two or more images. This could be possible with unsupervised optical flow but that is hard to test with no ground-truth data. With such a sensor the FarmBot could automatically collect depth data for a dataset.

I will post my designs and schematics here as soon as I have them.


This is a great idea! I wanted to perform some experiments with a TOF laser also but have not had time yet. You have obviously done a fair amount of research on each possible design. I will try my best to address each one, but feel free to post follow ups if something doesn’t make sense.

Ardunio + PWM output: This is probably the best solution for the FBOS of today. You could read the GPIO from Lua or the sequence editor.

i₂c: As you mention, I would be a bit fearful of signal interference over such a long line. Additionally, I would need to make some updates to FBOS to allow for i₂c, possibly via a Lua scripting interface? :thinking_face: I welcome ideas on this approach.

UART: Like i₂c, this would require modification to FBOS, but we do like the idea of exposing a “UART Device” resource in the web app. Rory and I brainstormed some ideas for this a while back. One idea I had was to have a “UART Devices” page that allows you to set the baud rate, device name, etc… for multiple UART peripherals and then expose a send() and receive() function in the Lua sandbox. That’s just an idea though. I’m interested to hear yours if this is something you’ve considered.

For all the approaches above, I’m making the assumption that you don’t want to fork FBOS. If you are OK with forking FarmBot OS, then my advice would be to add a special handler to the Lua sandbox that does whatever you need it to do. I can point you to the relevant files if that’s what you are trying to do.

As a side note, we are also working on this problem using the soil height detection system and are working on a “soil height interpolation” system that will guess soil height at arbitrary locations by using a grid of sample points. Obviously, it won’t be as accurate as a laser, but it has the benefit of not requiring new hardware and it also supports legacy devices.

I wish you luck on this project and look forward to hearing about your progress. Please let me know if you have any questions. :tada:


At first glance the wires inside the UTM cable were not twisted in pairs and not shielded separately. So in this type of cable the biggest problem are neighbouring wires which act as small capacitors. The signal of the serial connection has to charge and discharge these small capacitors with every change in potential. However 5 volts are a relatively high voltage for inter chip communication which allows for some degradation of signal levels. I guess it simply works OK if the baud rate is slow enough.

With i₂c the master can lower the communication speed with the clock signal and most slaves will work relaibly with relatively slow speeds. I think i₂c is the best option if we want simple tools without an additional microcontroller.

However microcontroller boards like a Arduino Nano are very cheap and they could prescale sensor readings which might be handy for some sensors. With the option to mechanically switch tool heads we do not need a serial connection with multiple slaves. So a simple UART connection would have the benefit of full duplex communication. It is also quite easy to use and there is no need for address discovery.

I think it would be great to have support for UART sensors in FBOS. Just make the baud rate configurable so one can lower it if the communication is unstable. Chances are that 9600 baud just work fine over the length of the UTM cable.

Please keep in mind that tools with serial communication could contain several sensors. So at the receiving end the different readings should be selectable. This could be done with transferring json strings on the serial connection. Processing json is already supported in the lua sandbox in FBOS.

Next steps for the sensor

For the laser distance sensor I will start with an Arduino Nano which generates an analog signal. For now I do not want to fork FarmBot OS. This design can easily be modified to use serial communication with configurable baud rate. I will be happy to test a new UART communication feature in FBOS if it gets available.


Thanks for the feedback @pinae ! We will keep this in mind as we plan that feature. A few research users have requested this feature also so we are strongly considering it.

One idea I had to deal with cable length problems was to use RS-485 (which, as I understand, is better suited for transmission up to 1.2km).

On the RPi side, an RS485-to-USB converter could be used, and on the MCU side, a TTL-to-RS485 breakout (a few dollars on sites like Amazon). So far I’ve only tested this idea on my desk at short distances. I can’t yet say if it will work well over a UTM cable.

1 Like

Sounds good! I will add a TTL-to-RS485 board to my sensor to be able to use it as soon as the new FBOS feature is available. Do you already have a plan which pins of the UTM you want to use for the serial connection?

@pinae Great! I am going to see if I can get a beta Lua function added soon (possibly in v14.0.0 / 14.1.0).

As far as pin assignment goes, if you want to stay compatible with the upcoming 1.6 release, I would recommend using pins F, G, I, J, or K for custom tools.

In v1.6, L is reserved for PE (protected earth) and E and H are reserved for Rotary Tool motor control.

1 Like

@pinae I have a very minimal prototype for you. It will be available for testing in v14.0.0-rc48 on the beta release channel.

Although it works, there are some issues currently:

  • Because FBOS isn’t “accustomed” to having UART devices plugged in aside from the Farmduino, there is contention over which device is the Farmduino and which one isn’t. For now, I recommend not plugging in custom UART devices until after the device has booted. That way, FBOS has time to connect to the Farmduino. I can fix this in a later release.
  • I did not spend a lot of time testing uart.write(). The only device I had on hand for testing was a UART GPS/GNSS receiver (RX only). I appreciate bug reports!
  • I am unsure if the OS is releasing the UART devices properly.

Here’s some example code:

list = uart.list()
list_json = json.encode(list)
msg = "UART List: " .. list_json
send_message("info", msg, "toast")

-- device name, baud rate:
uart, error ="ttyACM1", 115200)

if error then
    send_message("error", error, "toast")
    -- Wait 60s for data...
    string, error2 =
    if error2 then
        send_message("error", error2, "toast")
        send_message("info", string, "toast")

error3 = uart.write("Hello, world!")
if error3 then
    -- Handle errors etc..

RC48 is available now as a beta release.


How do I update to the beta release? The way described in the documentation does not work. When I try to open a “device” panel the webapp complains with “Page Not Found.”

Do you have a link to the RS485-to-USB converter you used? I have the RS485 board for the tool (the laser sensor is still on its way from china) but I haven’t ordered the USB converter for the raspberry pi.

Good catch, you can find it in the device settings now.
Settings page

Thanks @Ascend , and thanks @pinae for catching that out-of-date documentation entry. I’ve added a note to my TODO list.

The USB adapter can be found here. I have not tried mixing these adapters with RS485 boards from other manufacturers, but I assume they should interoperate. In my case, I was using it for a non-FarmBot related project.

@pinae Were you able to install the beta release?

I switched to the beta yesterday evening. So far it looks really good! At first glance the issue with negative encoder values is fixed. Now I can start debugging the motor currents and check for mechanical blocks because I get failed movements.

I ordered the USB-to-RS485-converter a minute ago and I am still waiting for the laser sensor. I will post an update here when I was able to build a prototype for the tool. Without it I can not test the new UART feature. You were faster than I expected to implement the feature!


@pinae Quick update: I added a .close() method to UART objects. It will be available in RC49 or RC50.

UPDATE: RC50 was just published to the alpha channel. It is on alphabecause I still need to perform QA.