@IsobusPlusPlus Hello,I have been watching the development of isobus++ recently.
I have just completed the porting of ESP32S3 and successfully ran the virtual terminal examples for the esp32,
I initially planned to program and port to ESP32 using Arduino( AgIsoStack-Arduino), but there was an error message, “. cpp: 42:36: error: ‘make_unique’ is not a member of ‘std’”. Because I want to try using it in ARM Cortex-M3/4, such as STM32, which is more similar to the programming method of Arduino.
Finally, I successfully used PlatformIO( AgIsoStack-plus-plus).
Hello! That is great! I think we could remove the dependency on std::make_unique
if it it makes life easier for people by instead doing .reset(new
on these few unique_ptrs. make_unique
is a C++14 feature that some compilers apparently do not like. If this is something you’d be interested in I’d encourage you to make an issue on our GitHub page, but regardless I am glad you are finding success with PlatformIO.
We’ve got a lot of new things coming soon, including a fully functional VT server that runs on windows, linux, and mac!
Wow, now that’s going to really be something - really looking forward to a VT on Windows !
Succesfully compiled/built with Visual Studio 2017. Can I connect now to tractor isobus and run example?
As long as you have a compatible CAN adapter, yep! Connect to the implement bus, example shown below with the ISOBUS/J1939 diagnostic connector, but there should be multiple places to connect.
Hi JinQQQQQ - very interesting, are FJD planning on open-sourcing their code then?
I suppose it need to select right manufacturer id or am I wrong?
Watching this with considerable interest. I can see that eventually it might be possible to add a task controller to AOG, along with variable rate. And looking forward to seeing the VT server. It’s crazy how much money OEMs charge for bare VT monitors with no task controller enabled even.
Of course, development of cheap replacements is still costly. @IsobusPlusPlus, what is the best way to support your development? Is this endeavor company backed?
Setting the manufacturer code isn’t that important as long as you have a valid one. On an ISOBUS you should largely be able to interoperate with most standard devices with any manufacturer code. You are welcome to use our code, which is 1407, if you want.
We’re just a loose collection of developers that like open source software and ISOBUS, haha. There are no companies involved in the development of the VT, and I work on it in my free time. I’d maybe say it’s 80ish percent complete. (I’m currently adding Auxiliary function/input support to it, for example). It has been difficult, and I’ve even had to throw away our entire graphics framework once and switch to something else to get it to where it’s at now, but it’s so exciting to see it working when, as you said, normally you’d have to pay a substantial sum to get just a VT, without section control and whatnot.
I definitely think there could be some possibility of collaborating with AOG to bring some of these things together. We’ve also at least started on a TC server at the CAN level.
There’s absolutely no pressure to support us in any way, but perhaps the most useful way would be to help us test it with different implements once we release it, so that we can find issues and collect a little catalogue of object pools we can use to improve it. Every implement is a little different, so the more data we have on what does or doesn’t work, the better it will get.
I’m just always super happy to see how passionate the AOG community and others are about this stuff. Stay tuned as we make progress
I don’t think so for now,because FJD is producing commercial products.
Will FJD be contributing code, expertise or anything else back to the project ?
What are the ways to test and evaluate the supported features besides AEF?
I don’t think so…
For them, this is a good source of information based on which they can “build” their product… This may sound harsh a little bit but it is the truth.
Many a commercial product relies on open source software underneath. Depending on license, publishing elements of their code may be a requirement if so, but I wouldn’t hold my breath.
(See John Deere and their refusal to comply with GPL for details - hopefully that’ll end in a lawsuit soon enough)
As a developer, of course I know about that,I have only recently started researching IOSBUS solutions. If the project team ultimately confirms the use of AgIsoStack++, I will definitely remind them of the rules they need to follow。
Where does John Deere use GPL’d code?
IsoAgStack-plus-plus is MIT licensed. It can be used in a proprietary, closed-source product, provided you include a notice that tells your users there is some code in your product that is copyright the IsoAgStack developer (Copyright (c) 2022 Adrian Del Grosso). See https://github.com/Open-Agriculture/AgIsoStack-plus-plus/blob/main/LICENSE
AgOpenGPS is also licensed under the same MIT license.
Obviously the AOG devs and the IsoAgStack devs hope that proprietary users will contribute bug fixes and enhancements back, but that is not required.
Personally I prefer to default all my projects to GPLv3, and then re-license if someone wished to negotiate some kind of proprietary license.
And the next step is they release their canbus codes?