Error when loading sl_quadrotor_vs

[nguye...@gmail.com]

Dear everyone,

I am trying to load sl_quadrotor_vs, but there are some errors described as follows:

"Error evaluating 'InitFcn' callback of block_diagram 'sl_quadrotor_vs'.

Caused by:

Undefined function 'SphericalCamera' for input arguments of type 'char'."

I'm using Matlab R2015b and i've installed RTB-10.1 zip format.

Could you please help to give a solution?

Thank you so much!

[Erik van Oene]

Hi,

Can you check the result of:

which SphericalCamera

If the result is:

'SphericalCamera' not found.

you probably didn't (correctly) install the (vision part of the) toolbox.

Erik
Op vrijdag 20 april 2018 15:51:16 UTC+2 schreef Ryan Pham:

[Ryan Pham]

Hi Erik,

Thanks for your help.

Can you guide me how to install the vision toolbox and use the "sl_quadrotor_vs.mdl" file correctly?

Because now i have this new issue after installing MVTB in my own way:

"Error evaluating 'InitFcn' callback of block_diagram 'sl_quadrotor_vs'.

Caused by:

The specified superclass 'SO3' contains a parse error or cannot be found on MATLAB's search path, possibly shadowed by another file with the same name."

Thank you!

[Peter Corke]

Ryan, could you install my Robotics Toolbox as well.  These complex visual servo example have dependencies on both toolboxes.

[Ryan Pham]

Dear Professor Peter Corke,

I have already installed both toolboxes and also tried a lot of couple (RTB and MVTB version), but the file "sl_quadrotor_vs" always show that there are some errors.

I have searched for this problem on this group and i find that this problem is still not solved (through this post:"Installation of robot-10.1.mltbx deletes the installed Machine Vision Toolbox?", one guy have the same problem as me).

Luckily, i still read post:"Problem with sl_quadrotor_vs demo" by Matteo Morelli and i found out that the couple RTB 9.10 and MVTB 3.4 work well for the file "sl_quadrotor_vs".

Anyway, the version MVTB 3.4 is no longer available on your website. Do you still keep the installation file MVTB 3.4? If yes, could you please send me a link to download that?

Thank you very much!

[Peter.I.corke]

The toolbox deletion problem is fixed

Can you try for me

>> which rotx

>> which rpy2tr

Peter.

Sent from my iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "Robotics & Machine Vision Toolboxes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/robotics-tool-box/ht2uXg73UsU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to robotics-tool-...@googlegroups.com.
To post to this group, send email to robotics...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotics-tool-box.
For more options, visit https://groups.google.com/d/optout.

[Peter Corke]

You can get 3.4 from the web page for the old book at http://www.petercorke.com/RVC1/

peter

[Ryan Pham]

Dear Professor Peter Corke,

Sorry for replying too late. I have installed Matlab R2017b and the latest version RTB-10.2 and MVTB-4.3.

The old error is fixed but now there is a new problem described as follows:

"Error in port widths or dimensions. Output port 1 of 'sl_quadrotor_vs/lambda' is a one dimensional vector with 1 elements."

and

"Error in port widths or dimensions. Input port 1 of 'sl_quadrotor_vs/Demux' is a one dimensional vector with 4 elements."

The output signal of "lambda" block is the input signal of "Demux" block.

In my opinion, i think the "visual Jacobian" block is wrong, because the output signal must be [4x6] matrix.

Could you please help me to give a solution?

Thank you very much!

[Peter Corke]

Hi Ryan,

I am mystified by this.  On my machine, running the distributed versions of the toolboxes but with 18a everything is fine.  I am sure it was fine under 17a also.  See comments below 

On Tuesday, 15 May 2018 13:02:30 UTC+10, Ryan Pham wrote:

Dear Professor Peter Corke,

Sorry for replying too late. I have installed Matlab R2017b and the latest version RTB-10.2 and MVTB-4.3.

The old error is fixed but now there is a new problem described as follows:

"Error in port widths or dimensions. Output port 1 of 'sl_quadrotor_vs/lambda' is a one dimensional vector with 1 elements."

and

it should have 4 elements

 

"Error in port widths or dimensions. Input port 1 of 'sl_quadrotor_vs/Demux' is a one dimensional vector with 4 elements."

The output signal of "lambda" block is the input signal of "Demux" block.

In my opinion, i think the "visual Jacobian" block is wrong, because the output signal must be [4x6] matrix.

It should be an 8x6 matrix.  There are 4 points, so 8 coordinates, so 8 rows.  To confirm, the output of the block P is 3x4?

[Ryan Pham]

Thank you for replying sir,

On my machine, the block P is [3x4] matrix.

I think that the input of "visual Jacobian" block, which is the output of "camera" block, is wrong. On my machine, the output signal of "camera" block is [28x1],is that true, can you check it please?

I have send you the picture of "camera" block and there are also inputs and outputs's dimension of signal when i run on my computer. Can you check it which part is wrong please?

Because i have tried this model on many friend's computers, but this error always appear. I don't have any well-worked model to find out which part of my machine is wrong.

[Ryan Pham]

Dear,

Eureka! I have found out the error. The reason is the function "slcamera.m" is missing from the toolbox. I have downloaded it from the post "simulink error about the model sl_ibvs in the vision-4.3 toolbox". Now, the dimension is totally ok.

But now when i run it, i meet new error:

"An error occurred while running the simulation and the simulation was terminated

Caused by:

Error due to multiple causes.

Struct contents reference from a non-struct array object.

Error in 'sl_quadrotor_vs/camera/MATLAB Fcn' while evaluating expression."

Can you have me to find a solution for this, please?

[Ryan Pham]

I also modify the "slcamera.m"  like your instruction in post "simulink error about the sl_arm_ibvs", so the first 2 lines look like this:

function p = slcamera(cam, u)

             u'

This is the output of the diagnostic view when i run the simulation:

[tkm.i...@gmail.com]

Dear  Ryan Pham,

I have found the same error. Do you have any idea about how to fix it.

Thank you very much.

-Tapas

[Peter Corke]

It's not clear what the error is.  The diagnostics that Ryan lists are normal and not indicative of any error.

Can you send me the error message.

If your error message is:

An error occurred while running the simulation and the simulation was terminated

Caused by:

Error due to multiple causes.

Dot indexing is not supported for variables of this type.

Error in 'sl_quadrotor_vs/camera/MATLAB Fcn' while evaluating expression.

Then change line 9 of slcamera to

p = cam.plot(P, 'pose', Tcam, 'drawnow');

peter

[jann...@gmail.com]

Hi,

I just downloaded both toolboxes (vision-4.3 and robot-10.2 - using Matlab 2017b) and ran into the same problems listed here. 

The error message is:

The simulink block with dimensional information is:

 

The second error message I get (relating to camera) is as per the previous post but line 9 of my slcamera file is the same as the text recommended in this post.

Any suggestions on how to resolve this?

Thanks,

Jan

[Peter Corke]

Hi Jan,

change line 9 of slcamera.m to

        p = cam.plot(P, 'pose', SE3(Tcam), 'drawnow');

and the error will go away.  This is my bad, incomplete changes to support RTB10.  

Now I can run the model but the quad doesn't take off or even move.  It's been a long time since I ran the model (Simulink models are hard to unit test) and right now I'm not quite sure what's going on.  I'll try to look into this over the coming week.

peter

[Peter Corke]

Hi Jan,

you need to also change where the image-plane set points are computed, this is in an initialisation function.  From the Simulink block menu go to File/Model Properties/Model Properties, then hit the Callbacks tab, then select InitFcn* and update line 10.

pstar = camera.project(P, 'pose', SE3(0, 0, -5)*SE3.Rz(pi/2));

Now the quad rotor should "fly"

peter

[Ryan Pham]

Hi,

Now the file is working correctly. Thank you very much for your help.

Do you have any advice to make the simulation become more faster?

Because for 10sec, it takes me around 20mins.

Thanks,

Ryan.

[jann...@gmail.com]

Hi Peter,

Thanks for looking / the quick response - will keep an eye out for updates. 

Jan

[Peter Corke]

Did that fix work for you?

peter

[Peter Corke]

Wow, that's pretty slow.  My 2016 MacBook Pro (2.7GHZ i7) does it in 170s, that's 7x faster than yours.

Things to speed it up:

- remove graphics: the image plane view and/or the quad rotor view.  Maybe selectively remove them to see which one is the time hog

- experiment with integration parameters, perhaps go to a fixed time step solver.

peter

[jann...@gmail.com]

Hi Peter,

Yes thanks a lot - the fix worked worked exactly as you described it.

Sorry, meant to reply earlier but I have also noticed that the simulation runs pretty slowly and was planning to first take a look at methods for speed up the run time. Is the running speed also sub real time for you Peter? and if so does this seem congruent with the workload being done by the simulator?

Thanks!

Jan

[Peter Corke]

Mine is still 17x slower than clock time.  I suspect the graphics are a big part of the slow down. Simulink also gives you options to compile a lot of the code and deploy it on a target platform.  It’s a complex but powerful beast, worth spending some time getting into the details

peter

[Jan Stankiewicz]

I tried commenting out various blocks yesterday to see what twas contributing to the slowdown - "quadcopter_dynamics" seemed to be the main problem. Although there are probably better ways of profiling I've read that s-functions can be inefficient:

e.g. "Your model includes a MATLAB file S-function. MATLAB file S-functions also call the MATLAB execution engine at each time step. Consider converting the S-function either to a subsystem or to a C-MEX file S-function"

So I think taking the recommended action here could be the way forward as far as performance is concerned. Happy to have a look at it at some point and feedback although it could be a few weeks before I get chance.

Jan

peter

To unsubscribe from this group and all its topics, send an email to robotics-tool-box+unsubscribe@googlegroups.com.
To post to this group, send email to robotics-tool-box@googlegroups.com.

Visit this group at https://groups.google.com/group/robotics-tool-box.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Robotics & Machine Vision Toolboxes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/robotics-tool-box/ht2uXg73UsU/unsubscribe.

To unsubscribe from this group and all its topics, send an email to robotics-tool-box+unsubscribe@googlegroups.com.
To post to this group, send email to robotics-tool-box@googlegroups.com.

[Peter Corke]

Hi Jan,

that makes sense, though I would have thought that graphics would have been costly despite their primitive nature.  Implementing as a C-MEX file would improve performance but take a bit of work.  I spent a few minutes attacking it with the MATLAB codegen tool to do this automatically, but it's not straightforward.  Maybe possible but it'l take a bit of thought and fiddling (and you need to have a licence to use it).

An alternative is to do what Jörn Malzahn did for robot manipulators, plug in symbols, evaluate the dynamics symbolically, simpllify, then export as C code.  You'd need to tackle the mdlOutputs and mdlDerivatives functions separately. This would take care of the heavy lifting of coding this in C.  Jörn's code gives improvements of 1000x to 10,000x for robot manipulators.

I'd be happy to include this in RTB with credit if you did it.

peter

[Peter Corke]

Hi Jan,

I renamed this thread.

Attached is a really quick hack of the quadrotor_dynamics, using symbolic toolbox to generate C code for the derivative and output functions.  It shows the general idea.  MATLAB has done symbolic simplification and optimisation of the generated C code, the compiler will do more.  It could be worth benchmarking this C code and the MATLAB code to get some idea of the performance win.

You still need to do the MEX glue code to interface to Simulink.

peter

[Jan Stankiewicz]

Hi Peter,

Great, I haven't used this approach before but will look into it. I'm working towards a review at the moment but will take a stab at it once that's complete... unless someone beats me to it. Benchmarking a good idea, there may other modelling approaches as well - e.g. in this project  they use simulink blocks and user defined functions to model the dynamics.

Jan