Yes, indeed that’s the current “state of the art” for low cost projects.
The XBee use case I mentioned was to control self-powered “near field” things without wires such as ventilation louvres and humidity control in a large-ish greenhouse, for example.
Yes, I like that one ! Going USB back into the Pi ?
I have used the extra wires to the UTM to power and control other sensors etc on tools, they work well. It shouldn’t be too hard to wire up a distance sensor. Reading and interpreting the output is the interesting part.
I consider it a hack but I have daisy chained another Arduino powered off a spare Farmduino periferal 24v port via a voltage regulator. This gives me an easy way to quickly write code to control sensor inputs and interpret outputs. I can then also turn sensors on and off via the periferal port. I did this hack as I’m very time poor. It’s good for prototyping stuff quickly.
Hope that helps.
I just discovered the NXP PCA9615 which converts I2C into differential I2C and power in an ethernet cable. Sparkfun has a breakout for it. This may be the best long-term method if others are looking to integrate sensors, lights, and servos. I will research more and report. I have no idea how any of the methods would be integrated with FBOS.
That sounds like a good idea, @aronrubin. Would it be possible to get the values from i2c to the webUI?
There is a port on the farmduino labeled I2C so that is a start. I am sure @RickCarlino is not too busy to add I2C register reading/writing along side analog and digital pin I/O in the software side 
. Honestly, I would love to help out on the C/C++ side of the equation. I could imagine a setup where “microdrivers” existed for devices that needed more than single reads and writes to complete an operation (i.e. state management around operations)
Building a tool for distance measuring using the hc-sr204. wondering if i should attempt to use the farmbot ecosystem or hook up to my own jetson nano /raspberry pi 4. advantage of the farmbot of course is the pinout connectors to the farmduino, the challenge is the trig and echo connection and programming. hence I may go it alone for time being…
@aronrubin I like the sound of the microdriver idea. Memory consumption would be a big concern, as it has been in the past, but this is definitely worth exploring. If you are interested in running your own experiments and have questions, feel free to PM me.
I switched to a lidar sensor(http://en.benewake.com/product/detail/5c345cd0e5b3a844c472329b.html)
a bit more weather proof, set it up on the secondary Raspberry Pi using a USB to UART adapter.
I have used the TFmini plus before. It is a nice bit of kit that delivers readings without noise.
Nice! I can think of a lot of applications with that piece of kit. Have you integrated it to control the steppers yet?
Two quick question(s) 
Ubuntu 18.04 64bit , looking at 20.04 in a next release
Currently taped to the UTM…and it has shown distance from ground, however, I may have a different use case, The design for the lidar is to identify distance to a plant from a horizontal perspective, the 3d scanner I chose to work with is an Occipital core device(s) and it works really well if you start with a set distance before it takes over to measure objects and then later distance. I call it a distance primer. and dealing with variables such as plant growth. I need to get the camera to start at nearly consistent location relative to the plant. All that said, its going on a Pan-Tilt kit and can be pointed downward. Again, the design doesn’t need to integrate to the steppers, but could pass a value to your MQTT message host. Having the secondary Raspberry Pi opens up a lot of possibilities as one can code in some freedom and with the design of the farmbot eco-system which allows for external manipulation of the devices, its a debate for me when to physically leverage and interact with the UTM/farmduino and when to remotely in building my “mod’s”.
see other response, no need to in this design goal
