I am writing code for rrt(rapidly exploring random trees) which is a sampling based motion planning algorithm.I wrote the code in MATLAB but now i am writing it in c++.
I want to know how can we plot the robot path in real time with all the obstacles.
What I want is this: I want to see my robot traversing the space.So basically it's about the graphics.I am trying to use sfml but I am having problems with it.Some people suggested using opencv or opengl but I think they are not easy to use.I am looking for a simple to use library.
If opencv or opengl is the answer then please tell me what specifically i need to use in these libraries.I am working on linux(ubuntu 11.10)
You might want too look into using the internal matlab compiler for generating a standalone application directly from your M-code. That way you don't have to rewrite everything form scratch.
I have used the following link a couple of times just to refresh my memory
http://technologyinterface.nmsu.edu/5_1/5_1f/5_1f.html
Eg if you have made an M function with the following content(Example from link):
function y=PolyValue(poly,x)
poly=[1 2 -1 4 -5];
x=[5, 6];
y=polyval(poly, x)
you could use the command
mcc -m PolyValue
to compile the program.
This command would then give you the files necessary for implementation in a larger c++ program.
It should even support Gui elements and graphs.
Something like http://www.ros.org/news/2011/01/open-motion-planning-library-ompl-released.html
may be what you are looking for.
I've worked in both OpenCV for some image recognition projects and OpenGL for rendering displays and whether you go with a library like above or render it yourself is really up to how complex the display needs to be. Ask yourself some questions about how many different obstacle scenarios you are looking at. Are there a large multitude of possible shapes for the obstacles and the robot? Is the problem deterministic (in terms of both the robot's movement and the environment)?
In terms of OpenGL and OpenCV being not easy to use for those new to them, this is very much the case, but choosing to work in C++ makes the problem more difficult for beginners. As another user has mentioned, wrapping your Matlab code instead of throwing it away may be a viable option. Even running the matlab engine in the background to run your scripts through C++ may be viable, if speed is not a critical factor. See http://au.mathworks.com/help/matlab/matlab_external/introducing-matlab-engine.html for more information.
I am trying to understand few things on Mac related to OpenGL framework integration in the form of layers. Well basically when I want to understand 3D technologies present in OS X and which layer is OpenGL's actual implentation layer.
From reading apple docs, below is what I have understood so far:
1.NSOpenGLContext object wraps a low-level, platform-specific Core OpenGL (CGL) context.
= This makes it clear that NSOpenGL makes use of CGL.
2.The AGL (Apple Graphics Library) API is part of the Apple implementation of OpenGL in Mac OS X.
= So, does AGL and CGL are related in any way?
3.CGL (Core OpenGL) is the lowest-level programming interface for the Apple implementation of OpenGL.
= Does it mean Standard OpenGL API's are just wrapper over CGL?
4.CoreAnimation seems to be combo of Core Graphics, Open-GL and Quick-time. But I am not sure what it uses underneath it, I mean actual implementation layer, is it again CGL?
Things are not completely clear to me. I am still reading though and I have asked somewhat related question in past but with incomplete knowledge.
I would really appreciate if someone can share his understanding on matter.
NSOpenGLContext, AGL and CGL are all APIs for setting up an OpenGL context you can draw into.
Use NSOpenGLContext unless you already know you have a reason not to.
Use AGL if you are writing a Carbon application or if you need compatibility with Mac OS 9 (As of 2012, that basically means: don't).
Both AGL and NSOpenGLContext are implemented on top of CGL. However, not all the necessary parts of CGL are actually public APIs. Last time I checked, the only public parts of the CGL API where the ones that allow you to create a fullscreen OpenGL context. If you want OpenGL in a window or you want the option of showing dialog boxes or some NSViews on top of your OpenGL, you probably can't use CGL.
CoreAnimation is a framework for (mostly UI) animations; you can use CoreAnimation without using OpenGL directly. I have never used it myself, but I assume it also allows you to create an OpenGL context for an animation layer. Use it if you already have other reasons to use CoreAnimation, or if you want to combine OpenGL graphics and Mac GUI widgets in creative ways.
I'm starting to learn openGL on the mac, and being a cocoa developer already I find the native windowing system to be very appealing.
The books I'm reading all mentions the use of GLUT. Now, I'm wondering what the majority of people use for developing opengl programs, or if it's just a matter of taste.
Generally (Free)GLUT is not used for developing actual applications. It's used for demoing effects or simple things, which is why so many online materials use it. It takes all the cross-platform stuff and shoves it into a corner, thus focusing the user's attention on OpenGL.
GLUT owns the message processing loop. For simple applications, that's fine. But for most real programs, you will need to control message processing on your own. So GLUT fails. Also, GLUT doesn't really mesh well with the rest of the UI; it has no facilities for creating GUI controls (except for context menus).
If you're learning OpenGL, then you should be focused on learning OpenGL, not GUI programming. So use what makes sense for the task in question.
I am in the process of starting a project and whilst the logic part is relatively simple for me to mull through I am not very experienced with creating GUIs.
If you are not familiar with node based workflow here are a few examples
Nuke (The Foundry)
Max/MSP (Cycling 74)
SoftImage (AutoDesk)
The problems I have is where to start, What kind of object should I use to encapsulate the node gui? Or How would I go about making custom GUI elements that are click-drag/movable within a workspace? Are there any Books you recommend or anything you can link me too that would be able to get me up to speed.
Thank You
Your node view will derive from NSView, and I imagine that you'll want to use CALayers for your nodes.
You may find it helpful to look at some opensource Cocoa frameworks that implement custom views. Two that spring to mind are TwUI and GCDrawKit. Neither are a drop-in solution for what you want but they should give you an idea about how to architect complex custom views in Cocoa.
I recommend you use interface builder and the AppKit framework. A good introductory book is Cocoa Programming for Mac Os X
I've been developing for Windows and *nix platforms for quite some time, and am looking to move into Mac development. I am tossing up between using ObjC/Cocoa and C++/Qt4.5.
The C++/moc semantics make more sense to me, and improving knowledge in Qt seems like a sensible thing to do given that you end up with a skill set that covers more platforms.
Am I likely to handicap my applications by skipping Cocoa?
The sample Qt applications look pretty Mac-native to me, but they are quite simple so potentially don't tell the whole story. Are there other pros to the Xcode way that Qt doesn't have, such as packaging, deployment, etc.?
Here's an easy way to answer it:
If you were developing a Windows app with .NET or MFC, would you handicap your applications by using Qt? If the answer to that is yes, then the situation is likely to be the same on the Mac.
A few negatives I can think of off the top of my head:
Licensing
Qt apps, while good, are not completely a native UI experience and there's things a native UI designer can do in Cocoa which boggle the mind. While I can't be sure that all the same functionality isn't available in Qt, I doubt it.
Qt is always a little behind. If Microsoft or Apple come out with a great new technology, you have to wait for the Qt developers to update Qt.
However, with all that said, only you can determine the business value of using Qt. If you think cross-platform development is going to be a major part of your development, then Qt might be worth it, despite the issues mentioned.
Ask yourself: how many of the best Mac applications that you know of use Qt instead of native Cocoa?
For our robotic systems, we originally wrote our control software in C++ using the cross-platform wxWidgets library (we avoided Qt due to some licensing concerns), because we felt that we had to target Windows, Linux, and Mac platforms for our end users. This is what we shipped for over a year until I started tinkering with Cocoa.
Right away, the thing that most impressed me was how quickly you could develop using Cocoa. Eventually, we decided to drop support for Linux and Windows and rewrite our entire control applications in Cocoa. What had taken us years to put together in C++ required only three months to completely reimplement in Cocoa.
Aside from the "lowest common denominator" interface issues that others have pointed out, the rapid development allowed by Cocoa has become a competitive advantage for our company. Our software has advanced far more quickly since our conversion to Cocoa, and it has allowed us as a new company with one developer to pull even with 10-year-old competitors that have 20-man development teams. This appears to be a common story in the Mac development space, where you see a lot of small teams who are able to create products that compete with those of much larger companies.
As a final note, using Cocoa gives you the ability to stay on top of the new APIs Apple is continually rolling out. We're now working on a new control interface that will make heavy use of Core Animation, something that would be painful to deal with using Qt.
I'm currently developing both with QT (actually PyQT, but it makes no difference to your question) and native Cocoa app. For me it's no brainer, I'd chose Cocoa. It's really worth time to explore Cocoa in general, there are many great concepts within the Cocoa framework, and Objective-C 2.0 as well.
I'd use Qt if you want this to be a crossplatform application.
You can have a look at the QMacCocoaViewContainer class. It acts as some kind of wrapper for generic Cocoa views, so you can also have Cocoa elements which are not officially supported by Qt.
Of course this means learning a little about Cocoa and Objective C and how a Cocoa UI would need to look like. But if you already know Qt well and if it’s not like your application is all and only about the GUI this could be a good way to go.
And don’t forget about the QMacStyle::WidgetSizePolicy or you won’t understand why your tables come out so huge.
Obviously, the best option is to use a cross platform suite that supports native widgets.
With QT4 you can build your base user interface. Then just add native support for your specific target platform.
Sure, Cocoa has a lot of fancy stuff (and you can still use them trough QT4), but let me be clear. I see a lot of fancy Apps on the AppStore, pretty ones, but most of then are just crap, expensive.. what ever. I really missed my Kate text editor, my okular viewer, my krita drawing software... those are just better than the commercial and expensive alternatives and are free. so i just tweak the source code a little bit too have a REAL native and great experience.
What if i have to use a linux app on my main computer with is a mac os x? or windows? or whatever? only?
For example, why on earth i have to buy a expensive ,fancy but far less featured image editor software for my mac like pixelmator when i can use a full featured real image manipulation software like Gimp? YES Gimp is gtk2 based which is a pain on any platform, specially on Mac because is really ugly. Gimp should be ported to QT4. Inkscape should be ported to QT4 too, and it would feel so great.
Is so simple to do.. gosh!
http://doc.qt.nokia.com/4.7-snapshot/demos-macmainwindow.html
Even you can add support for the the new native lion fullscreen feature, unified title and toolbar menus, etc
I , as a user, i really care about efficient, featured, good and cross platform apps, i don't really care about developer's convenience or laziness .
I do a lot of cross-platform development (Mac, Windows, Linux), and for some projects use Qt. It is a fine framework, and provides a rich class library. If you need to deploy on multiple platforms, cannot afford to spend the time/effort on platform-specific front-ends, or the "generic" support for each platform is sufficiently good, then use Qt.
However, Qt inevitably suffers in some ways from the lowest common denominator syndrome, and sometimes does not feel quite native enough. There are also certain features that are either difficult to support, or are simply not provided in the Qt libraries. So if you can afford the time and effort, or your app really demands the attention to detail and fit & finish, then developing separate front-ends may be worth it.
In either case, you ought to be writing your back-end (aka domain) code in a platform-neutral and front-end neutral manner. This way, the front-end is easily replaced, or modified between platforms.
You could always start with a Qt front-end and go for a quick time to market, then develop a native front-end down the line.
In practice, I've noticed that a Qt app on Windows looks most "native", while on Mac there are certain subtle telltale signs that make it look/feel not quite right. And Mac users tend to have much higher expectations when it comes to UI/UX!
Since posting this, i've been learning the Cocoa / Objective-C way, and have been quite impressed. Despite what I initially thought was quite a quirky syntax, Objc appears to be a very effective language for implementing UI code, and the XCode sugar - things like Core Data and bindings - make short work of all of the boring bits.
I spent a while with the QT examples and documentation before digging into cocoa, and tend to agree with what has been said above w.r.t being slightly behind the curve and less 'aqua-ish' - albeit from a fairly trivial inspection. If I absolutely had to be build a cross-platform app i'd probably use QT rather than trying to separate out the UI code, as it seems like it would provide close-enough visuals, but for mac only purposes, Cocoa seems like a definite win.
Thanks all for your responses, they've all been very helpful!
DO NOT use Qt for a Mac app. You will get no hardware acceleration for 2D rendering, and you will not be able to deliver ADA compliance.
Depending on what kind of apps you want to write, another contender is REALbasic now called Xojo.
The move from C++ is pretty easy (I have 15 years C++ experience) and the framework and IDE extremely productive. You have the added bonus of being able to deploy to Linux and Windows with trivial effort. Their framework compiles to native code and uses native widgets so you don't have an emulated look and feel.
The big reason for learning Cocoa and coding in Objective-C is if you want to hone your iPhone skills or are chasing a really fancy user experience. If you wanted to rival the cutting edge of WPF development then I'd recommend Cocoa.