I'm currently working on a Qt-GUI with which I plan to remote control a robot. The robot is ros-controlled and equipped with multiple cameras. The topic is completely new to me and I just started learning both Qt and ROS and have some basic questions. I didn't make any progress googling around so I finally decided to post it here:
How can I connect data from ROS with Qt? So let's say I kind of want to live-stream the recordings of the cameras into my GUI. How is the general procedure there?
I've seen this ROS Qt Creator Plug-in. Is that something I want to use for this project?
Thanks a lot to everyone answering.
This is my first post here so I hope I didn't mess anything up or flouted forum regulations.
Edit 1: I am working with C++.
Edit 2: In case it helps you giving me advice; the rostopic type of the camera topic is sensor_msgs/Image.
For question 1, since the images are coming over the sensor_msgs/Image topic, using ROS with OpenCV's cv_bridge in the Qt application to receive the the incoming image stream from ROS into the Qt-GUI is a good start. There are several tutorials that cover integrating OpenCV into a Qt project. An important advice is to keep track of the image properties (size, color format, etc.), which will help in displaying the image properly in the GUI. Disclaimer: I have worked with Qt libraries on the Python side, not with C++.
As for question 2, the information for setting up, building, and running the code within the Qt-Creator can be very convenient. There are times where it is prudent to use an IDE to build, run, and debug code (to deal with memory management, segmentation faults, etc.), while other for other times running "catkin_make" or "catkin build" in the root directory when the hardware is minimal.
I've just discovered TideSDK and it seems to be a really great tool, but I have one requirement : I need to use some native code (for managing USB devices for example) and so I need communication between this native code and the web app, is such a thing possible with TideSDK?
Yes, working with native code in TideSDK is possible. Our SDK is modular and we have been reorganizing the code structurally to make it easier to do the sort of thing you want. At a modular level, you will be contending with support for multiple platforms typically.
A module should extend to all platforms that you are supporting. We expect to have documentation to help developers (familiar with native code) to better understand the SDK. This should include some module boilerplate to help you get started. At this point, we have yet to prepare this more detailed documentation. We have much to do and sometimes progress seems slow despite all the great efforts going into TideSDK.
TideSDK is a large and complex SDK but don't let this frighten you off. It is extensible and we will be shining light on this soon with module development guides. It would be cool to talk more on IRC about this with you so feel free to drop by at any time. Perhaps the functionality you are speaking of is of general use ie. to extend the APIs for everyone.
There are possibilities to work together with the core developers of TideSDK on modules and to contribute to this great open source project. Other possibilities also include sponsoring module development if this something that you need more immediately for a project. Hope this helps.
We've developed a commercial Qt application with Qt under LGPL. We link dynamically. We also made a few changes to a couple of files in Qt to better suit our needs. I realize that according to LGPL, I must make those changes publicly available.
My question is how is that done?
Do I set a webpage on my domain with the modified source codes available for download?
Do I distribute the modified source code in a folder on the client target machine after installation?
Another
way?
You simply have to make them available on request.
It can be a file on your web server, it could just be emailing them to anyone that asks, you can even supply them on floppy disk and make a charge for it.
Ideally you would also contribute the changes back to Qt if it's a bug fix or feature that could be useful to other people, then it may be incorporated in future editions and youcould then just use the standard build.
ps. The letter of the GPL says that you have to provide everything that is needed to create your modified build - so the full Qt sources and the build files. However for a large complex project like Qt, if you have only modified a couple of files it would be useful to offer a download of just these (or even a diff against the specific Qt version)
According to the licence you need to provide your changes back to the community, not just to your customer.
The easiest way is forking the main Qt repository on http://qt.gitorious.org/qt and commit your changes there.
Recently I've had to work with big, existing projects to get them to compile. So far, it's been a pain in the butt to download all of the necessary libraries and configure the environment correctly.
If I had a checklist that I could hand to project leads, listing: "here's what I need to run your project," that'd save me time and effort.
Does anyone have any checklists, advice or readings on how to simplify compilation of big projects?
thanks
Use build scripts. Compiling a large project shouldn't be any more difficult than compiling a small project. A single command should be all that is required.
without knowing what language you're targeting, I can't be more specific.
almost all nix source distributions come with a README file which should list the dependencies.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As recently as several years ago, the developers actually made the builds that went to clients. This was obviously a disaster for reasons too numerous to list.
Then when we started to learn the errors of our ways, we looked for a way to auto-build the entire application on a dedicated build machine. The culture at that time was very averse to bringing in outside tools, so we built our own autobuild system by writing a VB app.
This worked fine for a while, until the project's structure started to change, new projects were added, and we needed to build the application in different ways. Then then weaknesses of our hand-rolled autobuilder became apparent and, over time, increasingly onerous. This disease has progressed now to the point where QA (who owns our build process) can't even maintain the autobuilder because it requires more and more programming skill. Every time we add a project or change something in an existing project, it consumes more developer time just to make it work. There have been days when we were unable to produce a build because the system was broken.
I'm now in a position where I can change this process, and I'm looking to scrap the entire system and put something else in it's place. My goals are:
Have an autobuild system that can run with zero human interaction at a specific time every day. It should be able to gather all the source code, compile all the apps, create the setups, put the finished products on a network share, and possibly trigger the automated testing system to kick in (we use QTP).
The autobuild system should be flexible enough to easily adapt to changes in the project without rrequiring a major overhaul.
It should be simple enough so that QA can own the system and not require developer resources to make changes to how builds are made.
What are your experiences? Can you recommend an autobuild system? Should I have different goals?
I'm currently using CruiseControl integrated with Ant to control project builds. This allows flexibility of build schedules and means you can automate the entire build process fairly easily using Ant scripts. Also, during defect fixing periods you can have CruiseControl set up to watch for source control submissions instead of time periods and build when these occur. This allows developers very quick feedback on defect fixes.
I use FinalBuilder and FinalBuilder Server for nightly builds. It's a bit buggy at times, but if you think it through it's quite easy to create extensible projects that can build X project type, build it's database from change scripts and deploy it to a testing server.
It can also handle all kinds of wierd and wonderful things like ZIPing a nightly build and uploading it to an FTP or creating ISO images automatically.
Definitely look into MSBuild if you're on the Microsoft stack.
Joel is always going on and on about how great FinalBuilder is, so that might be worth a look as well.
We just migrated from a hand-rolled set of Perl scripts to a Buildbot setup. I found it because that's what Google's using for Chrome.
You can do nightlies, or it can integrate with source control to do an isolated test build whenever anybody does a checkin, or a variety of other things. It's also parallel; you can have more than one machine in the build farm, either for specialized duties or just to handle more load.
The entire system is written in Python, so it's platform-agnostic, which is important if you need to do builds on more than one platform. It can do anything you can do from the command line; we have it calling MSBuild for user-mode components, a DDK build for kernel-mode pieces, and running products for unit test builds.
Out of the box it supports most OSS source control tools, but if you're using TFS or something else you may need to modify the package that you install on the slave machines.
I think you are on the right track here.
Whoever looks after your automated build process needs to have a fundamental understanding of how your solution fits together. This doesn't necessarily mean knowing how to write code or architect solutions, but they will require a solid understanding of how the solution compiles, packages itself etc.
You might need to share responsibility for builds between people or teams to accomplish this. I'd say that a daily build is a "team responsibility".
I'd look at establishing a baseline build configuration which can be extended for "special use" builds (besides just building a release version), e.g. internationalized releases, fxCop/Quality Tools config, build + run Unit Tests, continuous integration builds, a build config to run on developer workstations, etc.
Instead, I'd aim to achieve the following:
Automatic versioning, signing etc
Ability to produce verbose output (logging) to help debug build breaks
On that point - it should handle errors properly, capture as much information and log it properly
Consistency - It should work the same way each time to produce repeatable outcomes
Run in a clean, limited access environment
Well commented/documented so that it can be understood by new staff, etc.
Option to generate release notes, compile metrics, produce reports (if this option is available)
Ability to deploy to multiple environments
Support different ways to obtain source code from source control, e.g. by changeset, label, date, etc
As for tool recommendations, I've used FinalBuilder, Visual Build Pro, MSBuild/Team Build, nAnt, CruiseControl and CIFactory plus and good old fashioned batch files.
Each has its pros and cons, I'm not going to make a recommendation except to say that the products with decent UI support were a little bit easier to work with, but at times were far less powerful. If you're working with VIsual Studio, MSBuild is very powerful, but has a somewhat steep learning curve.
As of tools delivered with MS Visual Studio you might want to use MSBuild. Additional Community toolsets for MSBuild will even give you the possibility to checkout code from Subversion and zip output.
We're using it successfully in our company. Projects consists of several solutions with 100+ subprojects. Works like a charm.
Visual Build Pro is nice, if your build machines are Windows. I think this would fill the requirement you have about QA owning the system. But don't get me wrong, it's pretty powerful.
We use CruiseControl.NET and UppercuT (which uses NAnt) to do this. UppercuT uses conventions for building so it makes it really easy for someone to get started by answering three questions (What is the solution named? What is the path to source control? What is your company's name?) and you are building.
http://code.google.com/p/uppercut/
Some good explanations here: UppercuT
We use the Hudson buildbot for for big Java web app building from ant build scripts. Hudson is pretty sweet for our purposes. It has a master/slave setup so builds can be done concurrently (on a timer or on-demand). Slave nodes can be any OS/hardware combo provided it has the needed build tools already on it and is on the network (and won't crash every 10 min).
Full web-based interface including live console output, change logs, artifacts from the build are available across the network including previous builds (if successful). Awesomesauce!