Ag Geek Speak

From Pitcher to Programmer: Hudson Fuller's Journey pt. 1

• A Podcast for Precision Agriculture Geeks • Season 2 • Episode 7

Share episode

Hudson Fuller, GK Technology's newest full-time employee and computer science graduate, shares his journey from baseball player to agricultural data specialist working on the ADAPT standard integration.

• Hudson's connection to GK began through family ties and company retreats before pursuing internships during college
• Completed a computer science degree at Dakota State University while playing college baseball
• Created an AI baseball pitch predictor that achieved 80% accuracy in predicting pitch outcomes
• Currently coaches high school baseball and plays for the local amateur team
• Working on implementing the ADAPT standard to unify agricultural data formats across different systems in ADMS
• ADAPT aims to standardize how agricultural data is stored and transferred between different controllers and software
• The standardization is similar to how hydraulic hookups were standardized to allow equipment compatibility
• Different file types (shapefiles, GeoJSON, ISO XML) serve different purposes in storing agricultural data
• Modern controllers can process thousands of data points instantly to vary application rates accurately

Join us for part two of our conversation with Hudson in the next episode of Ag Geek Speak.


Sarah:

And now it's time for a Geek Speak with GK Technology's, Sarah and Jodi, friends and I can't wait to get in the fields again.

Hudson Fuller:

No, I can't wait to get in the fields again.

Jodi:

Welcome back to Ag Geek Speak and welcome to a very fantastic episode. We have a very special guest with us today, hudson Fuller, who, as of right now, beginning of May, is our newest full-time employee, so we're super excited to have on the podcast to talk about his background. He is a recent graduate in computer science and I'll let him talk more about his background there and also someone that's working very closely with integrating ADAPT standard into ADMS, and Hudson's going to give us a lowdown on that and talk more about how we get data from our ag equipment into our computer. So we're really looking forward to this episode and we know that Hudson will have a lot of fantastic information for all of you listening to the podcast. So with that, hudson, do you want to give a little bit about where you're from, how you may have become familiar with GK technology in the first place, because for those very keen observers, hudson's last name may sound a little familiar to those that have worked for GK for a while.

Hudson Fuller:

Yeah, so I'm Hudson Fuller, as Jodi stated, and I'm from Clark, south Dakota, and I was first introduced to GK at the first company retreat I got to go to.

Hudson Fuller:

As we're a very family oriented company and the kids get to come along and my dad works for GK. That was really the first time I got integrated in with Darren and Kelly and got introduced to them. And then got to my sophomore year of college and thing I was looking around for internships in the area and I figured I might as well talk to Darren because I knew I enjoyed the outdoors and agriculture fit right in with that. But I also loved the, the nerd stuff with the computer science. And I talked to Darren and he was willing to give me an internship for that summer where my main focus was working on the first version of Adapt. And from there, fast forward to the next summer I worked with GK again as an intern, also working on Adapt. However, it was a newer version of Adapt where they completely rebranded everything and then, following that, they decided to give me a full-time offer in December. I accepted it and started to work here in January.

Sarah:

So wow, there's a lot there, hudson, that's a lot. So my first question for you is how old were you when you went to your first GK retreat, the GK Technology Inc. We go on a company retreat every summer. It's about a week long, it's our company meetings for the year, annual meetings, where we really get a chance to like hash through everything for the year and where we're going to go for the future. And you know, as Hudson said, that's when family gets to come in. But how old were you on your first company retreat?

Hudson Fuller:

I was 17. Yep, some of them have been there a lot longer than I have. It just never worked out the first couple of years of the retreat for me to get to go. But I got to go 17, right after graduating high school.

Sarah:

That's awesome. Okay, and what was your favorite thing that you got to do for fun on that retreat?

Hudson Fuller:

It was probably. It was in Montana, up in the Billings area and we went to a natural land bridge and my favorite. That was my favorite destination that we went and did and it was cool because I was able to throw our rock across the land bridge, get it across the whole canyon.

Jodi:

I like that reasoning.

Sarah:

That's probably because you might know a little something about baseball and throwing a baseball. Yep, I like that reasoning. That's probably because you might know a little something about baseball and throwing a baseball.

Hudson Fuller:

Yep, I played college baseball for three years and played throughout high school and everything else at Dakota State University.

Sarah:

Awesome. So, speaking of Dakota State University, what did you major in? I don't think my computer science description was really encompassing of what your major was. What did you major in, and was that first what you started in? Tell us more.

Hudson Fuller:

Yeah, so my major was computer science actually. Yep, you got it right and then no, that's what I started with. At first I was pretty sure I liked computers enough to do it, but once I got into some of the classes where you actually were hands-on doing stuff with computers, I realized that I actually enjoyed doing it a lot. It didn't feel like I was in school, it just felt like I was learning something for fun.

Sarah:

We are certainly glad that we have you around here to solve all of our programming issues, and you think it's fun. That's great.

Jodi:

So what does that encompass? Do you learn a little bit about coding, about the hardware Maybe? What was your favorite class going through the whole computer science degree program? What was your favorite specific class out of that?

Hudson Fuller:

Yeah. So going through it was pretty much all about coding and then the theory behind coding. It was pretty much all about coding and then the theory behind coding. Some classes were every week you'd have some sort of coding assignment where you'd have to make something. Other classes it was more about do you understand how this idea works, writing it out on a piece of paper. And then, as far as my favorite class, it was probably in my last semester, it was a software engineering class because it was all about one big group project, basically the whole semester, and it was my first real introduction to group work in a code system. But my two internships with GK I was kind of off on my little lonesome working on the adapt because no one else understood C sharp, which is the programming language that adapt needs. So it was awesome to be able to work through different pieces at once to come together to a final. So it was an AI baseball pitch predictor.

Hudson Fuller:

So like the purpose of it was to predict which pitch you should use to trick the batter, or so it was more about say you knew you were going to throw a slider and then you could figure out, based on how hard it was where it was at in the strike zone and what the count was. It would figure out what the most likely outcome of that pitch was, whether it was getting put in play a strike or a ball.

Sarah:

So you could predict the strikes or the balls based on what pitch you were going to throw.

Hudson Fuller:

Yes, okay.

Jodi:

How accurate was it at predicting at the end?

Hudson Fuller:

It was between those three outcomes, it was, I think, 80%, which is quite good for baseball, Because baseball there's a lot of things that go into baseball and lucky things will happen that you can never predict.

Jodi:

That's really interesting. So you kind of need a database to do that right. Like you're kind of building like a regression model and like predicting response. Where did you, where'd you pull data from and like, were there any factors that like came out that were really predictive, that you didn't think they'd be? Or were you kind of limited on, like what you were pulling in for?

Hudson Fuller:

Yeah, so there is a website called Baseball Reference and it is for the nerds out there. It has everything from how much a pitch moves, exactly how hard it is, to how many times per minute it's spinning, and there is a library in Python that allows you to pull all of this data just almost instantly. And you can pull back to, I think, it's 2012. You could pull every pitch from that season, from a certain team, from a certain player. There's so many different ways that you could pull in the data, and that's where we struggled at first, because we could export it in an Excel spreadsheet just to see it, instead of trying to figure out by coding it what is actually in there. We thought that how much a pitch moved was going to have way more of an impact than it did. It ended up having almost a zero impact. It was way more about where in the strike zone that pitch actually was.

Sarah:

That's so cool, and did I hear you correctly a little bit earlier that you just called yourself a nerd?

Hudson Fuller:

Yes.

Sarah:

That's awesome. I mean, we at GK actually like to classify ourselves as geeks, but that's okay. I have also been known to be accused of being a nerd as well, so we're all in good company here. That's awesome.

Hudson Fuller:

Nerds make the world go around.

Sarah:

So do geeks. And here we are.

Jodi:

I love it because it's very similar to putting together a science project. Right you have a hypothesis of what you think is going to affect the outcome, right. And then you test it. In this case, you brought the data back, you looked at it, you built a model and found out that it was actually a different factor that influences it the most.

Sarah:

But on top of that is where you were talking about how there's a lot of data that's out there and, you know, sometimes in baseball there's some things that are just unpredictable and you just can't predict it. That really isn't that different from agriculture. There's a lot of things that we know, there's a lot of things that we deal with every day in the field and we base a lot of our decisions based in previous knowledge, in data that already exists. But sometimes there's things that just happen, right yeah.

Jodi:

That's a great point, Sarah, Because like, okay, so you've got all this data right, and I think we've been talking in agriculture for the past oh I don't know how many years ever since we've gotten yield monitors on combines. But we have a lot of data in agriculture now and it's kind of piecing through and figuring out what actually has value and what doesn't. And that's kind of exciting with AI right, because instead of having to choose what factors or like what data you're pulling in to build your models, you can now kind of bring everything in, as long as you have a library that's organized and I think we'll talk about that with Adapt but you can kind of look at all of it and figure out how that might predict final yield at the end of the season, and maybe that's a little bit too optimistic at this point in time, but that's cool. I think that's where the future is is using artificial intelligence to analyze a lot of the stuff that we have.

Sarah:

So lots of talk about baseball and data and how we're doing predicting what's going on with baseball. So, but you've been really active with baseball, so what tell us a little bit about, like what exactly your history with baseball has been?

Hudson Fuller:

Yeah. So the first memory any of my family and me have with baseball is me wanting to play t-ball when I was three, and we couldn't until I was four, and I was so upset at that point in time. It was one of my sister's friends that was coaching that team and it was hard for them not to let me play. But I had to wait one more summer I did, and then worked my way up from t-ball to coach pitch and then the first year where I ever pitched at all would have been probably when I was 12, and I only think I threw twice and it was something the previous coach wanted me to pitch more, but I didn't want to, and then it just never really came up much until I. It got mentioned once that I'd like to try it, so we tried it. It was okay, but it wasn't fantastic. Then we get up to the big field the size that every team in America plays once you're about 14. And then it was. I got thrown on the mound against a bunch of 18 year olds when I think I was 13. And my second time ever doing it I had a line drive come back and hit me in the wrist and it was that we went to the emergency room because we figured it was going to be broken. It hit me that hard, Jeez Yep.

Hudson Fuller:

Then kept working through high school and then I think it was about my junior year I realized there was a chance I could play college baseball and I was really interested in doing it. So I emailed the coaches at Dakota State because I knew there was a chance that I wanted to do computer science and the DSU has the best computer science program in the area. So I was like it would make perfect sense if I would be able to go play baseball there. I got an email back saying we'll talk once you actually turn into a senior, Got an email back and went down for a visit and got my scholarship offer there.

Sarah:

Oh, that's awesome. So you got through college playing baseball. Yes, that's really cool, that's pretty neat, that's that's pretty cool. So, and are you still? Is baseball still a part of your life today?

Hudson Fuller:

Yes, so I actually coached the high school team and the 16 year old team here in Clark. It's awesome to be able to do that and give back to the. I've played with some of the kids too, because we've had to play 13 year olds with the 18 year olds, and then I also play for our local amateur team in the summers okay, so that, so baseball still still a big part of your life and everything else so it was.

Sarah:

It was always kind of interesting because, uh, I know your parents followed you around doing taller games and everything. And it was always kind of fun because I think Paul, your dad, is Paul and he used to take off and he'd bring his computer with and he'd map, you know, on the road going all the way to see you and everything like that and get a chance to catch up on the baseball and then come on back again. So it's, it's interesting. We've been hearing about Hudson and his baseball as as employees of of GK for for a little bit. Well, that's pretty neat. I think Jody was asking a couple of questions about ADAPT. So your first internship with GK was ADAPT and your second internship was ADAPT, but all different ADAPT, correct?

Hudson Fuller:

Yes.

Sarah:

Why don't you tell us a little bit about that? What is ADAPT? What does it do? Yep.

Hudson Fuller:

Everything else. So ADAPT is a standard that AgGateway has set in an attempt to unionize data formats across all of the agricultural software companies. So everyone can say, say, put it into a John Deere monitor and pull it back out, and they'll be able to turn it back into the data they want to use in their own software system. The goal of it has always been full unionization and a lot of different small companies have signed on to make it a possibility. There are not that many that actually have ADAPT working at all and it's because it keeps changing, which is a great thing, because it needs to keep updating.

Hudson Fuller:

So the first version of ADAPT we'll call the ADAPT framework. That is the one that I think it was. Three or four years ago the idea was brought on to make a standardization and, darren, he knew about it, he wanted to implement it. He just did not understand the coding language that it ran with and then it happened to work out perfectly that I did for my first internship. So we worked through that first summer and with that, with the ADAPT framework, it could export into multiple different file types, that being GeoJSONs, iso, xmls and then also an ADAPT file, itself known as an ADF.

Sarah:

Okay. So when you're getting and that's the as applied data, then pretty much that you're talking about coming from, okay, from controllers, getting into a standardized format that we can just bring in as generic file formats.

Hudson Fuller:

Yes, yeah. And then from there we got that somewhat working at the end of the summer. However, there was a few issues with it with it. And then we realized that adapt had changed something in their code that made it not securely signed, meaning we could not release it to the public. And then come to the next summer we know we figure out how to fix that, I get that working. And then we realized that adapt changed everything. They decided to get rid of the different types of files that Adapt would export to, and just always export to, a JSON file, which is it's not a bad idea at all, because then you don't have a whole bunch of different file types floating around. But that meant I had to recode everything so we could export into that JSON style.

Jodi:

So, backing up even before Adapt, can you tell us a little bit more about what the problem was and why is there this drive to have something standard? And I think in my head I know sometimes we get asked as employees at GK to handle different information types and I know sometimes I just can't open them right away or like I don't have the right import. Can you tell us more about, like, what the problem at hand is here and then how ADAPT and that framework is helping to get us closer to being able to view and use this data?

Hudson Fuller:

Yeah. So it's as simple as instead of having a whole bunch of different fruits and trying to make a big fruit salad, you just have one type of fruit set out at a buffet. There is no real point in any industry, but in the agriculture industry it's been way different, because there are more file types. There's the shapes and every single different file type associated with the shapes. There's the shapes and every single different file type associated with the shapes. Every single one of those just leads to more space taken up on a computer and leads to more things having to get put on a flash drive or whatever else to get put into a monitor. If everything could get put in as one, our space would be a lot smaller and there would be no confusion within the industry. Everything, everything falls under just a few file types, instead of 50 or 100 that might be out there even though we don't use them.

Sarah:

There are so many out there that are not used in our area of the world but might be in australia, asia or anywhere else so kind of like hydraulic hookups back in the day then, like John Deere had their own specialized hydraulic hookups for many, many, many years and you couldn't hook up like if it was a chisel plow or something from a different brand. You couldn't hook it up to the John Deere unless you had the converter to convert the hydraulic hookup.

Hudson Fuller:

Yes, that's a perfect analogy.

Sarah:

Once we standardized hydraulic hookups, now we could hook up whatever equipment we wanted to whatever tractor we wanted, without converters, because we all had the same hookups.

Hudson Fuller:

Yes.

Sarah:

Every color would talk to every color.

Hudson Fuller:

Yeah, that is a perfect analogy for that.

Jodi:

Would this get us to be where, like we wouldn't have to use the FOD importer for yield data that kind of thing anymore, or I suppose, like there'd still be older controllers that would export like that correct? Would this be something that comes out in newer controllers and we'd see that newer controllers are using the ADAPT standard, or is this like a standalone? How does ADAPT get implemented, I guess would be my question. What do things look like once ADAPT is implemented?

Hudson Fuller:

Yeah, so the idea is to not truly replace FOD because the older monitors and controllers they will never get updated to ADAPT Okay. But a lot of the newer ones I know specifically with Case they have the full implementation of ADAPT within their newer monitors. I don't know the numbers that controller monitors are, but I know they use ADAPT and that's why we've been pushing hard to get the ADAPT framework out, because they use the ISO XML plugin of Adapt so that it exports into a task data into that style format. But it all uses a format inside built from Adapt.

Sarah:

So would we be exporting out a geo JSON then essentially the ADAPT system that the CASE controller could read.

Hudson Fuller:

CASE uses an ISO XML file that has the boundary and it has the averages and certain other numbers associated with your prescriptions, and then it also exports a bin file, and that bin file has a grid associated with all of your different prescriptions for variable rate for that field.

Jodi:

That's really interesting.

Jodi:

I guess I'm saying it's interesting because I've never thought about you know, because I think right now for exporting to cases you know, or like importing yield data, it comes back in like a CN1 file or like a.

Jodi:

My point is like, even with like KMLs too, when anything is different from a shapefile, I don't know how it works right, like the thought of like having a bin that has the grid of like all of the prescriptions, it just kind of blowing my mind. Right now I'm just trying to think through, like what are could you talk about like some other types of like file types and like how that's set up? Like could you walk through, like in your computer language, computer science knowledge, can you talk about like what is a shape file? And then like what does a case prescription file look like? And maybe like another export type that you can think of? Because I think when I know what these things kind of act like, it helps me really understand, like how to export things better out of ad master, like why I need to jump through a certain hoop to get what I need to get done yeah, so we'll start off with a shapefile and when I'm actually working with the data from a shapefile I don't look at the shapefile.

Hudson Fuller:

I'm not seeing the boundary or the polygon style prescription. I'm not seeing that at all. I am just seeing the data in the back end. So we have a tool within ADMS that allows us to read in all of those points on the shapefile. Usually it is in different features. That is like in the backend what a shapefile has. Each polygon is not a polygon, it is a feature and each of those features has so many different values associated with it. If it's relating to a prescription, they will have some sort of numerical value value say it's 112 pounds per acre, whatever it may be and then they'll also have an extent, is what we call it, and that is the edge of that feature. So every little square has four numbers and that is the lat long of each corner of that. And then in ADMS we always read it in as northern and easting in the UTM style. Sometimes we have to re-transform it back into lat long to make it so that we can use that data across the world, not needing to know the UTM zone. That specifically has come up recently when I've been working with the field info stuff and trying to figure out how can we best actually get where this field is. But that's a different topic for a different time.

Hudson Fuller:

And then the Adapt ISO XML files. When you open up that file, the ISO file, you don't actually see a picture of the boundary. You will see probably a hundred points or so that make up the edge of that field's boundary. Along with that you will have the average of the prescription, like what the average pounds per acre in that field is. You will have a default value and a out-of-field value. These values are in there.

Hudson Fuller:

So if for some reason the controller cannot use the bin file, which is a file that just you can't actually see the data in there, the computer can see the data though it knows exactly what each point in that field the prescription can be. And then really another third type that gets used is a GeoJSON, which we also, through ADAPT, will have the ability to export a prescription from. That comes out as two separate GeoJSON files in one folder. The one contains the basic information, such as the boundary, the default rates, the out-of-field rates, and the other, geojson, will be a very, very long JSON file that has a whole bunch of different boundary points in it or prescription points, and then it will have the variable rate for each point within that field. And, for example, one of the test fields that we have through GK, the Bloom House one, that one ends up at 25,000 different points of information that end up getting thrown into that GeoJSON file.

Sarah:

Wow.

Hudson Fuller:

But the controllers that read that can do it in an instant.

Jodi:

Wow that the controllers that read that can do it in an instant. When you increase the resolution or like decrease it down, where you're going from like three meters to two meters or like 10 meters to seven meters, you're increasing the number of data points that need to be collected for each of those, the squares, and I suppose, for like older monitors, like we see in, like the manual for exporting, um, that that matrix, right, some of the older controllers can't handle that much data, right, right, and we've got to reduce that polygon size. But that makes sense If we've got data at all those points, that takes up more space and more memory with the computer to read those and process what that actually means. To tell the spreader or the planter in the back what to do and how to vary the rate, the spreader, the planter in the back, what to do and how to vary the rate.

Sarah:

Gosh, I'm so glad that you're talking with us about this because you know, from our perspective, or like for me, especially as agronomists, I see a lot of these things on the front end but I've got no idea how it's actually working in the computer to see these things and convert it into something that is, you know making rates vary in the back, so this is really fascinating for me to learn from you, hudson, and not only making the rates vary, but making the rates vary in the way that makes you know the agronomist has the rates set up, but we want to keep the integrity of that prescription, and not every single export process can do that well, and so it's really exciting to hear about how this all comes together, and not only that, but to have the explanation of all of those different file types. That's pretty fun.

Jodi:

So we're going to cut it here, but we've had such a fantastic conversation just getting to know Hudson a little bit better, learning about his background and how baseball has helped make Hudson a better computer programmer. But we've also talked a little bit about the ADAPT standard and some of the things that Hudson's working on, and it's been such a pleasure to have Hudson explain these things to us and I know that we're going to do the same when we come back with Hudson in the next episode, in the second part of our talk with him. So thank you all so much for joining us today and we will see you on the next full-length episode of Ag Geek. Speak with GK Technology.

Sarah:

And at GK Technology we have a map and an app for that.