Orocos4Simulink - matlab algorithm not running properly

Submitted by chitotest1 on Tue, 2010-08-03 16:05

Orocos-users

Hi.

I developed a very simple simulink model (RptCtl). It succesfully compiled into an Orocos component. I loaded is using the Deployer and connected its ports to the ports of a peer (the RSIServer component developed by you guys). So far so good.

The communication between ports seems to be working Ok ('ls RptCtl' and 'ls RSIServer' show the right values on the ports). However, the internal matlab algorithm works rather strangely.

What it SHOULD DO after RptCtl.start:

set element 4 of the output port array to 0.05, element 4 of input array should increase at a constant rate. When the value of the input port element is greater than 20, the element of the output port should be set to 0.

What it DOES after RptCtl.start:

sets element 4 of the output port array to 0.05, element 4 of input array increases at the expected constant rate (as reported in 'ls RptCtl'). When the value of the input port element is greater than 20, the element of the output port stays in its current value. After 'RptCtl.stop', '.cleanup', '.configure', the output value is again set to 0.0, but after '.start' it is set again to 0.05 (looks like the values of the input port never reach the algorithm, i.e. are always 0.).

What am I doing wrong?

how can I print some debug info inside the model so I can see it while running the Taskbrowser?

My system: matlab 2010a Ubuntu linux 2.6.32.7 xenomai 2.51 Orocos 1.10.2

Attached you will find the simulink model (RptCtl.mdl_.txt, please remove the _.txt) and the file for the deployer (assignment-rpt.xml).

Regards,

Attachment	Size
assignment-rpt.xml	2.23 KB
RptCtl.mdl_.txt	28.87 KB

Orocos4Simulink - matlab algorithm not running properly

Submitted by Klaas Gadeyne on Wed, 2010-08-11 15:24.

On Tue, Aug 3, 2010 at 6:05 PM, <jpmzometa [..] ...> wrote:
> Hi.
>
> I developed a very simple simulink model (RptCtl). It succesfully compiled
> into an Orocos component. I loaded is using the Deployer and connected its
> ports to the ports of a peer (the RSIServer component developed by you
> guys). So far so good.
> The communication between ports seems to be working Ok ('ls RptCtl' and 'ls
> RSIServer' show the right values on the ports). However, the internal matlab
> algorithm works rather strangely.
> What it SHOULD DO after RptCtl.start:
>
> set element 4 of the output port array to 0.05, element 4 of input array
> should increase at a constant rate. When the value of the input port element
> is greater than 20, the element of the output port should be set to 0.
>
> What it DOES after RptCtl.start:
>
> sets element 4 of the output port array to 0.05, element 4 of input array
> increases at the expected constant rate (as reported in 'ls RptCtl'). When
> the value of the input port element is greater than 20, the element of the
> output port stays in its current value. After 'RptCtl.stop', '.cleanup',
> '.configure', the output value is again set to 0.0, but after '.start' it is
> set again to 0.05 (looks like the values of the input port never reach the
> algorithm, i.e. are always 0.).
>
> What am I doing wrong?

I've had a quick look at your model, so I might be talking nonsense
here. However, it looks like
1/ the desired behaviour you describe is (cannot?) not obtained solely
by your matlab component, but by the wiring of your ports?
2/ the embedded matlab function you are using seems to be simple
enough such that you can have a look at the generated code and figure
out what's wrong.

I would try this first before starting to do the somewhat harder
"wrapping" solution suggested by Peter.

HTH,

Klaas

Hello Klaas.Observation 1 is

Submitted by chitotest1 on Wed, 2010-08-11 15:52.

Hello Klaas.

Observation 1 is correct. My ports are, as far as I understand, connected as you can see from the deployer xml file I attached. I can see data coming and going in the ports. I am using a Kuka-robot with the RSI interface (the RSIServer components). The RIst port is the actual position of the robot, RKorr is the path correction (in other words, where I command a movement). As described before, when I start the matlab component (RptCtl), the robots starts moving (RKorr[4] > 0 and in RIst[4] I can read the real position of the robot), but after reaching the RIst[4] limit, the robot never stops. The matlab component works well on simulink simulations. I also wrote an equivalent component in C++ and that one works as expected.

Observation 2. I did take a look at the code. Unfortunately, I could not figure out was is wrong.

Thanks for your help though,

Regards,

Hello Klaas.Observation 1 is

Submitted by chitotest1 on Wed, 2010-08-11 15:49.

Hello Klaas.

Observation 2. I did take a look at the code. Unfortunately, I could not figure out was is wrong.

Thanks for your help though,

Regards,

Hello Klaas.Observation 1 is

Submitted by Klaas Gadeyne on Thu, 2010-08-12 07:28.

On Wed, Aug 11, 2010 at 5:49 PM, <jpmzometa [..] ...> wrote:
> Hello Klaas.
>
> Observation 1 is correct. My ports are, as far as I understand, connected as you can see from the deployer xml file I attached. I can see data coming and going in the ports. I am using a Kuka-robot with the RSI interface (the RSIServer components). The RIst port is the actual position of the robot, RKorr is the path correction (in other words, where I command a movement). As described before, when I start the matlab component (RptCtl), the robots starts moving (RKorr[4] > 0 and in RIst[4] I can read the real position of the robot), but after reaching the RIst[4] limit, the robot never stops. The matlab component works well on simulink simulations. I also wrote an equivalent component in C++ and that one works as expected.
>
> Observation 2. I did take a look at the code. Unfortunately, I could not figure out was is wrong.

Do you mean that you couldn't understand the code, or that the
generated code looked fine (after all, given your embedded matlab
code, we're talking about a few lines of code here)
One thing that could differ between your simulation in matlab and
reality is the fact that your SW components are executed in different
threads, whereas your matlab simulation does not -> debugger time...

Klaas

Hello Klaas.Observation

Submitted by chitotest1 on Thu, 2010-08-12 08:12.

The code snippet corresponding to the Matlab function was correct. I was not brave enough to try to tweak the rest of the generated code as I did not completely understand it and I rather not risk breaking the robot ;) I can only suspect the problem is on the input port. I will give it another try in the next days.

I mentioned the Matlab simulation just to make clear that the problem is not in the Matlab/Simulink code itself, but in the compiled component (or generated code). And as I said before, I wrote an equivalent version of the RptCtl component in C++, and that one works correctly in reality (i.e. using the robot). So, I was expecting the Matlab component to work identically.

Thanks for your help,

Hello Klaas.Observation 1 is

Submitted by chitotest1 on Thu, 2010-08-12 08:10.

Thanks for your help,

Hello Klaas.Observation

Submitted by Klaas Gadeyne on Thu, 2010-08-12 15:56.

On Thu, Aug 12, 2010 at 10:10 AM, <jpmzometa [..] ...> wrote:
> The code snippet corresponding to the Matlab function was correct. I was not brave enough to try to tweak the rest of the generated code as I did not completely understand it and I rather not risk breaking the robot ;) I can only suspect the problem is on the input port. I will give it another try in the next days.
>
> I mentioned the Matlab simulation just to make clear that the problem is not in the Matlab/Simulink code itself, but in the compiled component (or generated code). And as I said before, I wrote an equivalent version of the RptCtl component in C++, and that one works correctly in reality (i.e. using the robot). So, I was expecting the Matlab component to work identically.

FWIW:
If you have the C++ component, the wrapping process described by Peter
is rather simple, all you need to do is generate the code using the
ERT target and modify your component code st. it looks like

#include <mysimulinkheader.h>
 
...
 
bool mycomp::starthook()
{
  return mysimulinkmodel_initialize();
 
void mycomp::updatehook()
{
  mysimulinkmodel_U.In1 = MyPort.Get();
 
  mysimulinkmodel_step();
 
  MyPort.Set(mysimulinkmodel_Y.Out.1);
}
 
Check for the real names in your header files, that is.
 
This will allow you to check whether the problem is really due to the
orocos tlc target or not.
 
Klaas

Orocos4Simulink - matlab algorithm not running properly

Submitted by peter on Thu, 2010-08-05 21:16.

On Tuesday 03 August 2010 18:05:34 jpmzometa [..] ... wrote:
> Hi.
>
> I developed a very simple simulink model (RptCtl). It succesfully compiled
> into an Orocos component. I loaded is using the Deployer and connected its
> ports to the ports of a peer (the RSIServer component developed by you
> guys). So far so good.
>
> The communication between ports seems to be working Ok ('ls RptCtl' and 'ls
> RSIServer' show the right values on the ports). However, the internal
> matlab algorithm works rather strangely.

I believe it's possible to create logs (ie store in mat files), but I haven't
looked at this code for a long time. What you might be seeing is an issue with
the code generator, and debugging has in such a case little sense. It might
make more sense to inspect the generated .c file instead.
For some reasons, our .tlc file triggers some awkward bugs, that persist
accross matlab releases. It was reported to The MathWorks, but I have no
longer the follow-up.

What some people have done to work around this is, *not to use the toolkit*
and to generate the code to a generic C++ target and then call that code from
a custom written Orocos component. It's not such a big effort (it maps nicely
to configureHook/updateHook, but you need to create your own ports and
properties though in C++ and wire them to the parameters and ports of your
model.

Peter

Simulink4Orocos - matlab algorithm not running properly

Submitted by chitotest1 on Fri, 2010-08-06 08:08.

Thanks Peter.

That's a pity. My colleagues are more comfortable writing Matlab code than C++ code ;)

I'll give your suggestion a try. Do you have by chance a nice example on how to achieve the not-to-use-the-toolkit alternative?

Regards,

P.S. your CAPTCHAs are driving me crazy!

Simulink4Orocos - matlab algorithm not running properly

Submitted by chitotest1 on Fri, 2010-08-06 08:05.

Thanks Peter.

That's a pity. My colleagues are more comfortable writing Matlab code than C++ code ;)

I'll give your suggestion a try. Do you have by chance a nice example on how to achieve the not-to-use-the-toolkit alternative?

Regards,

P.S. your CAPTCHAs are driving me crazy!

Orocos4Simulink - matlab algorithm not running properly

Submitted by chitotest1 on Tue, 2010-08-03 16:16.

Hi.

The communication between ports seems to be working Ok ('ls RptCtl' and 'ls RSIServer' show the right values on the ports). However, the internal matlab algorithm works rather strangely.

What it SHOULD DO after RptCtl.start:

What it DOES after RptCtl.start:

What am I doing wrong?

how can I print some debug info inside the model so I can see it while running the Taskbrowser?

My system:
matlab 2010a
Ubuntu linux 2.6.32.7
xenomai 2.51
Orocos 1.10.2

Attached you will find the simulink model (RptCtl.mdl_.txt, please remove the _.txt) and the file for the deployer (assignment-rpt.xml).

Regards,