Monterey 4.0 Feature Preview: ROV Configuration File

Time permitting, I'm planning on posting little blog entries about each of Monterey's new major features.  Since Monterey 4.0 is still in progress, any of these features may change before the final release.

ROV Configuration File
A problem with Monterey 3.0 and earlier is that in order to customize the ROV configuration, you had to re-compile Monterey from source.  Well, that is a ridiculous requirement for such a common operation.  With Monterey 4.0 and on you will be able to use a JSON file to configure your ROV.

rov.json configuration file

The configuration file is located in the same folder as Monterey, although default settings can be loaded if the config file cannot be found.  Because it is a simple JSON file, it is easy for humans to read and edit it, so there is no configuration application.

Relays
With the relay JSON objects, you can specify a name that will be used in the UI.

Servos
With the servo JSON objects, you can specify a name, minimum value, maximum value, and a default (starting) value.

Sensors
With the sensor JSON objects, you can specify the name of the sensor and the units.

Motor layout
This is where you specify if your ROV is a vector or a tank ROV.

Max depth
This is where you specify the max depth of your ROV.  The units for this measurement are the same units for your depth sensor.

The UI is automatically configured to display the right amount of buttons, sliders and sensor displays based on your config file.  Also, the received UDP packet format is based on your config file.  The order that Monterey expects the sensor values to be in is specified in the order of the sensor JSON objects (in this case, Monterey would expect to get depth, voltage, current and heading in that order).  Monterey automatically adds any needed values to the sent packet (motors, relays and then servos, in that order).

Certain UI elements, like the depth and heading tickers, are only updated from their respective sensors.  The look for sensors labeled depth and heading, respectively.  If you don't have those sensors in your ROV config file, the UI will still display the widgets but they won't update with useful information.

Thanks for stopping by!

Chris

First update in a LONG time (Spoiler: ROV-Suite updates)

Hey!  It's been a LONG time since my last post (too long for my taste), but I've been pretty busy.  I finished up my freshman year of college well.  I had a great time!  I've also learned a lot about programming and CS in general since the last time I worked on one of my projects so the quality of my work should be increasing.

For this summer, I'm interning at a large software development company in NYC.  I just moved in recently but I've been having a great time so far!  It's very cool to live in a big city and the company's work seems really interesting.

I've also been planning improvements, features and bug fixes for Monterey for months now.  I didn't have time while in school (and I barely have time now that I'm working from 9-5), but I'm trying to get some updates for Monterey pushed out as soon as possible.  The biggest change that I'm currently working on is allowing people to configure their ROV from a simple JSON file and having Monterey's UI and networking code take care of the rest.  See here for more information.

Another big improvement for Monterey that I have planned for this summer is unit testing.  Yes, one of my big goals is get Monterey set up with a unit testing framework.  More on that later!

Thanks,

Chris

Monterey v3.0 Video Streaming Fix

When I updated the Windows release for Monterey recently I forgot to add the image format plugins required by the web browser to see the video feed from the Raspberry Pi.  I have since updated the release on Github which you can grab here.  I apologize for the error!  Monterey would start up just fine without the plugins but it would display a question mark instead of an image on any web page shown (i.e. the RPi video feed webpage).

Monterey 3.0.0 - Windows Executable Released!

Hey!  It's been a while since I last wrote an article.  I've been kept pretty busy with school work (2 CS classes, a math class, physics and a job on the side).  Anyway, I received some incredibly nice emails and PMs the past few days from some users from the Homebuilt ROV Forums thanking me for working on Monterey and releasing it for free.  They had some feedback for making Monterey easier to use, and I've taken their feedback to heart.  The most pressing issue was that there wasn't a compiled version of Monterey for Windows for new users to download (Windows is by far the largest target audience according to my Sourceforge download stats).  It has been months since I last looked into fixing the deployment issue that Monterey faced with the switch from Qt 4.X to Qt 5.1.  I sat down tonight after finishing up some math homework and tried getting Monterey to work with the help of QuantumCD.  Here's what happened.

(Quick note: Since I did not have access to another Windows machine, I would rename my QTDIR so that any applications trying to reference it would not be able to find it.)

I tried getting some Hello World Qt apps to "deploy on another Windows machine."  I got that working and QuantumCD verified that it worked on his system, too.  Then, I tried Monterey.  Monterey ran just fine before I renamed my QTDIR.  However after renaming it, Monterey would fail to launch and even fail to display any warning or crash dialogs. That meant that Montery was trying to load up something from my QTDIR.  So I went through and copied mingw48_32/bin into Monterey's directory.  Then changed my QTDIR... and crash.  So that's obviously not all that I have to do.  I kept experimenting, but this time, instead of changing my QTDIR's name, I would rename subfolders in it until Monterey would crash, signifying that Monterey needed something in that directory.

After about 10 minutes of this, I figured out the one folder that Monterey needed that I had never copied over to Monterey's directory before (and NO online tutorials or forum posts said to copy this over). I figured out that QTDIR/mingw48_32/qml/QtQuick.2 was needed for Monterey to run.  After copying that directory into Monterey's directory, I figured out that qtquick2plugin.dll and qmldir were both required. Bam, deployment problem solved!

RootDir
-platforms
    -qwindows.dll
    -qminimal.dll
-QtQuick.2
    -qmldir
    -qtquick2plugin.dll
-icudt51.dll
-icuin51.dll
-icuuc51.dll
-libgcc_s_dw2-1.dll
-libstdc++-6.dll
-libwinpthread-1.dll
-Monterey.exe
-Qt5Core.dll
-Qt5Gui.dll
-Qt5Network.dll
-Qt5OpenGL.dll
-Qt5PrintSupport.dll
-Qt5Qml.dll
-Qt5Quick.dll
-Qt5Sensors.dll
-Qt5Sql.dll
-Qt5V8.dll
-Qt5WebKit.dll
-Qt5WebKitWidgets.dll
-Qt5Widgets.dll
-SDL.dll
-sdl-config

I'm happy to have finally fixed that issue!  Now I feel as though work on Monterey can continue this summer.  I won't promise anything before then because I'm kept pretty busy here.  I'm hoping to score a software development internship for this summer, which would be incredibly fun and educational.  The UC system is looking at having us start even later than we already do, which means that I'd have almost a month after my internship to work on Monterey.

When I do work on Monterey this summer I want to focus first on making it more polished, and then adding features.  I want to make it easier to customize (probably using config files) and QuantumCD and I have been talking about making it themeable.  Stay tuned for more information!

You can grab Monterey 3.0.0 here.

Thanks for stopping by!

Chris Konstad

BruinLyfe 1.2.0 - Tutorial added, better screen support

BruinLyfe 1.2.0 has been pushed out to Google Play today.  It brings better support for 7in+ screens and it also brings a first-run tutorial.  There have been plenty of changes over the past 12 hours!  Other updates include improved algorithms for detecting which dining halls are currently open, optimizing JSON parsing code and removing depreciated API calls.

Thanks for stopping by and don't forget to download BruinLyfe here!

You can check out the source code here.

Chris Konstad

Recent Developments: College Life and Bruin Lyfe

I haven't really had time to post recently because of college.  I moved in and I have been kept busy with my classes.  After getting here, I found out that someone developed an iOS app called Bruin Life, which had dining hall menus among other information.  Sadly, he never ported it to Android, so a floormate and I decided to fix the situation ourselves.  Over the past few weeks, he and I been developing our own app and it's coming along great!  You can see in the screenshots above that it lists all of the dining hall hours.  When the  user clicks on a time (i.e. De Neve lunch), it opens up another activity that lists the menu for that time period.  More updates will be coming, so stay tuned!

Get it on Google Play!

Thanks for stopping by!

Chris Konstad

The Future of Mobile Development

A few weeks ago, I had the privilege to attend the Qt Insights meeting in Palo Alto, CA.  I met with some other Qt developers and we discussed the findings of the Qt Insights project.  For the first time, a clear picture of the Qt community is coming together.  Through Qt Insights' report, we can see who is using Qt and which industries it's being used in.  The report shows that Qt is gaining new developers and that, overall, people are happy with Qt.  While at the Qt Insights meeting, the question of Qt's ability to target multiple mobile OSes came up.  One tangent that we didn't have the time to fully discuss was: how can Qt apps fit into their target platform (UX-wise) if they are written once and deployed everywhere?  To help answer that question, I wrote the following blog post.

The Future of Mobile Development

What I see as the future of mobile development is a unified native API that spans across OSes and systems from various manufacturers.  Want to write an app?  Great!  Learn one language with one API and you can deploy your app to Android, iOS, Windows Phone, BlackBerry, Ubuntu Touch, Sailfish, etc.  The problem is, how do we get there from here?  It is no easy task to create such a language or such an API.  Thankfully, the language already exists, and it is well known.  Have you heard of C++?  Yeah, that language that works across all of those platforms (and many more!) already?  Well, C++ is already gaining popularity after the whole "managed languages rule!" trend of the past decade.  "But Chris," you might ask, "what about the unified API?"  Well, that's coming from everybody's favorite C++ framework: Qt.

The Current Status of Cross Platform Mobile Development

People are already partially working in that cross platform development utopia in which one language and one API let you deploy to every mobile OS.  Many games and other apps have a C++ back-end wrapped in the platform's SDK language (Java for Android, Obj-C for iOS, etc.).  That wrapper creates the UI and let's the C++ core access other platform APIs.  The only problem is that the developer MUST learn the SDK languages and APIs for each platform they want to deploy to.  While that may be alright for big time developers, for hobbyists and self-taught programmers that can be a major roadblock in deploying apps across multiple OSes.  We need a single API that we can use across all systems; a cross-platform language isn't enough by itself.

Problems with the Future

Each mobile OS has a very different UX that must be catered to by the developers because of user demand.  Android users absolutely hate it when the Android app uses the UI of the iOS version of an application.  It makes the Android version feel cheap and like an afterthought.  The mismatched theme devalues the application and it tells the users that the company doesn't care enough about them to rewrite the UI for Android.  There can be other issues, too.  For example, in iOS, application settings are often handled in the system preferences app.  However, on Android, each application usually has it's own settings fragment within the application.  What I'm getting at here is that even with the future of mobile development (one language, one API), developers cannot simply write an app once and deploy it across every OS available because the UX wouldn't be native for each platform, even if the on-screen UI elements are.

How to Remedy the Problems

The solution to the problem is quite simple, really.  Write a new UI for each target platform!  I mean, developers already do that when they have the C++ core and SDK language/API wrapper, right?  Only with a cross platform language and API, the developer can reuse more UI code, simplifying the process while retaining a native-feeling UX.  Think about it.  Even though the developer would have to tweak the UI/UX for each target platform, they could do so using the same set of tools and knowledge!  On Android, this would mean the developer wouldn't have to know about the JNI or Java to make a native feeling Android application.  On iOS, this would mean that the developer wouldn't have to know about Obj-C.  All the developer would have to do is move around a few UI elements and select the target's theme.


TLDR: Qt 5.2, which introduces iOS support, marks the beginning of a decent cross-platform develop suite for mobile apps.  Yes, the UI/UX will have to be tweaked for each target, but it can be done using one set of tools and the same knowledge.

Thanks for stopping by!

Chris Konstad