Question: Samples apps location

[laykuanloon]

@barbieri , @bdilly , @edersondisouza

Our team is enabling soletta for 2 platform: SoFIA 3GR and Apollo Lake.

Our sample apps characteristic: a) consists of fbp, c deal with sol-iio.c and sol-mqtt-impl-mosquitto.c API, sol-fbp-generator c code, and low and high level c api. b) some sample apps can be the share for 2 project. some sample apps is for SoFIA-3GR only. some sample apps is for Apollo Lake only.

Would like to seek for suggestion on where should we place these sample apps. Like centralize in 1 folder? And also file name for the sample app. For e.g: kxcjk1013.fbp should I just put accel-console-mqtt.fbp?

Attached is some sample apps for SoFIA 3GR kxcjk1013.c.txt kxcjk1013.fbp.txt sol-flow-SOFIA-3GR.json.txt apds9930.fbp.txt

@fulong82 and @lblim, feel free to add if i miss out anything.

[fulong82]

Hi all,

Besides what @laykuanloon has mentioned above, we also do have hybrid sample app where a c and fbp work together. The c app is used for custom node and algorithms handling. The fbp is for nodes connection included the custom node created in c app.

We are thinking to contribute back these sample apps into Soletta code base. So, would like to check with you all what is the best structuring for these apps.

Thanks & Regards, Wilson

[bdilly]

Hi @fulong82 and @laykuanloon ,

it's great to hear you're willing to contribute samples to Soletta. I'll explain how we setup the repos/directories architecture so you'll be able to find the best way to add them (now and in the future).

Usually inside soletta repo we have many simple samples to exemplify how to use the C API and node types.

For C API these samples are on src/samples distributed over many different folders using the name of the API group we want to highlight. So you'll find a folder for MQTT samples, for HTTP... The src/samples/flow folder has lots of fbp samples, also distributed over many different folders named following the node types family we would like to exemplify, so you'll find OIC, MQTT ... Exception is c-api that has examples of flow based program written using the Flow C API There you'll also find a folder with samples specifically written for Minnowboards with Calamari lures.

So eventually samples that are SoFIA 3GR or Apollo lake only could follow this approach.

For samples that work on both, you may want to follow the grove kit structure. You have fbp samples that work fine on Intel Edison or Intel Galileo, so we provide json files for both.

But if you have a sample that is very complex, composed by multiple C modules, or it's using custom node types you may have a hard time to integrate it on current buildsystem, used by these samples we provide. In this case, you may want to host them on another repository. We have a couple complex samples at soletta-demos repo.

You could take a look on them as well.

Regarding name conventions, we avoid to use the hardware model as the sample name, specially because some times the sample itself could work fine with another model, just chaning it on the configuration file (.json), right? In the case you mention, where the accelerator measures are sent via MQTT, you could just change from kxcjk1013 to another model (we even have some other node types for accelerators) and it could keep working, right? So I would suggest to allows try to give the best high-level description for the sample you may find. In your case, I would choose accel-console-mqtt.fbp

I know that we have many not following this convention, not even using json files (just putting the model directly in the fbp), but I believe they're there these way because aliases and configuration were supported later.

Thank you

[laykuanloon]

@bdilly

Seems to me the soletta project samples is specific to a single component/node. For e.g: mqtt samples or iio samples only. There is no mix of iio+mqtt. Our sample apps consist of iio+mqtt, or iio+custom node.

Thus we plan to upstream to soletta-demos repo. But I check on soletta-demos repo, the building step require to build on target platform.

Do you have any yocto recipe can build the soletta-demos repo? Because we are building samples on host and package it into image.

[barbieri]

@laykuanloon

There is no blocker in adding composite examples in our src/samples, the only guiding purpose is that "samples should be something you can copy&paste into your code and change it slightly so it will work". That's why they are often small and cover a single purpose, to make that task easy... at least until we have a stackoverflow section about soletta :-D

The soletta-demos repository, on the other hand, is meant to demonstrate a whole application, maybe composed of multiple roles (ie: client + server) and are not targeted at copy&paste (although may be used as a starting base for new projects).

As for Bitbake build, it should be doable to create a recipe. You need to require a soletta-native in order to have an usable sol-fbp-generator. Maybe you'll need to change the CMakeLists.txt to cope with that by allowing the command to be specified, currently it writes (https://github.com/solettaproject/soletta-demos/blob/master/foosball/CMakeLists.txt):

COMMAND ${CMAKE_FIND_ROOT_PATH}/${SOLETTA_PREFIX}/bin/sol-oic-gen.py

That whole command should be a variable defined such as:

SET(SOL_OIC_GEN_PY ${CMAKE_FIND_ROOT_PATH}/${SOLETTA_PREFIX}/bin/sol-oic-gen.py)
...
COMMAND ${SOL_OIC_GEN_PY}

Then users could specify their own (ie the one that comes from soletta-native.bb). Of course remember to verify if PKG_CONFIG_LIBDIR is pointing at the cross-compile version so things such as:

execute_process(COMMAND ${PKG_CONFIG_EXECUTABLE} --variable=modulesdir soletta
  OUTPUT_STRIP_TRAILING_WHITESPACE
  OUTPUT_VARIABLE SOLETTA_LIB_PREFIX
  )

will find the target files, not the soletta-native (host) one.

NOTE: the CMakeLists.txt I've linked above just use python scripts, that should be platform independent. Then it wouldn't need the soletta-native, but if you plan to use sol-fbp-generator, then that is required, thus the example.

[laykuanloon]

@barbieri

Then I think upstream to soletta src samples is better, because is more easy to access for soletta user.

For my fbp sensor iio+mqtt should I put in src/samples/flow/iio ? For my c sensor iio+mqtt should I create a folder name iio in src/samples? For sol fbp generator code iio+mqtt should I put in src/samples/flow/c-api?

You can take a look on my samples attached above. Or you have better suggestion?

[barbieri]

Looking at your example I believe you can split the sensor and the output part, creating one FBP being your "class/object" to read sensor and create the "processed data" (in your case, that's the concatenated string), then other fbp with the display of that information. Somehow analogous to what I did for semaphore-monitor (https://github.com/solettaproject/soletta/tree/master/src/samples/flow/semaphore-monitor).

My suggestion is to create src/samples/flow/iio+network folder (others may provide better name) and with that couple of files:

• accelerometer.fbp what's in kxcjk1013.fbp except mqtt and console parts, it will produce an OUTPORT=concat.OUT:STRING. You may choose to also export individual ports in addition, such as OUTPORT=accel.OUT:DIRECTION or even OUTPORT=accel.X:X.
• console-output.fbp, make it executable, it will DECLARE=accel:fbp:accelerometer.fbp and print to console.
• mqtt-output.fbp, make it executable, also DECLARE=accel:fbp:accelerometer.fbp and publish to MQTT.
• http-output.fbp, make it executable, also DECLARE=accel:fbp:accelerometer.fbp and publish paths like /string or /direction with stuff. You can use curl or wget to test it. Also note this can do HTTP Server-Side-Events for continuous deliver of updates. Example usage at https://github.com/solettaproject/soletta/blob/master/doc/tutorials/ostro-oic-tutorial/step7/http-light-server.fbp
• mqtt-and-http-output.fbp concat both examples above and create one that outputs the value of the accelerometer to both MQTT and HTTP.

And so on, a quick look at OIC doesnt show me any model with 3d acceleration, only a simple axis (https://github.com/OpenInterConnect/IoTDataModels/blob/d728798857a67a5d3c6f16586a1ddab20cbfa2c4/oic.r.sensor.acceleration.json) so you may use 3 nodes for that model, each for one axis (kinda weird, but...)

You can do another for proximity and yet another for light (those in apds9930.fbp) you can choose to pack them all in one mega-example that outputs all 3 information as one "sensor block" (acceleration, light and proximity), etc. I guess you got the idea :-)

Last but not least, your C is generated from sol-fbp-generator, so I dont see value to commit that to the repository. You can put some example in README.md on how to generate the C file, but note that our samples already generate those if you put Kconfig and Makefile as done for other samples (with proper inclusion on parent Kconfig), they will be in build/stage/samples/flow/XXX/YYY-gen.c and the built binary as build/stage/samples/flow/XXX/YYY for a given input defined in src/samples/flow/XXX/Makefile as sample-$(KCONFIG_NAME) += YYY.

[fulong82]

Hi @barbieri,

Just to double confirm. As @bdilly mentioned, if our sample app contain hybrid method which involved a custom node in c and a fbp to work with this custom node, then this sample app could not be putting into soletta repo due to the kbuild system issue.

Even though our sample app only perform simple usage to show case how to use accelerometer data to get its pitch angle and roll angle, it is the only choice and okay for us to put it in soletta-demo repo. Am i right?

Thanks & Regards, Wilson

[barbieri]

@fulong82

What's the kbuild issue? not being able to find the customnode.so? If that's the case I believe it can be made to work with not-so-big effort (we have a way to detect the root lib dir, that is based on current libsoletta.so in use, then it would find something in build/stage/...) Also I did not see the custom node type... where is it?

Also note that in https://github.com/solettaproject/soletta/tree/master/src/samples/flow/c-api we do have a custom-node-types.{c,json}, the only difference is that it gets built into the final app, as opposed to be used by sol-fbp-runner (which uses the logic stated above).

As for your last question, if it's simple usage like it seems, then having it in soletta is the best approach. IMO soletta-demo is for something you create a more real-world example of it, like using the accelerometer, light and proximity + mqtt to create some home automation, a robot or things like that.

[laykuanloon]

ambient-light-and-proximity.fbp.txt ambient-light-and-proximity-mqtt-output.fbp.txt

@barbieri The attached file fulfill your requirement?

[barbieri]

@laykuanloon it's almost perfect. I'd go bit beyond and export the option timer.interval and maybe individual ports for each sensor in addition to sensor string

OPTION=timer.interval:interval
OUTPORT=light.OUT:LUX
OUTPORT=proximity.OUT:PROXIMITY
OUTPORT=concat.OUT:SENSOR_STRING

And add another network output as well, here you do MQTT which is good, what about http? It's also simple and explains why you split the fbp in 2: to make it easy to reuse in different contexts.

[fulong82]

Hi @barbieri & @bdilly,

I just finished creating 3 sensor apps and would like to check with you all whether they are possible to be upstream-ed and where is the best location to store them.

1.) A tilt angle sensor that using accelerometer raw data and perform arithmetic in FBP model to output pitch and roll angles. An arctangent custom node is created in this example due to Soletta does not have arctangent node type: tilt_angle.tar.gz (My initial thought is to put in a new folder under src/samples/flow/tilt_angle/)

2.) A highlevel c-api model for iio light sensor application. This example using resolver function to extract configuration data from json file to allow modification w/o re-compilation which different from the hard-coded c code that generated by sol-fbp-generator: highlevel_iio_light.tar.gz (Not sure am i allow to put this together with the c-api samples?)

3.) Similar to @laykuanloon iio+network sample but enhanced to be more modular that i created a abstraction layer (sensor.fbp) to allow easily switching when more and more sensors added to hook with mqtt. This could help the mqtt_pub.fbp remain unchanged and being reuse all the time to reduce code duplication for newly added sensors. pressure_mqtt.tar.gz

Please provide your advise. Thanks.

Regards, Wilson

[laykuanloon]

@barbieri , @bdilly , @edersondisouza

Please take a look at #2332

[laykuanloon]

@barbieri , @bdilly , @edersondisouza

Please also take a look #2334 also. It's a c code sample that use iio and mqtt api.

[fulong82]

Hi @barbieri, @bdilly, @edersondisouza

I would like to ask for a review to this apps as well: #2337.

Thanks & Regards, Wilson

[laykuanloon]

Most sample app already merged.