I like my simple USB and it’s never given me any trouble. All the udp stuff would be new to me. However, I guess I managed to somehow get AOG working in the first place and for a while it all seemed way WAY over my head!!! So maybe I could figure out another new step.
I also like the idea of the new boards, but to be honest the part I’ve enjoyed most while learning to build AOG was the soldering and putting together my pcbs. I think I would actually miss that part with the fully smd boards. I bet they look a lot nicer than mine though!
UDP has been totally 100% reliable for me. USB almost always causes some disconnects now and then.
I think the GPS and AUTOSTEER should be in one module. And then put the machine control modules on implement with one connection to tractor
Some good points and hopefully some good answers I can give as i read comments.
CAN - yes it is easy to think you can just hook everything together and it is. The problem is there is no software to to separate all the chatter (it is called the stack same as ethernet) to know who is talking and who is listening and deal with collisions and priority and so on. None of which is written. Ethernet comes that way with a stack and with a teensy, it already has full ethernet so you plug in a cable and voila you have a network.
V4 was simple because it was simple. V5 allowed running multiple applications on the same machine, forced accurate timing from your setup, where v4 didn’t care if you thought you 10 hz gps but actually ran at 7 hz. We all know that once you fix the problems in v5 - it just works.
As a second GPS is now added for tool steering, writing more and more com ports was not going to be the answer. That is the biggest difference with udp, you just add. Whereas with serial, every function needs a full serial port written, a way to connect it, see what com port is connected etc. Then that serial port needs to be added thru the whole program and sent info it and only it really needs.
Serial is like having a party where all your guests are in separate rooms and the host goes from room to room and if another guest shows up you need to make up another room Whereas with udp is everyone is in the same room visiting and new people can just enter and start chatting.
the choice of udp is obvious for all the reasons you mentioned I adopted it from the start to make my pixi-multis work. At the beginning I wanted a system connected in rs 232 for its solidity but not so simple to implement I did not want the USB too fragile .
I did not want a wireless solution either neither wifi nor bluetooh which has in my opinion this should be limited in a work environment.
So ethernet is my preferred solution
we often talk about all in one cards it is an interesting solution especially for those who want a plug and play solution but often the construction of such a card using smd components is not within the reach of a beginner and I am very attached to this self-construction side, that’s why I prefer specialized cards to connect to ethernet via a switch
even if configured a gps card in ethernet it is not complicated a pcb including gps, autoguiding and ethernet switch could be a good idea the machine part remaining independent
The board designs can be either way, here is a dual/single F9P based on the original V2 and Kaupoi board with added F9P’s mostly all in one. This is thru hole design - easy to solder and build.
With regards to your points on message collisions in CAN, is this not dealt with at the hardware level with no software required anyway? The arbitration field sorts out which message wins (lower IDs have priority due to 0 being dominant). In the very rare case where two transceivers begin transmitting at the same time (normally the tranceivers are aware that there is a message transmission in progress will wait), the ‘losing’ tranceiver knows if the message it tried to send has been overriden by another more dominant message and again it stops and waits untill the bus is clear.
I have attached a short demo video of how I have implemented wireless UDP into OpengradeX, not at all saying it would be as easy or or possible in AOG as I haven’t looked through that code base much but a good proof of concept. The Usb running into both modules is for power only and no data transfers over them. The bottom breadboard is a a module for controlling a couple SCV’s on tractors. It also connects wirelessly and gets all its info from the network no cables required. The antenna module (which has an IMU in it) is then able to be mounted on the scraper mast and relay all info back to the Tablet in the tractor. (any latency noticed in the video is result of poor video editing skills, real life the data transfer is instant)
Hello ,
I just put my opinion. I won’t talk about technique, most of you are beyond me. I will therefore speak as a user.
AGO has reached a level where I cannot imagine using another autoguiding solution.
I am for evolution, and UDP seems to me the way. The Ethernet speed, the barrier of distance, the low cost of the material, the ease of finding components widely used in all areas, are points that eliminate other solutions. CAN is beautiful for isobus , but so closed is finally not so fast , nor so beautiful as ethernet… Watch the loading time of an implement in the VT of your tractor !!
I am however a USB user, for the moment, but if UDP makes it possible to go further in your desires for the development of AGO, for example as mentioned by brian computer vision, it is necessary to go in this direction.
Ethernet is something very common.
Please keep commenting, your thoughts are driving important decisions. It appears like we don’t have anyone scared of using Ethernet/uDp. That is great news.
I hope the best for everyone. Great things coming from Brian and team. Hold in there I promise miles of discussion has been had on developers site trying to find the best options for you all.
I’d like a hand to hold for setting up udp. Is there a video on this? I think the gps and auto steer should be separate to the machine and imu module. But maybe have the auto steer board be capable of turning off 1 section?
UDP works very well for me, USB ports are somewhat amateurish and unsafe for this system, tractor vibrations due to terrain and the expansion of USB port over time make the system unsafe, what if we can connect an IP camera to the switch and use it to see the equipment behind on the AOG screen while using UDP. it would be fine.
It can be either a router or a switch. Router being the one, maybe poorly named, that includes wifi. It would allow a wifi connected esp32 for example way back on the tool wirelessly.
In AgraBot, i used wifi and wired so i could keep an eye on AOG in the robot tractor rolling seeded peas using TeamViewer to see what was going on on my phone while i was in the other tractor seeding. This would not be possible with serial
