 |
| An early, ugly and pre-alpha build of Monterey v3.0. |
- Remote flashing of ROV software using a Raspberry Pi
- IP video via Raspberry Pi
- HUD
- PID algorithm for position holding
- Exponentially weighted moving averages for smoothing sensor data
- Vertical speed indicator
- Tailored for OpenROV electronics and hardware (with the exception of replacing the BeagleBone with a Raspberry Pi)
- An awesome theme borrowing heavily from Eric's mockup
I've already done some work the past two days on Monterey, bringing much needed improvements to the package. I've learned more about proper software architecture and UI/UX design since I last worked on Monterey, and I hope it'll show in my new work. While adding features to Monterey, I'll also be refactoring the older code to made it cleaner and easier to work on. Also, Monterey 3.0 will link with the Qt5 libraries and use QQuick2 for some of the widgets (see the depth-tape for an example).
Features/bugs already worked on:
- DiveTimer has been moved to it's own class and now automatically starts and pauses when the ROV enters and leaves the water.
- Monterey now has a fullscreen mode!
- The UI is now scalable, meaning Monterey now works on netbooks with 1024x600 displays through laptops with 1080p monitors. This feature was long needed, and I'm glad I've gotten good enough at layouts to add this functionality.
Thanks for stopping by!
Chris Konstad
Very cool! I'm not very knowledgeable in robotics, but perhaps I can help with some finer parts of your UI? I'll take a look at the source and maybe pull it down to work on it a bit. I haven't been working much with Qt lately, so it'll be great to finally get back to it!
ReplyDeleteAnything specific you are looking to add/improve that I could maybe help with? I don't know if I'd want to try refactoring your code that you wrote, especially since I haven't even took a look at it. :P
Hint: Qt Creator 2.8 has new refactoring support which is amazing! Implementing super class members (perhaps I will finally start using interfaces. :P) and a host of other things, namely that you can basically auto-generate getters/setters now, along with methods/members required for Q_PROPERTY's (although in Qt 5 you can bind these to a member and the MOC takes care of the rest, I think).
Thanks! I'd really appreciate the help!
DeleteI'm looking at adding a compass readout to the HUD, in a similar scrolling style to the depth tape, that stretches along the top of it. And just so you know, I'm completely self-taught so my architecture might be a little messy. I could also use help with the DepthTape::setMaxDepth(double) function. If you wanted to take a look at that, that'd be great. It should make the maximum depth of the depth tape whatever the argument is, without having to restart Monterey.
Awesome! I'll have to take a look at it. I just downloaded it the other day because I've been wanting those multiple editor windows for my multi-monitor setup for awhile. Qt Creator 2.8 looks fantastic!
Hmm... I took a look at it, but it's a bit hard to figure out what's going on. Maybe it's because I have no idea what the Depth Tape's purpose is :P Honestly, I'm not familiar with robotics anywhere near the level you appear to have. If I'm doing any commits, it's probably going to be an attempt to improve some existing code that doesn't break whatever you are trying to do!
DeleteAbout the architecture worry--don't be. You should see the mess my local solutions are.... or rather, it might bring pain to anyone who has OCD for really good software architecture. I've been doing a lot of game programming lately in C# and Unity, which has really ruined my organization. In Unity, there isn't really namespaces, you are stuck with .NET 2.0 (subset) and regular software development patterns don't really apply in my experience.
In fact, outside my blog, I really haven't been using Qt and C++ as much as I'd like. In Qt specifically, I am all self-taught, but I did take some online courses on software engineering and OOP concepts with C++. Most programs I have worked on lately are .NET (and some C++ non-managed code in DLL's for some math and stuff) since the UI's are done in WPF and recently, XAML. I really hate the whole XML thing, but luckily there's Blend (which is surprisingly like the QML designer... or perhaps vice versa).
Anyway, when I find some time to pull your project down and build it. Hopefully it'll build, since most Qt projects I pull never build right for me (probably my shoddy development environment). Perhaps I could maybe try my hand at a state machine for your main UI form. Maximizing viewing area for, say, the video feed could be beneficial. Plus, I really want an excuse to try out the QML-like animation classes in a QWidget environment.
Also, nice setup ;) I really need a new keyboard... and three monitors would be nice. I just don't know if three of these 24" monitors would fit on my desk. :P Perhaps I'll wait until those shiny 1440p monitors drop in price. Hopefully the 4K UHD craze will drive prices down from the 1K USD price tags they have currently. I tried out coding on an 1600p monitor once... very, very awesome. You can split like 4 80-character views in Qt Creator. Even better than multiple monitors in my opinion.
Haha. It's supposed to be a tick marker that displays the current depth by sliding up and down (kind of like this: http://www.air.flyingway.com/airlogo/adf/airspeed-tape.gif). Anything helps! I'm the only one working on Monterey at the moment, so really any help that you can offer is greatly appreciated!
DeleteOh okay. Thanks. I'm trying to do MVC, but I've never done MVC before, so I don't know if I'm doing it correctly. I am trying to follow the Unix Philosophies, too.
Sounds good! When you do that, make sure you install the SDL library (libsdl.org). You'll need to make sure the include files are in the proper location and that the DLL is in the right spot. Also, the latest version of Monterey depends on Qt5.1, not Qt4.X. Assuming those two dependencies are satisfied, it should compile just fine!
Thanks! I recently built it, and so far I love it! 3 24" monitors would need one heck of a large desk... XD Dang. That resolution would be fantastic for programming! Yeah, I bet a 1600p monitor would be fantastic for programming! Have you seen those 8K TVs? Now THAT would make a nice monitor...
Okay, perhaps I'll look into the depth tape more now that I know what it does! :P I haven't really used MVC that much, honestly. A while back, I did have an SQLite database managing contact information for a program, and I didn't use a model. Rather, I just queried the contact info and initialized a new form with the appropriate info and pushed it onto a stack widget. Worked well and was pretty scaleable.
DeleteI think I already have SDL around somewhere. Is there a specific version I should look into downloading (I think I saw a DLL in your Git repository). I have the 5.1 RC as well, but I may as well download the release.
8K would almost be too much for a monitor. I think the smallest they come in is like 80 inches. :P It'd be pretty amazing for a monitor... just not on the wallet. :P
Hmm, I downloaded Monterey's source, but I'm getting some issues with the "INFINITY" define. Any suggestions? I can't seem to find where the define is coming from.
DeleteThat'd be great if you could do that! Thanks! That sounds like a pretty good way of doing that. I haven't tried working with stacking widgets much.
DeleteI just used the current version of SDL (1.2.15).
Haha. 80 inches wouldn't be too bad if you sat far enough back... XD Too bad they're so expensive!
I think that is defined in the QNeedleIndicator class, which has been taken out of the latest commit to the HUD branch. Are you trying to build using the HUD branch or off of master? The HUD branch has all of the latest improvements (master is behind by many commits).
I should have the HUD branch, as I used Source Tree and pulled down the latest HUD a few hours ago. I'm getting the undeclared identifiers in the QScale class definition. The only other error I get is a peculiar include error regarding the QVectorDrive2.h file in QROVController.h. The .pro file seems to have the references and stuff setup... hmm.
DeleteAre you on commit 24c7eb7e0334b5d8a02767af1eb1af261ecb3561? I have completely deleted all references to QScale by that commit. QScale shouldn't even exist in that commit (there should be no files with it, no references, etc). Did you build in the same directory as an older version? That may cause that issue. Is it the "control reaches end of a non-void function" warning? I'm going to fix that one right now.
DeleteOkay, I fixed the include files. Turned out it was just where they were in the project, so adding a few '..'s helped immensely ;) Unfortunately, something seems to be bugged and I keep getting a linking error with the SDL library. Odd.
DeleteWhat development environment are you using to build Monterey right now? I am using Visual C++ 2012 64 bit with OpenGL Qt 5.1 and the MSVC 2012 compiler (latest version).
Really odd... even if I build SDL over again with Visual Studio, it still gives me linking errors.
DeleteOhhh.... I'm using MINGW32 with Qt Creator. I wonder if the compiler difference is the issue? I don't have as much experience with Qt on Windows as I do with it on other systems. What's the linker error? Is it a directory change? I know I had to manually copy the include files from the SDL library to QTDIR/mingw48_32/include/SDL (for example). I also copied over the lib and bin folders. Are you getting the "SDL/SDL.h not found" in QJoysick error?
DeleteI need to see if there is a more portable way of referencing DLLs. Like I said, I'm pretty inexperienced in the Windows side of this. I would do it all in Linux if I could, but most of the ROV-Suite userbase is using Windows.
DeleteHmm. I mostly use Visual Studio 2012 64 bit as of late, and linking is an absolute nightmare unless I am the one writing the DLL's. Also, I don't want to do this since I've probably tampered a bit too much with my copy of the HUD branch, but if the SDL is GPL or some variant license, you should consider putting all the necessary headers in the Git repository under a sub-directory, then use relative header file locations (i.e. something more like: ../../SDL/SDL.h). I did that and the include file errors went away.
DeleteAlso, I don't think it's the way you are linking the DLL, it's just a really odd error. First of all, I tried several different ways of including the SDL library, not just your LIBS += -lSDL.dll But all of them gave me *different* linking errors, but they all were wanting to reference "SDL.dll.lib" no matter what. Really odd.
I might hop on Linux if I have time later to see about building it on there, but I don't know. Dynamic dependencies are a major pitfall of open-source projects, huh? :P I have never been able to build anything that requires something like SDL, save some other things like OpenGL, etc. I'm thinking of setting up a secondary build environment on my laptop just for all these open-source projects that seem to use something besides what I use honestly :P
I suppose I could always try and branch out and leave behind all the files that require SDL (I'm assuming you are using it for cameras, joysticks, controllers, etc. for the robots), and possibly work on features not pertaining to those.
When in doubt, I could just make some blind commits :P
Hmmmm... SDL is released under the LGPL (at least the current version of SDL is). I'll change how I link to that to make it easier for others to join in on the fun. Thanks for the suggestion!
DeleteThat is odd. I've never had that issue on a Windows system... Did the brackets around the if statements in the *.pro get changed or something?
Haha. Yeah. But at least on Linux, it is really easy to link to. sudo apt-get install libsdl-dev and then in the *.pro file just add "LIBS += -lSDL" and you're done. No more errors!
I'll work on fixing that SDL issue, but it might take me the weekend as I have some plans that will keep me busy over the next few days. I'll get on it as soon as I can! Or if you have already fixed that issue, maybe do a pull-request on GitHub?
And I'm using SDL only for the joystick code.
I sent a pull request with the updated files. I spent 5 minutes trying to push a new branch to your repo, before realizing I hadn't forked first. :P
DeleteThanks for the pull request! I just merged it and added a small change to fix a linking error to the SDL error with mingw. Now, devs should be able to just download the repo and compile Monterey on Windows without needing to copy any files anywhere. Thanks for the help, Contingency!
DeleteNo problem. I'm going to try MinGW and see if I can compile. I still get the linking errors with MSVC 2012 64 bit.
DeleteYay! It links correctly with MinGW 32 bit! Thank goodness. Right off the bat, I notice one interesting issue. You can resize the window, but a) you get some errors regarding geometry that I haven't looked into and b) the maximize button is disabled.
DeleteAlso, the menu bar at the top doesn't like me... odd.
Oh, and there's one problem with me working on this project. I don't have a ROV or anything related lying around, so I might not be able to help with much besides the GUI and maybe some errors not pertaining to the robotics so much. :/
I'll do a bit of work on the UI and various things and submit another pull request soon if everything goes alright.
DeleteOh, and if you need it, I could probably compile SDL and release it for MSVC 32 and 64 bit, 2010 and 2012. I don't have anything older/newer though. I already compiled a debug SDL build with MSVC 2012 64 bit, but I couldn't get it to link, so no word on whether it works or not.
I might try linking it in Visual Studio instead of qmake and see if I have better luck, but for now I'm going to scan your code and add notes :P Nice style, by the way. It closely matches mine so we shouldn't have any issues there, hopefully.
Good! I'm glad to hear that MinGW32 worked well for you! Thanks for working on the UI scaling. I'm relatively new to making non-fixed size applications. I'm not entirely sure why the maximize button is disabled. I read online somewhere that Qt "decides" whether or not to enable the maximize button, but I'll look into it some more. It would be nice to make Monterey MSVC compatible, so if you want to compile SDL with MSVC and bundle it with the source code, that would awesome! And thanks for the notes! I'll take a closer look at them soon.
DeleteAs a side note, do you know of a good way to host Monterey binary downloads? I want people to be able to download executables.
It took me awhile to figure out, but be sure to make your tags on Github ;) Basically, tags are "releases" with Github, and when you create them on there, you are easily able to add binaries and other files to go along with them (i.e. release builds). If you go to the releases page on my newest repository on Github--my Run As Admin utility I made for a friend--you can find an example of bundling binaries with a release.
DeleteAlso, I cannot compile any changes to Monterey :(. See the issue I opened in the issue tracker.
Oh! That's a nice way of handling it. I'll make sure to take advantage of that! Thanks for the pointers, I'll check out your example.
DeleteYou cannot compile them or they don't run? While I had the window geometry error, it never caused any runtime or compiletime issues for me. Are you on Qt 5.1 on Windows? I'm using Qt5.1 on Win7 (64bit) with MinGW32.
I figured out the menubar problem. Apparently it has something to do with setting widgets' parents to the MainWindow, which then block the upper left part of the menubar.... Odd, but fixed!
DeleteI just fixed the maximize button issue.
DeleteAlso, don't worry about not having an ROV! Most of the code that needs to be written revolves around the UX. All help is really appreciated (even bug reports)!
I appear to be on f9e38d596c04bf722b0efbcec01e72f55441994a in the HUD branch. Everything seems to be the latest according to Source Tree.
ReplyDelete