Re: Interest in the ISO-Blue project

[Yang Wang]

Hello Göran,

I am cross-posting to ISOBlue Google Group to continue our conversation.

The bigger picture on ISOBlue with Avena is encapsulated in the architecture figure of this document. In short, we hope to create an ag machinery sensor hub/ecosystem. Sensors provide data streams. Services are written to back up data, push data to Cloud, do edge computing, etc. How services are written is up to the user. For example, if you only need yield data, you will write a service that parse yield data out from the CAN stream and do whatever you want with it.

In terms of price, for a complete last gen ISOBlue unit, it costs about $1000. However, with the Avena stack, this might get much cheaper or expensive depending on what you need to achieve. Since Avena aims to be as generic as possible, you could probably install it on a Raspberry Pi to do some basic logging. However, if your goal is to do video processing on the fly, a more powerful (expensive) solution should be considered.

For your comments on parsing CAN logs, there are a number of existing solutions (1, 2, 3, 4) targeting road vehicles. The trick is to generate dbc files - a file that stores message definitions. These dbc files are typically not machine agnostic; meaning that you will probably need a number of these files across different machines and brands. We are pretty good at logging CAN from machines; parsing CAN is an area we also want to tackle on.

 

Related to GeodataFarm, we have similar tools in OpenATK. TrialsTracker and ISOBlueApp (live app) is related to ISOBlue. They serve to visualize both real-time and historic data (GPS, yield, etc.). The backend is powered by our own OADA API. These works are actively maintained.

Also thanks for your catch on the dependency error. We are slowly moving away from using Kafka in logging CAN to a more compact solution using just candump.

This is quite a bit of information but hopefully they will help you guys out. We definitely would like to collaborate on creating a CAN parser. We have quite a bit of past CAN logs to play with. Let us know what you think.

Thanks,

Yang

On Wed, Aug 26, 2020 at 3:04 PM G Hasse <gor...@raditex.nu> wrote:

Hello!

Quite a long list of interested people! That is nice.

To make a long story short. We have, here in Sweden, a similar project
as yours.

We want to collect harvesting information and present this for farmers
in different ways. Eg on the webb.

Axel, have a project, GeodataFarm,
https://github.com/axelande/geodatafarm3

And I am helping Thomas with a similar project presenting data
in different ways.

Anyhow... we got interested in ISOBUS, eg ISO11783-X, and was looking
around for parsers of this protocol.

There is some commercially available sourcecode

https://www.embitel.com/isobus-software-stack-integration-services

but this is quite pricy. And there are some gateways around

https://www.b-plus.com/en/products/isobus-solutions/b-isobus-io-gateway

but this might bind you to a specific product.

So - I was hoping for a software parser of the CAN packages to present
them, and log them, in some form.

We are an experienced software developing company and I have been
looking into your source code at

https://github.com/ISOBlue/isoblue2.git

As I understand you use cansockets on Linux and distribute those can
packages with kafa (as message bus) to different consumers.

BTW: configure: error: libavro not found! Not so lucky today.

You should have a README file pointing out dependencys for your
software.

sudo apt install libavro-dev
sudo apt install librdkafka-dev

And you should compile all your code with -Wall to get rid of
all casting problems.

I am certain that our project could benefit from each other and
hope that you would like to cooperate.

// GH

P.S.
We also do hardware development we might cooperate on this as
well.

Den 2020-08-26 kl. 19:38, skrev Yang Wang:
> Hello Göran,
>
> Thank you for your interest!
>
> For your question, ISOBlue is the name of the sensor platform we are
> building. On the other hand, Avena is the newest software stack for ISOBlue.
>
> We are currently doing migration and refactoring legacy ISOBlue code
> into containers and remote orchestrationfor our old hardware. You can
> find the legacy code in the ISOBlue repo
> <https://github.com/ISOBlue/isoblue2>.
>
> For Avena stack, we provided a preliminary guide
> <https://github.com/OATS-Group/isoblue-avena/blob/master/docs/hardware/toradex/install-apalis.md>
> to install a base OS to the old hardware
> <https://github.com/OATS-Group/isoblue-avena/tree/master/installers/toradex-apalis>.
> You can also find the source code for services here
> <https://github.com/OATS-Group/isoblue-avena/tree/master/services>. We
> use Ansible coupled with Wireguard to do remote deployment. We also
> intend to move to a more powerful hardware and currently we are
> designing a custom shield
> <https://github.com/OATS-Group/isoblue-avena/tree/feature/hardware-avenashield-panda/hardware/avenashield>
> for it. Documentations are not there yet but will be added in the future.
>
> I am curious: what is your use case and what do you want to build? Avena
> is still really new; feel free to contribute and move further discussion
> to the ISOBlue Google Group <https://groups.google.com/g/isoblue>.
>
> -Yang
>
>
> On Wed, Aug 26, 2020 at 10:38 AM Göran Hasse <gor...@raditex.nu
> <mailto:gor...@raditex.nu>> wrote:
>
>     Hello,
>
>
>
>     I am interested in your ISO-Blue project. I tried to read on the
>
>     isoblue-avena homepage (GitHub) but did not understand the relation
>     between
>
>     isoblue and avena?
>
>
>
>     I checked out hte git but did not fine any source code...
>
>
>
>     How to proceed?
>
>
>
>     // GH
>
>
>
>
>
>     --
>
>     Göran Hasse
>
>     email: gor...@raditex.nu <mailto:gor...@raditex.nu>
>
>     Mobil: 070-5530148
>
>     www: www.raditex.nu <http://www.raditex.nu>
>
>
>

--
Göran Hasse
Raditex Control AB
Boo 229, 715 91 ODENSBACKEN
tel: 070 5530148
mail: gor...@raditex.nu

[Göran Hasse]

Hello,

> On 2020-08-27 00:05, Yang Wang wrote:
> Hello Göran,
>
> I am cross-posting to ISOBlue Google Group to continue our
> conversation.
>
> The bigger picture on ISOBlue with Avena is encapsulated in the
> architecture figure of this document

> <https://github.com/OATS-Group/isoblue-avena/tree/master/docs>. In

> short, we hope to create an ag machinery sensor hub/ecosystem.
> Sensors provide data streams. Services are written to back up data,
> push data to Cloud, do edge computing, etc.

In my opinion it would *not* be a good idea to push the complete CAN datastream
to the "cloud".

In an machine there is a _lot_ going on that you are _not_ interested in.

The CAN bus itself is a message buss and contains all sort of communications
between all units. Ant that could be a lot of them. So before starting
to collect data you must set upp some sort of filter and _then_ start
collect data.

And the idea behind the CAN buss is "problem separation". Eatch node on the
CAN unit does one thing and do that thing well. I belive that a monitoring
system should follow this paradigm. Not to cram all kind of functionality
into one linux box.

> How services are written
> is up to the user. For example, if you only need yield data, you will
> write a service that parse yield data out from the CAN stream and do
> whatever you want with it.

And this is also a problem. The CAN-stream from a agricultural machine
is encoded as ISO11783-10 messages. And this is a quite large "application"
protocol and _not_ easy to decode.

> In terms of price, for a complete last gen ISOBlue unit, it costs
> about $1000. However, with the Avena stack, this might get much
> cheaper or expensive depending on what you need to achieve. Since
> Avena aims to be as generic as possible, you could probably install
> it on a Raspberry Pi to do some basic logging. However, if your goal
> is to do video processing on the fly, a more powerful (expensive)
> solution should be considered.

On a agricultural machine there is a lot of power. And there
is lot of space. If you are planing to use a Unix (Linux) system
there is no need for a Rasberry. You could go for a industrial computer.
You could use a CAN interface to this and an ordinary USB stick for GSM
communication.

> For your comments on parsing CAN logs, there are a number of existing

> solutions (1 <https://github.com/eerimoq/cantools>, 2
> <https://github.com/jmagnuson/canparse>, 3> <https://github.com/commaai/opendbc>, 4
> <https://github.com/dschanoeh/Kayak>) targeting road vehicles. The

> trick is to generate dbc files - a file that stores message
> definitions. These dbc files are typically not machine agnostic;
> meaning that you will probably need a number of these files across
> different machines and brands. We are pretty good at logging CAN from
> machines; parsing CAN is an area we also want to tackle on.

Yes - and this is precise the problem. Most of the projects you list are
for ordinary cars or trucks. Most car manufacturer have there own application
protocol. And that for a good reason. If you know the application protocol
you could also inject data and by that havoc the engine.

And I found no parsing of ISO11783.

> Related to GeodataFarm, we have similar tools in OpenATK

> <https://github.com/OpenATK>. TrialsTracker
> <https://github.com/OpenATK/TrialsTracker> and ISOBlueApp
> <https://github.com/OpenATK/ISOBlueApp> (live app
> <https://openatk.com/ISOBlueApp/>) is related to ISOBlue. They serve

> to visualize both real-time and historic data (GPS, yield, etc.). The

> backend is powered by our own OADA API <https://github.com/oada>.

> These works are actively maintained.

Ok. I will look at this.

> Also thanks for your catch on the dependency error. We are slowly
> moving away from using Kafka in logging CAN to a more compact
> solution using just candump

> <https://github.com/OATS-Group/oats-fleet/blob/master/roles/file_logs/files/systemd/can-logger%40.service>.

In my opinion the parser of data should be as close to the CAN bus as possible.
Ofcourse this needs some sort of configuration before eatch run. But to store
a compleat CAN-stream would be overkill. So in Unix pipe lingo this
will be.

CAN-unit | socketcan/can-card | ISO11783-filter (c-program) | local storage (SSD) | transport(GSM) | longtime storage (Postgresql)

> This is quite a bit of information but hopefully they will help you
> guys out. We definitely would like to collaborate on creating a CAN
> parser. We have quite a bit of past CAN logs to play with. Let us
> know what you think.

Yes. And I hope I can contribute to your project.

// GH

>> <mailto:gor...@raditex.nu> <mailto:gor...@raditex.nu

>> <mailto:gor...@raditex.nu>>> wrote:
>>
>> Hello,
>>
>>
>>
>> I am interested in your ISO-Blue project. I tried to read on the
>>
>> isoblue-avena homepage (GitHub) but did not understand the
>> relation between
>>
>> isoblue and avena?
>>
>>
>>
>> I checked out hte git but did not fine any source code...
>>
>>
>>
>> How to proceed?
>>
>>
>>
>> // GH
>>
>>
>>
>>
>>
>> --
>>
>> Göran Hasse
>>
>> email: gor...@raditex.nu <mailto:gor...@raditex.nu>

>> <mailto:gor...@raditex.nu <mailto:gor...@raditex.nu>>

>>
>> Mobil: 070-5530148
>>
>> www: www.raditex.nu <http://www.raditex.nu>
>> <http://www.raditex.nu>
>>
>>
>>
>
> -- Göran Hasse Raditex Control AB Boo 229, 715 91 ODENSBACKEN tel:

> 070 5530148 mail: gor...@raditex.nu <mailto:gor...@raditex.nu>

>

--
Göran Hasse
email: gor...@raditex.nu

Mobil: 070-5530148
www: www.raditex.nu

[Andrew Balmos]

Hi Göran,

Nice to meet you and really happy to have these conversations.

I think a lot of your notes are written from the perspective of an "application developer" rather than our "platform" perspective. Keep in mind that Avena is just a software stack that is trying to make it easier to create whatever service you want. CAN Is just one of the potential interfaces that are in use. A secondary goal is to simplify how services access data. For example, you only have to integrate with Kafka to: listen to GPS fixes, CAN messages, cell strength, etc. The hardware details, configuring interfaces, etc. are taken care of. Some of these features work today and some of these are in development.

In my opinion it would *not* be a good idea to push the complete CAN datastream
to the "cloud".

I agree and at the moment we do not push complete CAN datastream to the cloud in real time. You could, however, easily create a service that would by forwarding all CAN messages on the Kafka bus up. Keep in mind this entire picture (https://github.com/OATS-Group/isoblue-avena/tree/master/docs) runs on the Avena device itself. The Kafka broker (which we are actively considering alternatives for), postgres, and docker containers are directly deployed to the computer in the machine. 

 

In an machine there is a _lot_ going on that you are _not_ interested in.

I don't agree at all. There are a wide array of potential applications interested in a variety of messages. Avena really can not pre-filter the CAN stream without hurting someone's development experience. Each service should filter the data streams as they see fit.

For OATS deployments, we do capture the entire unaltered CAN stream and store them locally on the device. They are copied off in bulk later. These are very useful tools in research and product development and are very much of interest to us.

And the idea behind the CAN buss is "problem separation". Eatch node on the
CAN unit does one thing and do that thing well. I belive that a monitoring
system should follow this paradigm. Not to cram all kind of functionality
into one linux box.

ISOBlue Avena is not just a monitoring system. I agree with you that separation of concerns is a good idea, we have just chosen to separate them in software rather than hardware taking lessons learned from the same problems in large scale cloud deployments with event buses. In Avena, you create docker containers that are able to access all local data streams (currently via Kafka) and databases (currently postgres/timescaledb). Containers can then do as they please. Process the data, send something to the cloud, write to the CAN bus, interact with a sensor via Bluetooth, etc.

I don't see the point in putting multiple $1000 units when we can achieve the same level of isolation in software.

 

> How services are written
> is up to the user. For example, if you only need yield data, you will
> write a service that parse yield data out from the CAN stream and do
> whatever you want with it.

And this is also a problem. The CAN-stream from a agricultural machine
is encoded as ISO11783-10 messages. And this is a quite large "application"
protocol and _not_ easy to decode.

ISO11783-10 isn't _that_ complicated to parse. We have worked with this style of data as kernel modules (https://github.com/ISOBlue/isoblue-software) in the past. We also have a variety of user land parsers that we use to break down captured logs, etc. That said, I expect we will do some level of initial parsing between the socketcan interface and the Kafka event bus. 

What type of "pre-processing" would you like to see?

 

> In terms of price, for a complete last gen ISOBlue unit, it costs
> about $1000. However, with the Avena stack, this might get much
> cheaper or expensive depending on what you need to achieve. Since
> Avena aims to be as generic as possible, you could probably install
> it on a Raspberry Pi to do some basic logging. However, if your goal
> is to do video processing on the fly, a more powerful (expensive)
> solution should be considered.

On a agricultural machine there is a lot of power. And there
is lot of space. If you are planing to use a Unix (Linux) system
there is no need for a Rasberry. You could go for a industrial computer.
You could use a CAN interface to this and an ordinary USB stick for GSM
communication.

To be fair, combines, sprayers, etc. have a lot of cabin space but not all machines do. For example, we often have a hard time finding a good place to install ISOBlue into medium-sized utility tractors whose cabins are often just  big enough for the operator's chair. Skidsteers, etc. can be even worse. 

Our earliest version of ISOBlue was built on a beaglebone black and it was perfectly fine as a simple logger. It was significantly cheaper than the current $1000 Toradex based design, which is cheaper still then the current Lattepanda Alpha hardware that we will start developing on. When you are making a large fleet, the cost of the hardware does start to make a difference. However, Avena is designed to be hardware independent (within reason), allowing the application engineer to make that decision for themselves.

And I found no parsing of ISO11783.

This is an industry problem. Most manufacturers hold the message schemas as private knowledge. A few messages are standard and those are available in both excel and dbc formats from the standard body. The rest you know either under NDA, reverse engineering, or some "databases" of messages like the pysobus project (mostly learned from reverse engineering I believe).

 

In my opinion the parser of data should be as close to the CAN bus as possible.
Ofcourse this needs some sort of configuration before eatch run. But to store
a compleat CAN-stream would be overkill. So in Unix pipe lingo this
will be.

CAN-unit | socketcan/can-card | ISO11783-filter (c-program) | local storage (SSD) | transport(GSM) | longtime storage (Postgresql)

You can certainly achieve that with Avena if you want. It will just look more like:

socketcan | Kafka | your-service

Where you build "you-service" like:

filter | local storage | transport | longtime storage

 

Here are some example Avena based services that we have released so far:

gps2tsdb (https://github.com/OATS-Group/isoblue-avena/tree/master/services/gps2tsdb) reads from gpsd and writes the fixes to postgres/timescaledb (local to the Avena node)

gpsd | dbus | timescaledb (local on Avena)

oada_upload (https://github.com/OATS-Group/isoblue-avena/tree/master/services/oada_upload) This service reads the GPS logs from timescaledb and uploads new GPS points to an OADA API (another OATS project)

timescaledb | OADA (HTTP API)

Those two services drive this app: https://openatk.com/ISOBlueApp/. If you go to the app at the right time, you can watch the tractors move about in real time. Try turning on 160-puma-tractor and 165-feeder. The others are test units and don't move.

I hope that clarifies the purpose of the project and makes it a bit clearer how things integrate. The project is relatively new (well, Avena is new--ISOBlue 2.0 and below have been around for some years) and the lack of services is due to them being in development. Most of the published work to date is in Ansible scripts--used to deploy the base Avena system. You can find those here: https://github.com/OATS-Group/isoblue-avena/tree/master/ansible/avena

Andrew