Re: Could not test Signal Composer and Low-CAN API

["Scott Murray" <scott.murray@xxxxxxxxxxxx>]

On Mon, 29 Nov 2021, ashwin vijaykumar wrote:

> Hello All,
>
> I am using Raspberry PI 4 with MCP 2515 CAN Controller and AGL Koi v11.0.4
> (built by enabling CAN in build/local.config - ENABLE_CAN="1").
>
> After flashing the CAN-Enabled-KOI-image, I changed the boot/config.txt
> file and made the following changes.
>
> dtparam=spi=on
> dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25
> dtoverlay=spi0-hw-cs
>
> I can see CAN Messages in "candump can0"  in AGL sent from Vehicle Spy.
>
> I can see CAN Messages sent by AGL (HVAC - FAN Speed) in Vehicle Spy
> [Message ID  0x030].
>
> Just I have just tested Engine Speed in Dashboard Application by
> sending the CAN Message with ID 0x3D9 by referring to
> file default-signals.cpp from application agl-service-can-low-level. It was
> not getting updated in the UI.
>
> For demo application, where can I find the CAN Message ID from AGL Koi.

They are what you see in plugins/default-signals.cpp in
agl-service-can-low-level.  That file is generated from signals.json in
examples/agl-vcar in the source repository with the generator tool in:

https://git.automotivelinux.org/src/low-level-can-generator

If you do get to the point where you want to get your own vehicle
definition used, you'll need to get whatever format you have it in
converted to the JSON format low-level-can-generator takes as input
(which is based on OpenXC, but is not identical to it AFAIK).  There
is some documentation on using the generator in the "docs" subdirectory
of agl-service-can-low-level.  Converting from something like a CANoe
dbc file will require an investigation on your part.  As I mentioned on
the call, others in the community have managed to do that with scripting
based on the cantools Python library, e.g.:

https://github.com/walzert/dbc2json

> After that I tried to bind afb-demon with either Signal Composer or
> low-can-service, both giving errors. The command and error log I am
> attaching the log below.

Those logs indicate you're running the bindings by hand with afb-daemon,
which I would strongly not recommend, even though it's mentioned in some
of the binding documentation.  The generated systemd units have a bunch of
environment configuration that is pretty much required for operation at
this point IMO.  If the bindings are installed correctly with afm-util
(which they will be automatically on first boot in any of the upstream AGL
images), then ones like agl-service-can-low-level that are marked as
"run-by-default" in their config.xml will be automatically started by
systemd.  agl-service-signal-composer is not configured that way, but in
the agl-demo-platform image it is a dependency of several other bindings
and applications so it should be getting started at boot if you're using
that image.  If you've built your own custom image and it is not a
dependency of anything and not getting started, then the ways to start it
by hand are either with:

afm-util start signal-composer

or:

systemctl start afm-service-signal-composer--11.0--main@1001.service

For the latter, you may need to check with:

systemctl | grep afm-service-signal-composer

for the correct unit name in systemd depending on the AGL release.

Another thing to note in this area is that I would not advise manually
restarting bindings that are in use by applications (or other bindings).
Gracefully recovering the binding API connection is not handled in any of
the demo bindings or applications, so doing so breaks things unless you
restart the whole chain of dependencies.  I mention this as the CAN and
signal composer bindings are ones I have seen this with in my own testing
when working on the demos.

> Where can I find the documentation or sources to configure a custom CAN ID
> to Signal composer?

The JSON files for the signal configuration are in the directory
conf.d/project/etc in the agl-service-signal-composer source.  For the
speed signals used by the demo apps, see e.g. event.vehicle.speed in
sig-demoboard.json.  The configuration is basically a direct mapping
of the CAN binding's messages.vehicle.average.speed message to the signal
composer event to send, and I believe all of the event.* signals used by
the demo bindings and applications are done this way.

Since I've found it not quite obvious in the past, note that the set of
JSON signal definition files to use is set in control-signal-composer.json
in conf.d/project/etc.  That file ends up inside the installed binding
widget.  There is some provision for triggering using a different
configuration for the binding at runtime, but you'll need to look through
the documentation in the "docs" subdirectory in the repository and maybe
in the source if you want to use it, as we do not in the demo platform.

> What triggers OnSignalEvent (ref: ValueSource.qml, agl-cluster-demo-dashboard)

A set of binding API wrappers from a library called libqtappfw are used
in the Qt based demo applications to avoid trying to efficiently handle
websocket events in QML and reduce duplicated code.  If you want to see
the code, take a look at the signal-composer directory in the repository:

https://git.automotivelinux.org/src/libqtappfw

With respect to testing, if you want a quick test, or want to check the
CAN message field definitions you are using in your test software, take
a look at the script:

recipes-demo/simple-can-simulator/files/simple_can_simulator.py

in the meta-agl-demo repository.  It is a test script that we've used to
drive the demo setup at trade shows like CES.

Scott



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9560): https://lists.automotivelinux.org/g/agl-dev-community/message/9560
Mute This Topic: https://lists.automotivelinux.org/mt/87377182/2167316
Group Owner: agl-dev-community+owner@xxxxxxxxxxxxxxxxxxxxxxxxx
Unsubscribe: https://lists.automotivelinux.org/g/agl-dev-community/leave/4543822/2167316/883735764/xyzzy [list-automotive-discussions82@xxxxxxxxxxx]
-=-=-=-=-=-=-=-=-=-=-=-