The flatpak installer contains the Builder although it also gives you an option to install the Engine as a local service if you don't want to fiddle with docker. The Builder is an IDE for creating new vision apps. You don't need it in an embedded environment.

It is possible to use the flatpak installer in a Yocto-based distro (I know one customer who has done so), but it may be challenging because it basically requires a full desktop environment. If the Builder from the flatpak installation doesn't work, there is little hope that the va-engine service inside it will either.

My suggestion is to go with the docker image. It is way easier to set up in a custom embedded system. Unfortunately we don't have ready-made installation instructions.

-Topi-

Hi,

Oh, you are using an OpenEmbedded -based custom distro? Making flatpak work on home-grown Linux distributions if unfortunately something we currently cannot help with. Furthermore, flatpak is targeted at desktop and not the best choice if your target is to run the VisionAppster Engine on an embedded system.

Unless you want to run the Builder on the target hardware, I propose that you use the va-engine docker image instead. It has much lighter dependencies. Basically, you only need a shell and a few utility programs (see here).

That said, systemctl status va-engine will tell you if the Engine is running. If you use the docker image, the command is docker ps.

-Topi-

Hi,

Can you report your operating system version so that we can try to reproduce the error? What does uname -a output if you type it to your shell?

When it comes to the connection problem I'm not sure what you are trying to achieve. Are you running a Raspberry Pi with our Engine? Or did you try to connect to a locally running Engine instance?

When installing with va-install you have the option to install the Engine as a local service. Did you choose that option? If yes, then http://localhost:2015 should do the trick. That is, unless the Engine also fails to start.

If you are trying to connect to a Raspberry Pi, "ip-address-of-rpi" needs to be replaced with the IP address of the Raspberry Pi. See here for instructions.

-Topi-

@ms I came back to this when running release tests with our new release.

The simplest thing you can do is to explicitly disconnect the ctrl object on error:

async function test() {
    let ctrl; // move declaration here
    try {
        const va = typeof window === "object" ?
        VisionAppster :           // Browser
        require("visionappster"); // Node.js
        const inputs = [
        await va.Image.fromUrl('image.jpg')
        ];
        ctrl = new va.RemoteObject("http://localhost:2015/apis/com.myapps.testapp/1");
        const api = await ctrl.connect();
        await api.sendImage.async(...inputs);
        console.log('Success.');
    }
    catch {
        console.error("Failed.");
        ctrl.disconnect(); // add this
    }
}

It is hard to do this automatically because JS is a garbage-collected language with no destructors. When the app on the server side is brought down, its control channel remains because no one called disconnect() on the client side. The JS runtime can keep the old instance alive arbitrarily long. Since there is a reference to the WebSocket instance, the connection will remain active as well.

Now, when you create a new RemoteObject instance, it shares an existing connection by default (you are using the default mechanism). This time however the existing connection is defunct. The old server-side object does not exist any more although there is a new one in the same URL.

The channel sharing mechanism could be improved to take the remote object ID into account, but that would be a rather invasive change now. The work-around is quite simple and I hope it will work for you for the time being. We'll come back to this during the next release cycle.

-Topi-

There is a very good reason for not enabling CORS by default. If you run the Engine on your local machine with CORS enabled, it will let JavaScript code on any web page to make requests to your server. If you are aware of and accept the risk, see here: https://doc.visionappster.com/latest/engine/configuration.html#cors

Bottom line: if you serve your HTML page from another HTTP server (not from the Engine itself), you need to take care of cross-domain security issues.

Please note that using a custom server-side script will not be a solution to this problem.

Media types and image formats are independent. You can handle both compressed and raw images in your application. In both cases, the data type will be Image. The media type only plays a role once you pass an Image through the network. By default, our protocols use a custom binary encoding, which can en/decode any type of an image. It requires a client library (which you are using).

If mediaType (or the Content-Type request header) is set to image/jpeg the image is encoded as JPEG. This makes it easier to handle the image in many applications, but the encoding may lose data.

Sorry, but I don't quite get what you are trying to achieve. You only need server-side (e.g. Node.js) code if your application requires image processing in the back-end.

Drawing pixels on the canvas in the browser requires careful handling of different RGB types and endianness. Please see the Image.toImageData() function. I'd however recommend using <img> instead. The cookbook recipe you are referring to uses <canvas> and toImageData(). Please let me know if that solves your problem.

It seems you have received the Image object and it was decoded successfully. There is something on the canvas as well, but it is hard to say what it is. Maybe you tried to draw a color image as RGB or vice versa? It looks like that there is at least a row alignment issue there.

The easiest way to display an image on an HTML page is to use an <img> element:

<img id="img-id">
...
obj.$image.connect(image => image.toHtmlImage(document.getElementById('img-id')));

In principle, yes. But unfortunately nothing that would just work out of the box. To be able to use all features of the camera you need a proper camera driver. On Linux this means either V4L2 or GenTL. The former requires a kernel module, the latter takes no stance. It can in principle be implemented in user space e.g. through command-line tools. You can create a custom GenTL driver as outlined here: https://doc.visionappster.com/latest/cameras/drivers/ The process is however quite tedious unless you are familiar with the intricacies of GenICam.

Another option is to create a custom tool for the purpose of getting images from the camera. Currently, this is only possible in C or C++ (see https://doc.visionappster.com/latest/api/tool/c/), but the next release will come with Python support.

I see. The Docker image only contains the Engine. To run the Builder on Mac, your only option is to use a virtual machine and use either the Windows or the Linux binary.

The Builder (and the Engine) actually do run on Mac, but Apple's SDK licensing terms prohibit building native extensions on non-Mac hardware. Since such extensions are the whole point of our business, Mac users are crippled. It is a big bummer, but nothing we can change.

The "VisionAppster" software distribution contains the Builder. The installer will ask you if you want to install a local instance of the Engine as well. All installers are available at https://download.visionappster.com/.

The fact that you need to ask tells me that we need to improve our message. Thanks for the question!

-Topi-