The Combine Forum banner

261 - 280 of 4139 Posts

·
Registered
Joined
·
372 Posts
Good question. If you run as a server, then the same code could service connections from a couple of different devices (NMEA GPS as well as Arduino).

Thinking about an IP-based farm data bus, however, it might make the most sense for each data source to be a server and the consumer would be a client. That way multiple clients could interface with the same device, such as a GPS source.
I think generally the device generating/hosting the data should be the server but that may require more complicated code to handle simultaneous connections. That being said, while my bin temp reading system has the Arduinos setup as the servers, there are times when it would be better if my readers would be the client and my server computer would actually run as a server. For example, now I have to setup my server computer to connect to each temp reader individually (and setup port forwarding for off site readers), instead of just sitting and waiting for the readers to initiate the connection. On the other hand, the network/wifi to serial adapters I use are easier to use in server mode than in client mode. In client mode they would try to maintain a constant connection instead of periodic, short connections.
 

·
Registered
Joined
·
5,808 Posts
Discussion Starter #263
I think generally the device generating/hosting the data should be the server but that may require more complicated code to handle simultaneous connections. That being said, while my bin temp reading system has the Arduinos setup as the servers, there are times when it would be better if my readers would be the client and my server computer would actually run as a server. For example, now I have to setup my server computer to connect to each temp reader individually (and setup port forwarding for off site readers), instead of just sitting and waiting for the readers to initiate the connection. On the other hand, the network/wifi to serial adapters I use are easier to use in server mode than in client mode. In client mode they would try to maintain a constant connection instead of periodic, short connections.
First of all, i know nothing about networking. That said, i've tried programming both ways. Now, the most important thing that keeps running is AgOpenGPS, it is always run no matter what. None of the "support connections" make any sense without it. While always desiring to be attached Matt, in the case of your serial adapters, using TCP with its addressing and confirmation of data sent is a reallly really good thing in this case. We want to know its connected and if not, immediately reconnect. Something almost impossible with rs232 it seems.

If a separate server is run now everything has to be read by the server and then either specifically broadcast to specific apps or a multicast approach - but then everything is rebroadcast twice - add to that the echo confirmation and the network is spending most of its time talking to itself.

Connection to the server isn't a big deal if AgOpen is a client. But now there is a separate application running.

It just seems a lot simpler to have AgOpen as a server - but the beauty of LAN is if needed, can just create another purposeful server should the need arise.

Matt, have you written your servers/clients in c++? Are they fully non blocking multithreaded asynchronous applications?
 

·
Registered
Joined
·
3,756 Posts
I've done a fair amount of networking and network engineering in my day. Not so much socket programming, though.

The thing about the way GPS uses serial and even the way your relay arduino uses serial, if a connection drops for a bit, we don't need to care about the stuff that was missed. As soon as the data comes through again we carry on. It's not uncommon for wifi serial adapters (or serial over lan) to support UDP as well as TCP/IP. UDP has no error correction, so if a packet gets lost it gets lost. But the advantage of UDP is that it has no connection building and tearing down (no need for syn/ack handshake) like TCP/IP does. That makes it much easier to handle faults. With TCP/IP you'll have to make your code be able to re-establish connections when connections drop or time out. With UDP we don't have to worry about any of that. A serial device could just blast UDP packets at the AgOpenGPS machine and if the network was functioning, they'd show up.

I can go into more detail on TCP/IP vs UDP and how they react to lost packets if you want.

Anyway, just a FYI kind of thought. I'd say do what ever is easiest right now and we can improve it later, or come up with a better networking method.
 

·
Registered
Joined
·
3,756 Posts
If I was going to design an ethernet network for a tractor (with or without a wifi component), I'd probably put in a real layer 3 router switch at the top of the network that supports multicasting. Then any data stream source on the network can attach itself to a multicast address and start sending data immediately. Then client devices, such as AgOpenGPS could subscribe to the multicast channel and get the feed. The nice thing about multicast is that it's all handled by the layer 3 switch and it will only send those multicast packets to the devices who ask for it.

For automatic discovery of devices I'd probably employ mDNS (used to be Apple's Bonjour). It works quite well on a LAN. And if IPv6 was used, devices could self-configure addresses based on their MAC address, so DHCP wouldn't be required.

Anyway, pie in the sky stuff.
 

·
Registered
Joined
·
5,808 Posts
Discussion Starter #266
So does udp utilize more of an intelligent packet style rather then TCP? Data can arrive in any order from anywhere, complete or incomplete and parts and pieces. But would that only be an issue on a very busy and high traffic network?

In this application i don't see that being an issue. TCP worked flawless with one computer as simulator on wifi and a wired desktop running Agopen. The wifi one had 2 browser windows open with youtube running in each playing a movie. It only started to stutter once i copied a 1 gig file from wifi laptop to desktop.

The way its written is both serial and TCP just fill the data into the variable "receiveSentence". AgOpen doesn't know or even care where it comes from. In fact i ran both, a serial and TCP at the same time into it and the fix just jumped around as it thought it was in two places at once, which it was. Kinda neat - and universal.

In reading about programming this stuff it is generally agreed, it is difficult. I concur. I gotta get some of this stuff up so you guys can look at code and fiddle.
 

·
Registered
Joined
·
3,756 Posts
Correct. UDP does not have any inherent connection or error-correction data. There's no guarantee about the order of packets or whether they'll arrive at all.

If you had network congestion to the point that UDP packets were dropping or out of order, you'd likely find that the latency of TCP/IP connections would be extremely high (delays in getting the data), which can cause its own kind of issues. I guess all I am saying is that using TCP/IP is fine, but just keep in mind that AgOpenGPS has to deal with re-establishing the connection should it every drop or time out, if AgOpenGPs is going to be a client. If it's a server, then the serial to wifi devices have to worry about that.

Sounds good the way you've implemented things. It's good to have the code written such that the data streams can come from any source.
 

·
Registered
Joined
·
5,808 Posts
Discussion Starter #268 (Edited)
Up on the Git. Includes a TCP version of AgSim.

Lots of changes, hopefully much smoother and more logical interface. The server in AgOpenGPS runs as soon as the application is started. It uses port 7777. To zoom in and out click or touch the left half or the right half of the screen. No more zoom buttons

If you want your own textured background, make a tileable 256x256 png file and replace floor.png in the dependencies folder.

Up next.... figuring out UDP asynchronous socket programming. Yuck.

https://github.com/farmerbriantee/AgOpenGPS

Revision log:
v1.3.1.1 Dec 1 2016
* TCP server added. Port 7777
* tileable textures for field surface
* WebCam support
* New and close job are now; resume - new - open; in its own dialog
* exiting asks if you want to save field if one is open
* custom timeout message dialog - non modal
* custom YesNo dialog for save
* fixed AB line setting, must drive a ways before setting B point.
* Set Auto Manual buttons on to off if other turned on to be easier
* individual section buttons * added zoom by touching left or right side of screen
* removed most divides with multiply, constants for pi/2 and 2 PI etc
* Tool now has Red for Off, Yellow for ON, and Green for Auto, matching the buttons
* Sections are in control of on off request now, not buttons. Buttons simply change button states of sections
 

·
Registered
Joined
·
3,756 Posts
Sorry to bring up the UDP stuff! May not be worth exploring. It all depends on what protocols the Serial to Wifi adapters you want to use work with. Most/all do support tcp/ip, so probably keep on going with what you've got until problems appear.

For lookahead stuff you could look at my diffs to see what I added (it's very minor). And/or I could re-integrate my stuff in a few days and then you can pull from that. Whatever you'd like. Below are the two commits that contain all the look-ahead logic:

Here're the changes to CSection.cs and vec3.cs:
https://github.com/torriem/AgOpenGPS/commit/2cc6fec8287d122a198a344ecad72eb90af067bc
- added some vector operations such as subtract, normalize, magnitude, and heading
- added logic to csection to compute speeds of each section
- requires always calling AddPathPoint, even if section is off, but the section itself knows if it's off or on so it won't draw triangles if it's off. In other words we don't need to do that check in SerialComm.designer.

And here are the changes to OpenGL.designer and Serial.Comm.designer:
https://github.com/torriem/AgOpenGPS/commit/d9c1e6ae7b1c7586b42c77703b7edfcee33e1834
- no longer do any calculations regarding lookahead distance here. Instead the section object itself does that now
- serialcomm code just calls AddPathPoint on each section, and then the CalculateSpeed method which figures it out for us.

If you turn on "split" view on these diffs I think you'll be able to see what I added or removed/commented out.

I'll plan to pull merge your latest commits into mine in the next couple of days, but I think what I've linked to here should be easy to follow.
 

·
Registered
Joined
·
5,808 Posts
Discussion Starter #271
Warren i can't seem to reply to your message oddly, but here is my answer in regards to manual input back to control mapping from hydraulic equipment.

Absolutely. I think that is the next thing on the list actually. Deciding on the route to go whether that is one of those relay boards, an arduino or something else. I am certainly in favour of a relay board as it already has inputs and relays for outputs and would require no building - just plug it in. Did you get one of those USB relay boards? I need to order one.

Been quite the adventure with the ethernet networking stuff. Shows tremendous possibilities, but have been "wasting" time on it lol.
 

·
Registered
Joined
·
496 Posts
Warren i can't seem to reply to your message oddly, but here is my answer in regards to manual input back to control mapping from hydraulic equipment.

Absolutely. I think that is the next thing on the list actually. Deciding on the route to go whether that is one of those relay boards, an arduino or something else. I am certainly in favour of a relay board as it already has inputs and relays for outputs and would require no building - just plug it in. Did you get one of those USB relay boards? I need to order one.
I did get the message, actually twice ..

I just thought that using a mechanical switch on depth controlled equipment to enable mapping would turn your project into a 'year round' usable final product..

The manual ON mode is sufficient as is for equipment without depth control such as harrows, etc . while things like a valmar can just tap off the electric clutch actuation to show 'applied' mapping features

I just got the relay board, eight port, in today.. but I'm not sure if running the depth switch through that would work as most relay boards don't have inputs except for actuating the relays ..

I imagine an unused digital port on the Arduino would work fine, and unused analog ports can be re-designated for digital as well, [but not the other way around], with just an inline protection resistor and reverse diode to drop the voltage a bit as make / break spikes are quite likely ..

While I'm at it, a display can easily be added right on the Arduino enclosure to display visible section actuation by the relays as well as implement mounted switches, cost is about five bucks canadian, and there is still lots of code room in your .ino file ..

At the cost of the hardware [minus tablet ], it would be quite feasible to permanently mount the Arduino subsystem and GPS antenna to any desired piece of motorized equipment..

It will probably need a host PCB for the Arduino, basically just for larger connection points and normal screw connectors, will make it much easier for the average user to hook up, easily done
 

·
Registered
Joined
·
5,808 Posts
Discussion Starter #273
Well there ya go! Twice lol.

MAny of the relay boards i looked at also had inputs. Does yours?

What species is it?
 

·
Registered
Joined
·
496 Posts
Well there ya go! Twice lol.

MAny of the relay boards i looked at also had inputs. Does yours?

What species is it?
Mine has only inputs that drive the relays ... it was $6.35 CDN

5V 1/2/4/8 Channel Relay Board Module Optocoupler LED for Arduino PiC ARM AVRC | eBay

Later on I found a six channel, which would be a better usage fit for this project, a bit smaller size, for twenty cents more ..
5V 1/2/4/6/8 Channel Relay Board Module Optocoupler LED for Arduino Exquisite | eBay

The first one is intended for a friend to do fan and or heater turn on [through standard 220v contactors] from thermistors and moisture sensor chains in a couple of bins of his .. another 'in progress' project :)
 

·
Registered
Joined
·
5,808 Posts
Discussion Starter #275 (Edited)

·
Registered
Joined
·
496 Posts
Well, not sure about that style ..
First of all, the arduino has maybe 5 digital and six analog pins sitting un-used ..
But I do see an advantage to that type of USB relay / IO module .. no Arduino programming needed, just some [more] code change on your part, the Arduino can be tossed, easy hookup for the USB relay, much faster installation, it's already pre-built...
Drawback is cost, say with the 8 channel solid state, final cost would be around $200 or so [$119 US, shipping, exchange, taxes], with possibly having to rely on single source supply..
You could actually run either with a toggle choice in the setup menu ... Select Arduino/Relay, or Select USB Relay I/O
 

·
Registered
Joined
·
5,808 Posts
Discussion Starter #277
Well, not sure about that style ..
First of all, the arduino has maybe 5 digital and six analog pins sitting un-used ..
But I do see an advantage to that type of USB relay / IO module .. no Arduino programming needed, just some [more] code change on your part, the Arduino can be tossed, easy hookup for the USB relay, much faster installation, it's already pre-built...
Drawback is cost, say with the 8 channel solid state, final cost would be around $200 or so [$119 US, shipping, exchange, taxes], with possibly having to rely on single source supply..
You could actually run either with a toggle choice in the setup menu ... Select Arduino/Relay, or Select USB Relay I/O
That's where the plugins concept is great. All protocols for connection to whatever device are the same, the plugin then is the translator as a DLL and its read in when the program starts.

They are about 50$ us for 4 relay with multiple IO and a/d.
 

·
Registered
Joined
·
5,808 Posts
Discussion Starter #279 (Edited)
hi brian!

can i test agopengps without a gps antenna? i see you have agsim - but how do i connect agsim with agopengps?

the software looks nice!

best regards andreas!
you need either a pair of usb to rs232 adapters and a null modem cable to connect them, yuck.

or.........

just use AgSimIP and use TCP to connect to AgOpenGPS. Yup, AgOpenGPS has a server built into it now. Port 7777 and put in your computers' ip as your ip address in AgSim. Nothing to set in Agopen, just make sure its running first cuz its the server.
 

·
Registered
Joined
·
5,808 Posts
Discussion Starter #280
Toughest bug yet! An internet cookie for who can figure out what's wrong with this code.

Code:
vec3 left = leftPoint - lastLeftPoint;

delta = Math.PI - Math.Abs(Math.Abs(left.HeadingXZ() - toolHeading) - Math.PI)

       public double HeadingXZ() {
            return Math.Atan2(x,z);
        }
 
261 - 280 of 4139 Posts
Top