Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

using joystick inputs with Matlab

589 views
Skip to first unread message

Kate Jacobsen

unread,
Aug 19, 2008, 11:48:01 AM8/19/08
to
I'm planning to use a joystick input to a gui coded using
Matlab's GUIDE. I have reviewed Matlab's documentation
about joystick inputs, and it appears that I need to use
the Simulink block for joysticks. I have a couple of
questions:

1) am I missing any documentation about joysticks and
Matlab -- is there a way to use a joystick input *without*
having to use Simulink, e.g., by adding a function to my
Matlab GUIDE code? Any suggestions about how to use
joystick input without having to use Simulink would be
appreciated.

2) if I do use the Simulink joystick block, will the
system still run in real time? I have attempted to use the
RealTime Simulink block in the past, but have only ever
received error messages. I will need my gui to accept
inputs and run in real time.

Thanks for any information you can provide!

Kate Jacobsen

unread,
Aug 20, 2008, 12:30:19 PM8/20/08
to
Anyone have experience with joystick input to Matlab/GUIDE?

Walter Roberson

unread,
Aug 20, 2008, 1:08:27 PM8/20/08
to
Kate Jacobsen wrote:
> I'm planning to use a joystick input to a gui coded using
> Matlab's GUIDE. I have reviewed Matlab's documentation
> about joystick inputs, and it appears that I need to use
> the Simulink block for joysticks. I have a couple of
> questions:

> 1) am I missing any documentation about joysticks and
> Matlab -- is there a way to use a joystick input *without*
> having to use Simulink,

You can also use joysticks with the Aerospace blockset,
or the Virtual Reality Toolbox, and you can use analog joysticks
with the Real Time Workshop.

There are also facilities available with the psychophysics.org
toolbox, most directly if you are using OS-X.

> e.g., by adding a function to my Matlab GUIDE code?

I make it a policy not to speculate on what can or cannot be done
with GUIDE: to me the probability is too great that after you have
done all the hard coding that *should* work, that some oddity of GUIDE
will interfere. The only way to know is to try to implement it for
a few months and eliminate all of the GUIDE peculiarities one by one
until eventually it works or you hit something that GUIDE just won't
cooperate with. I do not consider reverse-engineering the innards of
GUIDE to be a productive use of my time, so I skip GUIDE and work
in Matlab directly.

If you are working in Matlab directly, on MS Windows, then,
http://www.ece.utah.edu/~bodson/fun/index.html
has a joystick DLL.


--
Q = quotation(rand);
if isempty(Q); error('Quotation server filesystem problems')
else sprintf('%s',Q), end

Kate Jacobsen

unread,
Aug 20, 2008, 1:19:02 PM8/20/08
to
Thanks for your input, Walter.

My basic question is, if I try to code my gui using only
Matlab and not GUIDE, would Matlab have as much gui
functionality as GUIDE does? I'm concerned that making a
gui in Matlab may be low-level and time consuming... your
thoughts?

Walter Roberson

unread,
Aug 20, 2008, 2:42:25 PM8/20/08
to
Kate Jacobsen wrote:

> My basic question is, if I try to code my gui using only
> Matlab and not GUIDE, would Matlab have as much gui
> functionality as GUIDE does?

GUIDE generates matlab code, so there is nothing you can do in
GUIDE that you cannot do in Matlab directly.

> I'm concerned that making a
> gui in Matlab may be low-level and time consuming... your
> thoughts?

When you are working within the limits of what GUIDE was designed
for, it can be useful for putting together a GUI with much reduced
hand-programming. The further away you get from what GUIDE was designed
for, the less important of a factor that becomes, until eventually
GUIDE becomes a hindrance, blocking you from doing things you can
readily do with a few lines of Matlab.

The key convenience that GUIDE provides is in placing GUI items and
finding the resulting coordinates, so that you do not have to guess
and use trial-and-error to find out what looks good. Unfortunately
what you get out of GUIDE as a result is a bunch of "magic numbers"
in the code, just pure arbitrary coordinates with no logic to them, so
modifying the generated code afterwards becomes a real headache.

I dealt with this issue by developing a small library of routines.
One subset figures out how big a gui element "should be" (e.g.,
reads off the String property of a popupbox, finds out how much space
would be needed to render that text, adds a margin for the "arrow"
to select other elements, resizes the gui element "shrink wrapped" around
the size really needed.) The other subset places elements relative to
other elements -- e.g., moves a gui element to underneath the bottom-left
corner of another, or moves a gui element so the vertical centers line up.
Having written that library, my code now contains very few explicit
'Position' specifications and very few arbitrary coordinates: I place
the top-left element with reference to the figure size and then I
dynamically make each new item the "right" size and dynamically place it
relative to the existing elements.

Unfortunately, I don't think I can release the relevant code, as it is
part of what is an internal research project at this point: getting
clearance from our patent people would be a trial, as it would have to
be reviewed in case the GUI code just happened to reveal information about
the research project itself.

Kate Jacobsen

unread,
Aug 20, 2008, 3:29:01 PM8/20/08
to
Thanks for your detailed explanation... I'll have to weigh
the convenience of GUIDE vs. the extended capabilities of
using only Matlab. Good food for thought.
0 new messages