orocos and wxwidgets

Submitted by vri on Fri, 2008-12-12 16:40

RTT-dev

Hello,

I'm trying something which is possibly not a good idea: combining orocos TaskContexts with a wxWidgets app.

Initialization of taskcontexts etc. seems ok. However, a problem occurs when I attach an activity to the execution engine. The logger reports:
[ Info ][ExecutionEngine::setActivity] myTask is not periodic.
[ Info ][ExecutionEngine::setActivity] myTask is disconnected from its activity.

The second message occurs almost immediately after the first. The same thing happens when I use a periodic task.

What can be the cause of this? Is it maybe due to incompatible thread implementations? What can I do to see what is happening? Even better, to resolve the problem?

Any suggestion is much appreciated!

Cheers, Theo.

orocos and wxwidgets

Submitted by sspr on Mon, 2008-12-15 10:00.

On Friday 12 December 2008 17:40:08 t [dot] j [dot] a [dot] devries [..] ... wrote:
> Hello,
>
> I'm trying something which is possibly not a good idea: combining orocos
> TaskContexts with a wxWidgets app.

It should work. We shouldn't be incompatible with any library.

>
> Initialization of taskcontexts etc. seems ok. However, a problem occurs
> when I attach an activity to the execution engine. The logger reports: [
> Info ][ExecutionEngine::setActivity] myTask is not periodic.
> [ Info ][ExecutionEngine::setActivity] myTask is disconnected from its
> activity.

Is this the same information as you get with ORO_LOGLEVEL=6 ? You're not using
the deployer ?

Are you using svn or 1.6.0 ?

>
> The second message occurs almost immediately after the first. The same
> thing happens when I use a periodic task.
>
> What can be the cause of this? Is it maybe due to incompatible thread
> implementations? What can I do to see what is happening? Even better, to
> resolve the problem?

This happens when your activity object is destroyed. Maybe your initialisation
code is wrong and accidentally destructs it again ? Orocos (1.6.0) does not
by itself delete activities.

Peter

orocos and wxwidgets

Submitted by vri on Tue, 2008-12-16 12:30.

You were right, Peter, the activity was accidentally destructed.
My loglevel was already 6 (INFO), after raising it to 7 (DEBUG) this was immediately shown. Lesson learned...

Thank you very much for your assistance!

Theo.

orocos and wxwidgets

Submitted by vri on Mon, 2008-12-15 17:56.

Good to hear that there should be no problems with any library.

I use version 1.4 (have to, I'm afraid, for now, because of running app). I'm not using the deployer.
I will check with ORO_LOGLEVEL=6 tomorrow.

Accidental destruction of the activity, that must be it. Will check...

I'll keep you posted.

Theo.

orocos and wxwidgets

Submitted by snrkiwi on Fri, 2008-12-12 17:10.

Are you calling the _ _os_init() function prior to doing anything with Orocos? You need to do this to setup the Orocos runtime environment. There's also a _ _os_exit() you need to call prior to exiting main, to cleanup.

We've succesfully integrated Orocos with Qt4, and it works fine. See example below ...
S

{{{
int
main(int argc, char* argv[])
{
int rc;

// Orocos pre-main startup
if (0 != __os_init(argc, argv))
{
std::cerr

orocos and wxwidgets

Submitted by snrkiwi on Fri, 2008-12-12 17:08.

We've succesfully integrated Orocos with Qt4, and it works fine. See example below ...
S

{{{
int
main(int argc, char* argv[])
{
int rc;

// Orocos pre-main startup
if (0 != __os_init(argc, argv))
{
std::cerr << "Unable to start Orocos" << std::endl;
return -1;
}

RTT::TaskContext* proxy = findRemote(argc, argv); // custom code, which finds the remote system
if (NULL != proxy)
{
// run Qt app
QApplication a( argc, argv );
QMainWindow* w = new robot::gui::MainWindow(proxy);
w->show();
rc = a.exec();

RTT::Corba::ControlTaskProxy::DestroyOrb();
}
else
{
rc = -1;
}

// post-main shutdown
__os_exit();
return rc;
}
}}}

orocos and wxwidgets

Submitted by vri on Tue, 2008-12-16 12:41.

Ok, the following seems to work (so far).

Suppose we have an application class called MyApp.

We need to remove the standard wxwidgets macro

IMPLEMENT_APP(MyApp)

as this implicitly declares main. Instead, we write our own main and explicitly call the wxwidgets main loop in the same style as above:

int
main(int argc, char* argv[])
{
     // Orocos pre-main startup
    if (0 != __os_init(argc, argv))
    {
        std::cerr << "Unable to start Orocos" << std::endl;
        return -1;
    }
 
    //the next two lines do the same as the standard wxwidgets macro IMPLEMENT_APP(MyApp);
    // create the app
    wxApp* pApp = new MyApp();
    // initialize and start the wxwidgets main loop;
    wxEntry(argc, argv);
 
    // post-main shutdown
    __os_exit();
    return 0;
}

I myself have coded the orocos functionality in the frame.

Hope this helps someone.

Theo.

orocos and wxwidgets

Submitted by vri on Mon, 2008-12-15 17:50.

Thank you for your suggestions, S. Yes, I try to do __os_init (and __os_exit). But your code has shown me a better way, so I'll work on it.

I'll report back when I have found a proper way.

Theo.

orocos and wxwidgets

Submitted by sspr on Mon, 2008-12-15 10:00.

On Friday 12 December 2008 18:08:00 kiwi [dot] net [..] ... wrote:
> Are you calling the _ _os_init() function prior to doing anything with
> Orocos? You need to do this to setup the Orocos runtime environment.
> There's also a _ _os_exit() you need to call prior to exiting main, to
> cleanup.
>
> We've succesfully integrated Orocos with Qt4, and it works fine. See
> example below ... S
>
> {{{
> int
> main(int argc, char* argv[])
> {
> int rc;
>
> // Orocos pre-main startup
> if (0 != __os_init(argc, argv))
> {
> std::cerr

It seems the html filter on the forum is a bit to harsh and most of the C++
content disappears when apearing on the mailing list. Does someone wants to
figure this out ?

Peter