Geontech / meta-redhawk-sdr

REDHAWK SDR Layer for Yocto/OpenEmbedded -based deployments
http://geontech.com/getting-started-with-meta-redhawk-sdr/
GNU Lesser General Public License v3.0
9 stars 6 forks source link

Interacting between Components which is running on two different Hardware #66

Closed NayanaAnand closed 3 years ago

NayanaAnand commented 3 years ago

Hi all,

I am trying to interact between 2 Hardware which are loaded with Yocto image(built with meta-redhawk-sdr layer). OmniNames, OmniEvents, Domain and Device managers are able to run on Hardware.

Requirement : On each Hardware launched Redhawk components using sandbox and is there any ways to interact between those components which is running on different Hardware?

Regards, Nayana

btgoodwin commented 3 years ago

There are several ways to do this depending on what you're trying to do. The most simple thing is to use statements from that other issue's comments to attach to both domains, iterate to the associated components/devices and connect them (comp.connect(remote_comp)). Aside from that, here are a couple more options:

If you're trying to send small structured messages between the components running in different domains, you could build a bridge component (or device or service) that implements some other protocol like ZMQ on its own socket server. You would then connect those two components using whatever the underlying socket server requires and let that entity (component/device/service) handle the translation from MessageEvent (for example) to whatever structure the protocol requires and back again. This is a lot like how the github.com/geontech/rest-python server works when egressing events to a UI over a websocket.

If you're wanting to arbitrarily connect ports together, you can resolve the remote object's OmniNames IOR to a core framework object at the destination. For example in the python shell:

# at the source
from ossie.utils import redhawk
dom = redhawk.attach()
# iterate to the component, comp
remote_component_ior = dom.orb.object_to_string(comp.ref)

By some means you would convey that IOR information to the destination environment which could do something similar to this:

# at the destination
from ossie.cf import CF
from ossie.utils import redhawk
dom = redhawk.attach()
remote_comp_ref = dom.orb.string_to_object(remote_component_ior)
remote_comp = remote_comp_ref.narrow(CF.Component)
remote_comp.api()

Using statements from the other issue, you can see how one can code up a python script that runs only in one location to setup these kinds of connections by attaching to both the local and remote domains, which brings me back to the first couple of statements about the "most simple route". The last example is really just showcasing that even though there is a single omniNames service for a Domain, it doesn't actually make the Domain and its contents an island.

NayanaAnand commented 3 years ago

Hi Thomas,

Thank you for the suggestions. I am working on the above example.

I an facing an issue after launching Domain and Device manager like ERROR: "cat: can't open '/proc/xxxxx/status': No such file or directory" Even though those processors are not present in the background process list('ps -ef').

But that ERROR is not visible before launching Domain&Device managers.

Can you suggest any methods to find out why that msg is seen after launching Domain&Device?

Regards, Nayana

btgoodwin commented 3 years ago

Depending on what branch you're on, I began progressing the GPP package to RDEPENDS against procps and then removed the related patch (which seems to break with every busybox release). This eliminated the process tracking bugs for the most part on my side. Here's the patch over on the dunfell-next branch. Some of the more recent -next branches already have this patch too, typically as part of the squashed 2.2.6 commit (in hindsight, that was a mistake on my part; I was doing it to make it easy to move 2.2.6 between branches but then I found bugs against ARM32, x86 32-bit, etc. and had to keep patching. That's why dunfell-next is individual patches as I tried working through this again on a more recent version.)

NayanaAnand commented 3 years ago

Hi Thomas,

Thanks for the suggestions, given patch worked for me and ERROR is resolved.

eliminated the process tracking bugs for the most part on my side. Here's the patch over on the dunfell-next branch

Now working the data transmission between two systems which has same roots loaded on them. As per the example given above .

If you're wanting to arbitrarily connect ports together, you can resolve the remote object's OmniNames IOR to a core framework object at the destination. For example in the python shell:

Setup : System 1:

System2:

System1 considered as Server : Terminal 1:

Terminal 2:

# at the source
from ossie.utils import redhawk
dom = redhawk.attach()

System2 considered as Destination: Terminal 3:

Terminal 4:

# at the destination
from ossie.cf import CF
from ossie.utils import redhawk
dom = redhawk.attach()

ERROR: From System2 observed, unable to create IDM_channel while launching Device and Domain using nodeBooter. So, From System2, "redhawk.attach()" is failed.

Can you please guide me how to check where is the issue point from above setup.

Regards, Nayana

btgoodwin commented 3 years ago

Excellent news, thanks for the update about process tracking.

Your omni services configuration is suspicious. If System 1 and System 2 are to operate independently, each /etc/omniORB.cfg should point at the local system's external IP address, not the other system's. The configuration described would attempt for System 1's services to bind to an IP address it does not have on one of its own interfaces (and the same for System 2). What it should be in this case:

System 1

System 2

Script running wherever

NOTE: Using the "most simple method" described above, simply attaching to each domain using the location argument of redhawk.attach(), per our earlier discussion.

REDHAWK 2.2.7 Connections, for reference

This is all made more simple by having your applications (SADs) define external ports and properties so you can treat each instance as a single thing rather than finding specific components to connect. This is also assuming both domains are the default REDHAWK_DEV. If not, be sure to specify that in your attach(...) arguments.

from ossie.utils import redhawk
system1 = redhawk.attach(location='<System 1 external IP address>')
system2 = redhawk.attach(location='<System 2 external IP address>')

# 1. find the app and component from system1
# 2. find the app and component from system2
# 3. use appX.connect(appY, ...) or compX.connect(compY, ...)
#     with whatever args and order you need to clarify the connections

Under the hood, as they say, the core framework is going to resolve the IORs itself and make the connections according to the metadata stored in them.

NayanaAnand commented 3 years ago

Hi Thomas,

Thank you for suggestion.

Attaching Multiple Domains from Single Server is completed with below /etc/omniORB.cfg configuration. But i am not able to attach two domains as per given suggestion.

from ossie.utils import redhawk
system1 = redhawk.attach(location='<System 1 external IP address>')
system2 = redhawk.attach(location='<System 2 external IP address>')

Working omniORB.cfg shown below:

InitRef = NameService=corbaname::127.0.0.1 = InterfaceRepository=corbaloc:::2809/IfR InitRef = EventService=corbaloc::127.0.0.1:11169/omniEvents supportBootstrapAgent = 1

From Server: python: dom1 = redhawk.attach(location='system1 ip address') dom2 = redhawk.attach(location='system2 ip address')

Question : Can you guide me how to integrate Cross compiler in RedhawkIDE, the available cross compiler are not suitable for my Target platform. I need "gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf" compiler that can run on 64bit system to generate ARM-32bit binary. How to add new Cross compiler to IDE and how to compile the custom components using new Cross compiler from IDE.

Regards, Nayana

btgoodwin commented 3 years ago

The IP addresses used in each of the /etc/omniORB.cfg need to be the IP address of the respective instance. If you use local host as your post indicates, the service will not attach to the external network interface and therefore won’t respond to external requests (system 1 to system 2). This is discussed in the REDHAWK SDR installation guide regarding distributed computing configuration.

On Feb 23, 2021, at 8:09 AM, Nayana N R notifications@github.com wrote:

 Hi Thomas,

Thank you for suggestion.

Attaching Multiple Domains from Single Server is completed with below /etc/omniORB.cfg configuration. But i am not able to attach two domains as per given suggestion.

from ossie.utils import redhawk system1 = redhawk.attach(location='<System 1 external IP address>') system2 = redhawk.attach(location='<System 2 external IP address>') Working omniORB.cfg shown below:

InitRef = NameService=corbaname::127.0.0.1 = InterfaceRepository=corbaloc:::2809/IfR InitRef = EventService=corbaloc::127.0.0.1:11169/omniEvents supportBootstrapAgent = 1

From Server: python: dom1 = redhawk.attach(location='system1 ip address') dom2 = redhawk.attach(location='system2 ip address')

Question : Can you guide me how to integrate Cross compiler in RedhawkIDE, the available cross compiler are not suitable for my Target platform. I need "gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf" compiler that can run on 64bit system to generate ARM-32bit binary. How to add new Cross compiler to IDE and how to compile the custom components using new Cross compiler from IDE.

Regards, Nayana

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

NayanaAnand commented 3 years ago

Hi Thomas,

Okay, I got the point about external interface..Thank you.

Can tell me how to add cross compiler to Redhawk IDE. Because required cross compiler is not available in the list given from IDE. Can you suggest any method to cross compile the custom components.

Regards, Nayana

btgoodwin commented 3 years ago

I haven’t tried building the IDE to run on the target in recent years. Most of the time we don’t have a video output so it doesn’t make sense to do it.

For other components, you can create recipes for them and inherit from the redhawk component bbclass. That will take care of typical C++ implementations. The layer has nothing right now for Python or Java (the latter because the layer doesn’t build Java support).

On Feb 23, 2021, at 12:00 PM, Nayana N R notifications@github.com wrote:

 Hi Thomas,

Okay, I got the point about external interface..Thank you.

Can tell me how to add cross compiler to Redhawk IDE. Because required cross compiler is not available in the list given from IDE. Can you suggest any method to cross compile the custom components.

Regards, Nayana

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

NayanaAnand commented 3 years ago

Hi Thomas,

For other components, you can create recipes for them and inherit from the redhawk component bbclass.

Yes, i want to create new custom component for Target Hardware while building Redahwk with Yocto. As suggested, need to write .bbclass files. Can you please elaborate little more about how to write .bbclass for new components which for away different from existing components.

Because i want to add new implementation in custom component and load on to Target. As i observed, every time when i give build, the existing components are updated from github source, so changes will be erased from the workspace.

Can you suggest the way to create new custom component during yocto build.

Regards, Nayana

btgoodwin commented 3 years ago

I don't have a way to create a custom component during the yocto build. Usually we use the IDE to produce a standard CPP component, and then your recipe's contents would do something like this:

# other body contents like summary, description, etc.  See the bitbake and yocto reference manuals.
SRC_URI = "<protocol>://<path to source"
S = "${WORKDIR}/path/to/cpp"
inherit redhawk-component

The do_unpack bitbake task will unpack a copy of the SRC_URI to the WORKDIR at which point our classes' patches take over to produce an alternate cpp-PACKAGE_ARCH implementation which can later be added in parallel to the other implementation(s) for that component (using this tooling).

Here is a fairly old example. In that example, the NO_SPD_PATCH flag was used.

NayanaAnand commented 3 years ago

Hi Thomas,

Okay, I am generating custom components in Redhawk IDE, but the generated components are built for 64bit system....but I need 32bit binary to load on my target Hardware.

Is there any way to change the architecture while generating custom components.

Regards, Nayana

btgoodwin commented 3 years ago

I don't understand the question. If you generate a basic component from the IDE and put it somewhere that the recipe can SRC_URI, the build environment should create a new implementation (cpp-PACKAGE_ARCH) compiled for that particular target based on whatever you have MACHINE set to in the build environment.

NayanaAnand commented 3 years ago

Hi Thomas,

Thank you for the Help, the solution given above is worked for me.

generate a basic component from the IDE and put it somewhere that the recipe can SRC_URI

Now, custom components are built for my Target hardware.

Regards, Nayana

btgoodwin commented 3 years ago

You’re welcome!

Cheers On Mar 9, 2021, 7:30 AM -0500, Nayana N R notifications@github.com, wrote:

Hi Thomas, Thank you for the Help, the solution given above is worked for me.

generate a basic component from the IDE and put it somewhere that the recipe can SRC_URI Now, custom components are built for my Target hardware. Regards, Nayana — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

NayanaAnand commented 3 years ago

Thank you for the support Thomas.

Regards, Nayana