Communication between multiple OWLs for updating/logging/monitoring

[geezacoleman]

Currently for a multi-OWL system every unit is entirely independent. Communication between OWLs for easy updates/monitoring from a central location and powering on/off would be a considerable improvement.

Requires:

• addition of hardware (cables)
• comms protocols
• ?

[EchelonMirror]

Interface shouldn't be too much of an issue. Physical (ethernet) just means you need a switch, which can be annoying since so many are AC based. Wifi has the issue of interference from machines (i.e. high ping, dropped packets, devices falling off the network).

Comms protocol recommended would be MQTT. Will write something up over the next couple of months that works good enough for OWL.

[bassyboi]

Would rsync be an option?? Using ssh???

[geezacoleman]

I think rsync may be an option for wireless transfer of data off the OWL when collecting images, but for comms and controlling multiple from a centralised cab controller, then MQTT or CAN might be better. I'm no expert on this though, perhaps @EchelonMirror has some ideas on it.

[EchelonMirror]

If you want to manually do stuff, ssh and rsync will work. But for scale and a system that will ultimately do more, I would concur with @geezacoleman on this one

[bassyboi]

All sounds interesting definitely keep up the good work you got me hooked on the idea!!!

[bassyboi]

CAN bus command codes

CAN_COMMANDS = { 0x301: "pause", 0x302: "play", 0x303: "boom_flush", 0x304: "stop", 0x305: "save_config"

can we come up with more please 🙏 I’m currently working on this uses both wifi and lan

[geezacoleman]

Yes - this is a very good idea. A CAN library is something we'll develop for centralised control. I'm more and more thinking CAN is the way to go with a lot more simplicity/lower cost in hardware/architecture. Only two wires needed on the bus instead of a whole ethernet network for MQTT, and as you've already provided - it could be integrated into the existing OWL HAT for ease of use.

[EchelonMirror]

It will limit what you can do. With a speed limit of about 1mbps for the whole bus. With that said, if you just want a control system then that is a fine approach.

Though you will need to consider a faster version if you want to do image streaming etc

[geezacoleman]

Image streaming/model updates (probably most important) are the main reasons for an ethernet-based system, but I'm not sure if that outweighs the extra hassle of setup. It's a bit of a roundabout I'm on deciding which one to commit to. Perhaps support both? Start with CAN as the low cost, simple setup then move to ethernet for more advanced systems but with a lot of added cost.

[EchelonMirror]

Sounds like a plan.

Unfortunately I’ve taken the opposite path and done MQTT on Ethernet/Wifi with CANbus mod later on.

[MisterHW]

an ethernet-based system, but I'm not sure if that outweighs the extra hassle of setup

Assuming "hassle of setup" refers to hardware - I've used KSZ8873 (and will upgrade to KSZ9563) 3-port switch ICs in applications where multiple units are daisychained before connecting to an external ethernet switch. Pi-based builds could also use AX88179 or similar USB-GigE adapters with bridging to reduce the amount of cables running along the boom. So a + in the "wiring hassle" and a - in the "system cost" category for such an approach.

[EchelonMirror]

Daisy chaining is fun and a terrific idea to reduce the overall cabling requirements. Though bottlenecks will occur if you pull a lot of data across the network (1000mbps = 125MB/s).

If this isn’t an issue you only need one Ethernet switch. Bilberry has three Ethernet switches on their solution.

[EchelonMirror]

https://www.autopi.io/blog/discover-hidden-functions-in-your-car-with-can-bus/

I do wonder how well this would work for most JD hardware

[bassyboi]

What I was thinking with the can bus is only using the messages… I don’t think you would use it as a camera feed or upload or update!!

I’d just set up all the raspberrypi with like all the configuration files already set up and use canbus protocols to flick through them..

What is it called when you make the raspberrypi or computer make there own wifi I was watching a YouTube video a while ago and I can’t find it now but could something like that with ssh or something for updates work??

[bassyboi]

@EchelonMirror jd uses isobus protocols which are in hexadecimal there is an open source community out there agisostack they run 2 cans implement and machine if you want to owl on jd interface id recommend looking them up!!

[EchelonMirror]

Im Running an Ethernet variant on a 36m system.

Avoided doing anything CAN/ISO because of the variances with different manufacturers. But I’m thinking of an MCU that plugs into JD machines (ISO one end ETH on the other).

Work in progress. Get to a stable desirable point then experiment with the ISObus when I have the time/resources.

[bassyboi]

@EchelonMirror if you are interested in a board with can bus interface I have used the design off guys board and put a can bus part into it?

But I’d definitely like to see your system running sounds interesting! I wonder if you use the comp ports in on jd? I actually have no clue what you can do with them other the use that fertiliser vision thing that yara has!! But then again it’s jd!!!

Im 100 percent confident you can somehow get the command centre to show the ui on any system!! I know this because we needed to update a air seeder and jd didn’t have the capabilities to update it and we tried Trimble and the user interface came up and ended up getting the dealer out with a tropcon screen to update it!! And yes I know what your saying updates are slow through can bus!!

[EchelonMirror]

I’m running NVIDIA hardware so the CANbus is already available as output on the board if I wanted to tap into that.

I had no idea how integrate the CANbus originally and it wasn’t attractive as an option when a completely stand alone system running on wifi/ethernet utilising MQTT for control would get the job done. I wanted individual nozzle control, so it was best that I had a unit which was self contained.

Partly I wanted to avoid using the displays, because I wanted more control of the user experience. I have created more work for myself but I now have a faster turn around time where I can run the entire thing wirelessly via a tablet.

The future likely looks like having an MCU connected from the ISOport to Ethernet. With an MQTT-to-CAN library inside basically acting as a bit of a man-in-the-middle.

[bassyboi]

I’m wondering if we should be making both paths I’m sure both paths would work!! I like the idea that canbus has minimal overhead!!

But I see where you are coming from also are you going to publish your work??

I like to write every idea down and sharing them!! Feed back does help build better products for everyone to enjoy…

[EchelonMirror]

I will publish when I get around to it. The approach I originally took required making some NVIDIA drivers and ROS2 ports plus an entire MQTT rollout so I could control the whole thing from a tablet. A design approach I was growing to hate.

Last three months have been this blitz mode switching out form an older design to an improved design (in terms of software and hardware) since we got some decent feedback from a couple of on farm operators.

Both are former engineers turned farm hands - so they had a lot of know-how to reduce complexity of parts, improve fabrication and stability, as well as great feedback on how to improve UI. My word of advice to anyone and everyone is if you’re designing a system look at the people who are implementing it and working with it on a daily basis as they will be your biggest evangelist.

I will likely supply a dev kit at the end of the year with some cheap solenoids (Arag and TeeJet - HF 9L/min 30hz PWM) so you can do your own thing with a smaller platform.

[bassyboi]

That sounds super interesting!!! Yeah definitely!! I’m definitely interested in what you’re saying. Nckbass218@gmail.com if you want to chat?

Sounds like you have some serious progress