Use Yocto recipe as a acap app?

[thomas-roos]

Hi,
is there a way to use a yocto recipe as a acap app?

[github-actions[bot]]

This automatically generated reply acts as a friendly reminder.

Answers to your questions will most often come from the community, from developers like yourself. You will, from time to time, find that Axis employees answers some of the questions, but this is not a guarantee. Think of the discussion forum as a complement to other support channels, not a replacement to any of them.

If your question remains unanswered for a period of time, please revisit it to see whether it can be improved by following the guidelines listed in Axis support guidelines.

[vivekatoffice]

Hi @thomas-roos ,
Based on my understanding, AXIS OS is built on the Linux Yocto OpenEmbedded project. Developed by the AXIS OS team specifically for Axis devices, it leverages the stability of Linux Yocto OpenEmbedded while exceeding generic builds. Its optimized design meets the unique demands of Axis edge devices, including cameras, speakers, and access control equipment.

References:

1. Open source enables and improves Axis products through choice of technology and community contribution.
2. The power of a single platform

I don't think we can make changes at the Axis OS level because of the secure boot together with signed firmware. I suggest exploring Axis ACAP SDK for development.

P.S. You might have more experience than me with the Yocto Project, but I’d recommend using the Axis ACAP SDK instead of a Yocto recipe for building your application. The ACAP SDK is specifically designed for developing and packaging ACAP applications efficiently. That said, feel free to experiment and explore different approaches if you prefer!

[thomas-roos]

Thank you, that is all true - but my question was about the Axis ACAP SDK - if I can use a Yocto recipe to build an app with it? May there is some converter or so?

[vivekatoffice]

I will try to find more on Yocto recipe support in ACAP SDK. Do you have any wishlist(Yocto recipe links) which you can share here?

[thomas-roos]

I would love to install this as a app: https://github.com/aws4embeddedlinux/meta-aws/blob/master/recipes-iot/aws-iot-greengrass/greengrass-lite_2.0.2.bb

[vivekatoffice]

Hi @thomas-roos ,
Thank you for the link. It will be interesting to know the capability of AWS IoT Greengrass and how it will help with your use case.

I just added a few links below which I found related to AWS may be helpful 😜 :

1. Send images to AWS S3
2. Build hard hat detection using AXIS Object Analytics and Amazon Rekognition
3. Integration between Axis devices and Amazon Web Services (AWS)
4. The AWS Kinesis Video Stream Application makes it possible to stream video from an Axis device, that is capable to run containers, to AWS Kinesis Video Streams.

[thomas-roos]

Basically AWS Greengrass is a edge runtime. That means customers can deploy their own components (like your apps) with it.
Customers were using this in a container, but you're sunsetting this route.
So we are looking for an alternative to install Greengrass on your cameras.

[vivekatoffice]

Just adding another discussion link related to AWS Greengrass:

Building aws-greengrass-lite with acap native sdk #981

[daniel-falk]

Hi @thomas-roos, this is a very interesting question. Unfortunately, the simple answer is "no" - there are no easy ways to map a Yocto recipe to an ACAP build process. The reason for this is that the ACAP SDK is fundamentally different from the Yocto build environment (but @vivekatoffice is right in that the AXIS OS is built on Yocto, but all that is already set in stone once you create your ACAP application, and the recipes used to build the OS are not public).

1. Yocto allows you to install system dependencies and services, you can't do this in the ACAP SDK since you are very restricted in what you can do to the system. It's kind of a sandboxing (using read-only file system and reduced privileges)
2. Yocto allows you to install systemd services, you can't do this in the ACAP SDK. Each application will run as one process (using systemd under the hood, but that is an implementation detail). If you want to have multiple processes you either need to manage them as subprocesses or create multiple ACAP applications.
3. Yoco allows you to create and manage users etc, you can't do this in ACAP. Each application will run as one specific user that the system creates for you (you can chose to use the same static user for all, or a dynamically generated user).
4. Yocto provides way to handle dependencies between recipes. The dependencies between system libraries could possibly be mapped to dependencies on libraries that should be built and bundled with the application, but there's no 1:1 mapping, so you would need to define rules yourself that makes sense to you.

We have also looked quite a bit at AWS GreenGrass for the Axis cameras, but my belief is that it is not configurable enough to run as a native ACAP application. I would love to be proven wrong, but as I understand it, GreenGrass assumes that there is e.g. a package manager in the system. The Axis OS does not have a package manager. This is just one of a long list of issues we have identified.

I would be happy to connect and discuss more.

[thomas-roos]

Hi,
yes I guessed this what you just confirmed (1-4) - may a translator for build instructions would be nice, but that is not too hard...
What do you mean by configurable? We also now have two versions of greengrass - one Java version that's in market for years and a new Greengrass lite that is written in C targeting smaller devices using systemd and has a multiprocess architecture.
Greengrass is more like a package manager - it does not require any.
Here is a nice overview of the Greengrass lite: https://www.youtube.com/watch?v=5g5nSFciYk0
Would love to discuss this more.

[daniel-falk]

OK, that is a great step in the right direction. I have read through the architecture design document, and the design overview.

From what I have seen so far, I think the biggest challenge is the orchestration. If I understand it correctly, currently you can base the orchestration on one of these:

• SystemD
• InitD
• Windows system service registry

None of these are usable from an ACAP application. The reason for this is that the cameras are considered a multi-tenant system and no single ACAP application should be able to affect or interfere with other applications or the security critical functionality of the surveillance camera itself (this is at least the theoretical idea behind the system design).

Currently, as I understand it, systemd is used both to run multiple daemons for the nucleus itself, but also to install new user defined components at runtime. Both of these would need to be handled differently.

So with configurable, I mean e.g.:

• Can you create a custom orchestrator for the ACAP platform / system independent subprocess management?
• Can you configure the paths in the filesystem that will be used? (most filesystem is read-only)
• Can you dynamically handle the user name and group name at install time (i.e. not build time)? (for now, using the sdk user would be a workaround for this)

I'll send you a message so we can schedule a call to discuss more and see if there are any collaboration opportunities for us.

[thomas-roos]

Does ACAP support USER systemd services?
Something like this here: https://wiki.archlinux.org/title/Systemd/User#

[daniel-falk]

@thomas-roos That's a very good idea, but unfortunately it does not seem to be setup in the cameras. I don't think the OS even comes with a user bus setup for DBus, only the system bus. This does however deserve some closer investigation, so I will look more into it.

[vivekatoffice]

Feel free to re-open it OR share the solution/alternative/comment if already resolved👁️‍🗨️