Update

Although I've been on break for school for the past week, I haven't been able to do any programming because I've been helping my dad and friend replace the roof of our RV.  It's been an intense project!  Today was the first day that I had free from working on it, and I've spent most of it programming.

For my robotics team, I spent today playing around with the WiringPi library on my Raspberry Pi.  We want to have access to it's GPIO so we can use it as an embedded microcontroller onboard our ROV.  The GPIO utility it has (for turning on inputs and outputs from Bash) is pretty awesome!  I'm looking forward to writing some interesting embedded Qt apps for this.

I also found out today that my Raspberry Pi has a habit of breaking off the corner of my SD cards (above the contacts on the corner with the write-lock).  Debugging that issue took up a fair amount of time, sadly.  If you have the same issue, just take a piece of paper and put it between the SD card and the SD card holder (but not between the SD card and the contacts).  That will apply just enough pressure to maintain contact.

I'm looking into writing a Git client for Android devices at some point (probably this summer).  I tried to do a proof of concept today using QProcess to launch the Git executable that came with TerminalIDE (there is a Qt Git library, libqgit2, but it won't even compile on my Kubuntu VM), but I kept running into issues.  Hopefully I'll be able to resolve them and start working on the app soon!

Thanks for stopping by and expect more Android apps soon,

Chris K

Edit:  I just made a Qt app (for Android) that can execute Git commands.... (right now just the installed version).  User must have TerminalIDE installed for this build to work, but I plan on changing that soon.  Happy New Year!

Thumb Hypoplasia Update

I've been doing a lot of work recently on updating my hypoplasia app, and the results are looking pretty good!  It can now calculate the center point of the circle that fits the arc, calculate an average radius and use that information to calculate the range of motion of the patient's thumb.  It uses averages of many calculated center points (each one calculated from 3 randomly selected data points) to find the center point of the circle.  Then, it averages the radii from each datapoint to the center point to find the average radius.  Once it draws the circle on the screen, it uses some trig to calculated the range of motion of the thumb (from straight up to the blue line).  I've written the app to ignore extraneous data points (i.e. points caused by QPushButton clicks being registered on the QGraphicsScene).  I also greatly improved performance of the QGraphicsView by removing all anti-aliasing and by changing when data points are recorded.  All in all, it is working out pretty well right now!  I just need to get it tested in the clinical environment.  I plan on putting it on Google Play sometime this Christmas break.

If you'd like to download the current version of it (0.3.1), you can get it here.

The GUI theme looks very different from previous versions because I used Necessitas Alpha 4.1 instead of Alpha 3.

Thanks for stopping by!

Chris Konstad

Thumb Hypoplasia App: V0.2.0

I updated my Thumb Hypoplasia app to version 0.2.0 today.  This update brings more optimizations (non-antialiased text, for example) other other tweaks to improve performance.  My goal is to take exactly 10 samples per second on a variety of hardware so that each data point specifies a known point in time.  Also, I added a display of the current trial's ID number next to the test information text.

You can find the source code here.

Thanks for stopping by!

Chris Konstad

Thumb Hypoplasia: First Test

I found out today that one of my friends has thumb hypoplasia (diagnosed with Type 1).  Since I had my tablet with a beta build of my thumb hypoplasia app, we decided to try it out and see how well it worked.

I am not a doctor or a medically trained professional.  I am a high school student who loves science and programming.  The following analysis of the data is my interpretation of the data. I have received permission from my friend ("the patient") to post this information here.

The patient told me that he has type 1 thumb hypoplasia in his right hand only.  To run this test, the patient held my Acer A500 (10.1" screen) in both hands in the landscape position.  The full application looks like this:

He swept each thumb, one at a time, across the screen in an arc that started with his thumb parallel to the edge of the screen.

My software recorded his thumb position roughly ten times a second.  The slow sample rate is due to the painting of the "data field" (the area with the grid).  Once I learn how to cache the background pixmap of a QGraphicsScene, then I can increase the performance of this app.  Once he was done with swiping his thumbs across the screen, I saved the data as a *.png and the test was over.

Once home, I started to analyze the data that I had just taken.  I printed it out to the proper size (with each grid box being one square centimeter) and began taking measurements.  

I printed out the data field image (life sized, I checked it with a pair of calipers) and used a pair of calipers and a compass to obtain my measurements.  You can see the calculations overlayed on the data above (Keep in mind that the bezel of the tablet moved the centers of the circles off of the data field.  By printing out the data field image on an 8.5" by 11" piece of paper, I had enough room to the sides to find the center of the circles using a compass.  The area calculations include the area off-screen).  The afflicted thumb (right hand) has 86% of the range of motion (ROM) of the non-afflicted thumb on the plane that we measured on.  

The patient told me during the test that he has a smaller abductor pollicis brevis, which would result in a weaker abduction of the thumb manifested in a smaller angle of abduction from the starting position (aligned with the side of the palm, parallel to the index finger).  The data gathered from this test shows that symptom.  In other words, my app works (so far)!  

My application gathers data at a relatively constant rate that varies by device (because of the screen painting time).  In the future, I hope to make each data point represent the same change in time no matter which device it is used on, but that's lower on my list of priorities at the moment.  What you can see here, though, is how hard the patient had to work to force his thumb to sweep across the screen.  The data points on both thumbs end (at the bottom of the arc) with a much closer grouping than they do at the middle of the arc.  Therefore, one can deduce that the patient was struggling harder at the end of the arc to try to push his thumb as far as it could go.  On the non-afflicted side, the close grouping at the end is only 8mm long.  On the afflicted side, however, it is 13mm long.  The tighter the grouping near the end, the harder the patient was trying to move his thumb.  The data shows us that the patient struggled harder to abduct his afflicted thumb than his non-afflicted thumb, which supports the conclusion of a smaller abductor pollicis brevis. 

The tighter grouping of the data points at the beginning of the arc (at the top) can be explained by a slow velocity as the thumb accelerates during its sweeping motion.  The generally tighter grouping of the afflicted side versus the non-afflicted side can probably be attributed to the fact that the patient did the first test with his afflicted side.  He wasn't familiar with the testing process, so he did not know how fast he could move his thumb.  More tests are needed to confirm these hypotheses.

All of my interpretations are based on a single test with only one trial, which means that the data could be inaccurate.  More testing is needed to see how effective this application will be, but these are definitely promising first results!   One of my goals for this application is to automate the data analysis process.  I also want to optimize how the data field is rendered so that each data point is taken at a known time interval.

Thanks for stopping by!

Chris Konstad

Thumb Hypoplasia App 2.0

This app will be used to measure a patient's thumb's range of motion on a 2D plane.  By comparing ROMs (range of motion) of before and after surgery, surgeons will be able to get a quantitative analysis of the effects of the surgery.  The first version of this app was designed to find the 3D volume of space that the thumb could move in, but that had some issues.  This new version is working pretty well so far!  Each square on the grid is 1 square centimeter (found by having the user input a diagonal length of the screen and using the resolution to calculate the pixel density).  Each red dot is a recorded touch point.

I've spent about 8 hours this weekend working on this app (so far), because I've decided to rewrite it from scratch.  The main interaction area is a QGraphicsView widget which has perfectly usable performance on my modest Acer A500.  Through this project, I've been learning a lot about graphics in Qt, which should hopefully let me write some cool custom widgets.

Well I'm going to get back to working on the app now.  I'll post a video demo of it to Youtube soon.

Thanks for stopping by!

Chris Konstad

Edit: Here's a YouTube video of the very basic functionality currently implemented in action:

Update: School and College

I've been pretty quiet on my blog lately because school work and college apps have taken up a huge part of my time this past month.  Luckily, I'll be done with college apps before winter break so I can work on some side projects soon.  When I'm not doing educational work (school work, college apps, etc.), I'm working on things for my robotics team and trying to help get a programming club at my school going.  

Our (Jesuit Robotic's) ROV is looking great so far this year.  We have some ideas that we have been tossing around for a year or so that we are finally getting around to implementing!  For example, we are going to have a Raspberry Pi onboard so that we can flash our Arduino firmwares without having to open up the cans (waterproof electronics containers).  

The programming club is coming along nicely.  Two other students and myself are leading the club by teaching the other members how to use Qt to target iOS and Android (sadly, most of our members haven't had any programming experience yet).  Our first project is an application that will act as an information center about all of the clubs on campus.  We are working with the web development club on campus to create a web-based application that will let club administrators update the information about their club to include upcoming events and other notes.  

Here is an awesome Qt Developer Days video demonstrating Qt 5 on various platforms (I can't wait for Qt 5 to come out in 2013!  I'm super excited about Qt Creator 2.6 as well.).

And if you're looking to make 2D games using Qt Quick that target mobile devices, check out V-Play.  I haven't used their service yet but it looks pretty interesting!

Finally, I'm starting to make some headway again on a thumb hypoplasia analyzing Android app.  I've been stuck for a while because of third party library linking (and using) issues, but now a friend of mine offered an alternative solution.  Instead of finding a 3D volume that the thumb can move in, I could instead find the area on different planes that the thumb can move in.  It's much easier to calculate area than it is volume!  I plan to get some work done on that tonight because I'd like to start testing out a beta version of it ASAP.

Thanks for stopping by,

Chris Konstad

UDP Packet Logger

Last weekend, I made a handy little command line utility called "unlog" (Udp Network LOGger).  You can find the source here.  Once installed (and added to the path), just type unlog, if you want a timestamp or not, the port and then the file.  Then, unlog sits on that port and writes all of the UDP packets it gets to the file of your choice.  This might be handy for debugging UDP based ROV control applications or really just anything related UDP.

Enjoy!

Chris

[Tutorial] Bash Script for Arduino Uploader

Following the recent tutorial I wrote about flashing an Arduino hex file remotely using a Raspberry Pi, I wrote a bash script to automate the process.  To use this function, just copy the highlighted code to your .bash_profile or .bashrc file in your home directory.  With this function, you can just type arduinoupload path/to/my/file.hex in the command line and it will take care of the rest (assuming that you are trying to flash an Arduino Duemilanove using the "pi" user on the Raspberry Pi at IP 192.168.2.16 AND that you have already setup an SSH public key between the two).  If you don't set up the SSH keys, you will be prompted to enter your password.  You can tweak the function to adjust it to your setup, or you can rewrite it to make it more flexible.  I chose to hardcode these values because my setup (IP, user, Arduino model) never changes.

This is just an interesting little bash script that somebody may be able to make use of.  If you want any explanations regarding the script, you can either ask me in the comments or use Google (I'm new to bash so it probably will be more helpful that I will be).

Thanks for stopping by!

Chris Konstad

[Tutorial]Upload Arduino Sketches Using RPi

I just figured out how to do something really cool: upload sketches compiled on my laptop to my Arduino over my local network by using my Raspberry Pi.

It's pretty simple, really, but the uses are endless.  The most immediate use for me is that I could have a RPi onboard my ROV and I could flash new Arduino software to my ROV without having to turn it off or open it up.  That alone would save my robotics team a lot of time!

Here's a quick little tutorial on how to do this.

Step 0: Install AVRDUDE on Your RPi
This step is very simple.  Connect your RPi to the interent and type sudo apt-get install avrdude.  That will install all of the necessary packages (assuming SSH is already installed and enabled).

Step 1: Write and Compile Your Code

Write your code as normal and compile it as normal using the Arduino IDE.  The only catch here is that you'll want to go into settings and turn on the verbose mode for compilation so that you can find the hex file that the avr-gcc makes.  It moves around each time, just FYI.  The highlighted line (also the second to last line) is the path to the hex file.

Step 2: Copy the Hex File onto the RPi

This step should be pretty simple for any SSH familiar users.  Just use the scp fileToCopy user@hostname:/fileToCopyTo command.  In the screenshot above, you can see that I copied over two different hex files.  Remember where you copied the hex file to!

Step 3: Burn the Hex File

First off, you'll need to SSH into your RPi.  Just type ssh user@hostname into your command line.  It'll ask you for user's password, so enter that.  If you need help SSHing, you can find some awesome tutorials for your OS by using Google.  Once you're in, you can burn the hex file using avrdude.  For my Arduino Duemilanove, I know that it is in /dev/ttyUSB0.  You can find out which USB port your Arduino is under by typing ls /dev/tty* before plugging in your Arduino and then again afterwards.  Compare the results to find out the name of your Arduino.  Keep in mind that it should always stay the same unless you plug in another Arduino.  Now for burning the software.  The command for the Arduino Duemilanove is avrdude -b 57600 -p m328p -c arduino -P /dev/ttyUSB0 -U flash:w:fileToBurn -v.  That "v" is there for verbose output.  Let's break down that command.

avrdude: the application being called
-b 57600: sets the baud rate to 57600, which is what the Arduino Duemilanove
-p m328p: sets the part number of the processor (the atmega328p in this case)
-c arduino: sets the programmer type to "arduino" (which should be used for ALL "normal" Arduino software flashing)
-P /dev/ttyUSB0: this sets the port
-U flash:w:fileToBurn: this tells avrdude to "perform a memory operation" that involves the writing of the specified file to the flash memory of the microprocessor
-v: verbose output

And that's all there is to it!

Enjoy!

Chris Konstad

Mobile App Making Club

My school has decided to create a mobile app (iOS, Android) club where students can learn how to write apps.  The teacher in charge of the club has been asking for my input and help recently.  He wants to make it so that people in the club can write an app for one OS and compile it for the other OS without rewriting it.  He talked about using Google's new "translator," although if I recall correctly, that can't touch the UI code.  That means the students will have to rewrite the UI wrapper for their converted backend code.  I'm thinking about suggesting that they use Qt with QML (Necessitas for Android and Qt4iOS for iOS support), although I'm worried because of the status of both projects.  I don't know if new programmers should learn with projects that are relatively new because of the problems those newer projects could impose (including a higher barrier to entry).

Is there a better way to write apps for both platforms (using "real" code, not blocks and not using HTML5)?

Please leave any suggestions in the comments!

Thanks!

Chris

School Started and Qt on iOS

Sorry I haven't done too much work on ROV-Suite recently.  I've been pretty busy with school starting, college applications, Robotics team planning (I'm now the team lead) and other programming projects.

This year at school, I'm taking 5 AP courses (Physics, Spanish 4, English, Government, Calculus BC) and so my schedule will be pretty packed.  I won't have too much time to work on as many side projects as I did last year.  Also, I'm the team lead for my Robotics team, which will be a large time commitment.  Finally, the essays involved in college applications and the applications themselves will be a large time-sink.  What I'm trying to say is: don't expect too many updates to ROV-Suite or my other projects this school year.

The good news is that I have successfully written a QML application for iOS (I ported it from my Android/OSX/Windows/Linux code with only slight modifications)!  I'm really excited that the "Qt4iOS" project was far enough along for me to be able to easily use it.  I used Xcode 4.4.1 (on OSX 10.8) and I used the LLVM GCC compiler toolchain.  It works great on my iPhone!  I'll be writing more iOS apps and games in the future (possibly with the help of one of my friends).

I'm going to write a nice tutorial (with screenshots) about developing for iOS with Qt + QML sometime soon.  Thankfully it's pretty easy to get it all setup and working!

Thanks for stopping by!

Chris K

Monterey 2.0.3 Beta Released

I have some good news and some bad news!  First off, I have finally released Monterey 2.0.3 Beta for Windows.  The bad news is that the OSX release is going to lag behind a bit.  I am currently developing on OSX 10.8 Mountain Lion, so I will need to look into testing on Lion and Snow Leopard machines.  One person already alerted me to the crash on OSX Leopard, so I think I was able to change the update alert before too many people downloaded the new version.

Thanks!

Chris

Update: Monterey 2.0.3 Beta

I've been busy for the past several days hunting down bugs in Monterey 2.0.3 before I can release the code.  They've been tricky to find (since they rely on nothing but poor timing and therefore happen randomly when certain conditions are present), but luckily they've been easy to fix.  I plan on releasing Monterey 2.0.3 Beta this week.  It's working great on OSX but I need to test it on Windows before I'll feel comfortable releasing it.  OSX seems better at handling empty QLists than Windows, so that's mainly what I'll be looking for.

Monterey 2.0.3 Beta mainly adds the ability to read joystick buttons and a joystick's POV hat.  From there, you can trigger relays and increment/decrement each servo.  I'll post more information about it when I release it.

Thanks for stopping by!

Chris Konstad

ROV-Suite, OSX 10.8, Headaches

Yay for smooth(er) circles and OSX 10.8!

I'm not going to go into too many details tonight because of the time, but there's some new code sitting in the repo still warm from my keyboard.  I've started adding the code that reads the joystick's hats and buttons.  It's kind of a pain simply because it's a fair amount of work and then I have to figure out to sync the inputs that Monterey gets from it's GUI and from the joystick (and Tahoe) and make them all spit out a single, correct value to the ROV.  So far, the joystick's first hat can change the servo values and enable or disable a relay while the joystick's buttons can only enable or disable relays.  I'm going to add their servo code within the next few days.  So far, these settings can only be changed in the settings.ini file, but I will break them out to a GUI.  Speaking of the GUI, look at the compass!  I have finally gotten around to touching up the outer ring around the compass!  I think it looks much better (albeit maybe not perfect).  Please be aware that this code, Monterey 2.0.3 Beta, is not in the downloads page yet and is not yet ready for public consumption.  I just put it in the public for those of you who always want the latest, most cutting edge code.

Speaking of the cutting edge, I finally upgraded my MacBook Pro from 10.6.8 to 10.8!  I can finally enjoy all of the features of Lion and Mountain Lion!  I never thought I'd like the fullscreen apps part, but I'm finding that I enjoy using the fullscreen apps (and the four-fingered swipe between them) much more than I ever loved Spaces.  My only complaints so far are that 1) Apple doesn't ship any version of Make with 10.8 (first install Xcode 4.4 and then install the command line tools in the downloads section of Xcode's preferences) and 2) most of my programming tools are yet to be upgraded to be fully compatible with Mountain Lion.  I tried to install Valgrind tonight, but I couldn't even build it because compilation would stop with a "Your version of OSX is not supported" message.  Luckily, even though Qt 4.8.1 spits out about 25 warning messages (all with the "your version of OSX is not supported" text), it stil compiles my applications.  Although I have seem to have run into an issue... When running the debug build of Monterey on OSX 10.8 I get many crashes during startup and seemingly arbitrarily afterwards.  Most are sigsegv and sigabrt messages, although most seem to be related to QList.  The weird part is, when I switch the the release build of the same source code, everything runs along perfectly fine.  My guess is that maybe there's a compatibility issue with the debug libraries of Qt 4.8.1 and OSX 10.8.... or perhaps I'm just a crappy programmer (a much more likely alternative, except for the fact that these issues only plague the debug build).  ;)  My advice is to hold off on Mountain Lion until your programming environment has fully been carried over.  If you don't wait, you might run into the headaches that I've been running into.  But, let me tell you, OSX 10.8 is one amazing OS and I have almost no regrets upgrading so early.  The rest of the user experience has been perfect!

Anyways, I'll be uploading the latest version of Monterey when I get it all worked out.  Hopefully these crashing issues with the debug build are related more to Mountain Lion and less to any errors I've created.

Thanks for stopping by!

Chris Konstad

Raspberry Pi

I'm pretty excited!  I finally got my Raspberry Pi in the mail today!  I played with one at a friend's house, and so I'm pretty excited to get started with this one!  I have a few interesting projects in mind....

• Turn my TV into a weather, news, information, etc display
• Raspberry Pi based ROV...

I will admit, I'm most excited about the second option.  It'll be interesting working with Nick to make some custom circuit boards that can expand on the Raspberry Pi's GPIO (and buffer it AND bring it up to 5v from 3.3V).  It'd be nice to be able to write both the topside and the bottomside in Qt as well.  As much as I love the Arduino, Qt's language is much nicer and the whole Qt environment is much easier to program in (once you've gotten used to a full-fledged IDE, that is).  One cool idea that I've had as far as Raspberry Pi based ROVs go is a debug GUI.  Think about it.  You can have your ROV and give it a composite video link in a easily accessed spot.  When you need to check on statuses of different systems of your ROV, check on it's configuration or change it's configuration, you can just fire up the GUI and change it from the ROV.  I personally think that'd be a pretty awesome feature.  I'm just going to have to learn more about Linux now than I ever have before...

In other news, I'm finally going to get around exposing the joystick buttons and hats in Monterey.  I want you to be able to map them to the different relays and to the servos.  Sometime while I'm doing that I want to continue trying to port Monterey over to Android.  I think it would be totally awesome to be able to drive your ROV from an Android tablet.  After I get that done, I need to talk to Nick about getting an IP camera set up so that I can start writing and testing a more pilot-oriented GUI with a nice overlay (or something like that).  

Thanks!

Chris Konstad

ROV-Suite: Bottomside 1.1.0 Released

Great news!  I just uploaded the first revision of ROV-Suite's bottomside code to the repo and to the downloads page.  This new version supports a depth sensor, a voltage sensor and a digital compass.  Please note that while the libraries have been used (my robotics team used those very libraries to get 3rd place in the MATE ROV competition) and tested, the entire setup has not been tested yet.  Since it is late here tonight, I'll do some bench top testing tomorrow.  

Here's the setup:

Compass (HMC6352) hooked up to the Arduino's A4 and A5 (I2C) pins.

Voltage sensor (Phidgets P1135) hooked up to the Arduino's A1 analog input pin

Depth sensor* (Phidgets P1115) hooked up to the Arduino's A2 analog input pin

Now the depth sensor's setup is a little tricky at first, but it is really robust in practice.  In fact, in our testing, we found that the library was accurate to within a centimeter!  Since the P1115 is really just an air pressure sensor, you must use the water to compress a volume of air that must then compress the pressure sensor.

The flexible diaphragm is pushed inwards (towards the P1115) as the water pressure increases.  That causes the volume of air inside the sealed container to decrease, and since the container is sealed, the pressure then increases.  From there, the P1115 reads the absolute air pressure inside the sealed container and converts that to a depth reading.  I will admit, this is not my design.  A mentor on the team, Jay Isaacs, came up with it.  The only downfall of this setup is the maximum depth of the pressure sensor (as it can only have 36 PSI atmospheric on it, only 21.3 PSI of water pressure can be applied before it exceeds it's maximum pressure rating).  According to some calculations with the help of Engineering Tool Box, it's maximum depth is 49.2 feet of water.

I hope to test out this code more fully soon so that I can catch any bugs it's hiding.

Thanks for stopping by!

Chris Konstad

Update

I have some great news regarding Monterey and Android!  With the help of Stack Overflow, I've gotten SDL to almost compile and work with a Qt application on Android.  Now I'm just missing the compiled library to link to (my compiling is spitting out undefined reference errors).  Once I can get that sorted out, you can expect a fully functional version of Monterey for Android!

Also, I've been spending some of my programming time recently working on an application for a med school student that I'm working with at a hospital near my house (I'm volunteering there).  I'm writing an application for him that will detect the coordinates of a touch on the screen of an Android (and hopefully soon, iOS) phone, log those coordinates for multiple tests on multiple planes of the hand and integrate all of the data to find out the volume of space that the patient's thumb can move in (this will help patients with congenital thumb hypoplasia).  My application is based on the proof of concept technique the med school student figured out using an iPhone drawing program and MATLAB.  Hopefully, my application will simplify the process and make it practical to use in a clinical environment.  What I'm getting at here is that development of Monterey will be slowed down a little bit for the time being due to other commitments, although this application will be completed before the end of summer (so then I will have more time to spend on ROV-Suite)!

Also, since I'm on summer vacation, I'm spending some time playing around with fun side projects that I've been meaning to get setup for quite a while now.  I finally installed Linux on my Core 2 Quad desktop that I built in the 8th grade, so it's a nice little Samba file server on my home network, now.  I've since set up SSH (something I've been wanting to play around with for awhile) and I hope to turn my desktop into a remote compiler and backup solution for my computer.  My goal is to set up cross compilation on it so that I can write my programs in OSX, and then automatically compile them for Linux and Windows (and even Android) after I push the update to my Git repo.  I find having to reboot my laptop just to compile a Windows build kind of annoying (especially when I have all of my reference windows open in Chrome), so this should be fun to try out!

On a final note, I've noticed that ROV-Suite has been getting some negative feedback on Sourceforge (people have been not recommending it).  Obviously, if you think that ROV-Suite deserves the negative feedback, then go ahead and give it a thumbs down.  But please, if you do so, comment on why.  I really enjoy working on ROV-Suite and I want to make it the best suite of applications possible, but I can only do so if I am told what is wrong with it.  If you find any bugs, please make a ticket!  I will get back to those tickets as soon as I can!

Thanks for stopping by!

Chris K

Minor Setbacks

I have some semi-bad news (luckily it's not too bad)!  First off, I downloaded an IP camera app for my iPhone, and while trying to get it to work with Qt, I realized something: I don't know how to get the data from the IP camera chips that Nick and I are planning to include on the official ROV-Suite PCB!  I'll need to find out how the data is sent from the chips (jpg, mjpg, etc) before I can continue development on Bodega (the piloting GUI).

Also, I ran Monterey through Doxygen today and I was shown that I don't know how to properly add the comments and information in my code.  So I'll be spending some time adding more Doxygen information in my Monterey code soon.  That will, of course, delay the distribution of the Doxygen documentation.

That completes the bad news for today.  Luckily these are only minor issues!

On a side note, if any Android developers are out there and willing to help out with ROV-Suite, I'd love to have an Android service that reads USB joysticks and sends the values of the axes, buttons and hats over UDP to localhost.... Just saying. ;)  You can contact me in the comments if you are willing to help out!

Thanks!

Chris

Monterey 2.0.2Beta

Great news!  Monterey 2.0.2 Beta has just been released on OSX and Windows!  You can find the binaries here.  The update is fairly minor.  The biggest and most important change is the auto updating (well, mostly auto).  Now, when there is an updated version of Monterey, you will alerted by Monterey and it will provide you with a download link.

Thanks to the Fervor library for making this possible!

Thanks for stopping by and don't forget to update!

Chris Konstad

Monterey: Updater

(images from the author of the Fervor updater library)

I love adding new features to ROV-Suite to make it the best application for driving ROVs that you can find. I really do.  Since most of the base functionality is down (I still need to work on IP camera support and more debugging options), I'm starting to play around with new libraries to add useful features.  For instance, I'll be adding a library soon (shown above) that will alert the user when a newer version of Monterey is available and it will show the user a download URL.  I've been looking at the download numbers at ROV-Suite's SourceForge page, and it looks like most people aren't updating their older versions of Monterey to the latest version.  Maybe it's because they grabbed it early and used the Dropbox link that I put out, or maybe they just haven't checked back in with the project yet.  Either way, by adding this updater (which can be disabled from the preference pane), the user will be alerted to any newer versions, which often include bug fixes and awesome new features!

In other news, ROV-Suite has been well past the 100 downloads mark (56ish due to NetworkingTest alone) for quite a while now.  Monterey is pulling close to that threshold with 80 downloads so far (as of today)!  I'm looking forward to posting about the 100th download of Monterey which I have a feeling will be pretty soon!

Also, I'm not sure if I mentioned this already or not, but the early version of the bottomside software is already on the SourceForge page!  You can view it in the repo here.  Since it's a fairly simple setup, I'm not going to put it in the downloads page.  I'll start doing that later when I have a bunch of 3rd party libraries included with it.

If you have used Monterey to drive an ROV already or if you have any feedback, please let me know!  I'd love to post a quick blog entry with photos and a story or two. And, as always, feedback is very welcomed!

Thanks!

Chris K

Edit:  Apparently there have been 92(!) downloads of Monterey at Softpedia!

NetworkingTest on Google Play!

Great news!  I finally got Networking Test out on Google Play!  It took some learning on my part, but I finally found out how to use layouts properly to make a fully scalable GUI using QWidgets.  The desktop versions of NetworkingTest will be receiving that feature soon (on Windows and OSX).  I'm really happy to have consolidated the codebase for the Android and desktop versions!  Now features and bugs that are fixed for one version don't have to be replicated for the other version.  

You can find the Android version on Google Play for $1.00.

As a side note, today Nick, Alex and I etched a circuit board (to make own our Arduino) using nothing but muriatic acid and hydrogen peroxide.  It turned out great!  I'd post some pictures of it but Alex has them.  I'll upload some later.

Thanks for stopping by!

Chris K

Update: Monterey v2.0.1Beta (Windows)

Just an update to let you know that the Monterey v2.0.1Beta for Windows is up in the Sourceforge downloads page.  You can find that here.

Thanks for checking it out!

Chris K

International MATE ROV Competition

Great news!  The robotics team that I am a part of, Jesuit Robotics (a 17 member high school robotics team), just got 3rd place overall in the Explorer class (collegiate level) of the MATE International ROV Competition!  Out of many universities from several countries, only a team from Russian and a team from Perdue beat us!  On the team, my main responsibility was the software.  I'm very happy to say that we did not have a software problem at the competition!  I wrote the topside software and taught two guys, Alex and Nick, how to write Arduino code so that they could write the bottomside software.

Here's our ROV ("Triton").

I'd just like to say thanks for the guys of Jesuit Robotics for a great year, a great ROV and great friendships!  Also, I'd like to thank our mentors for their many, many hours of work and supervision that makes our program possible!

Thanks for stopping by,

Chris K

Monterey 2.0.1 Beta

Hey!  I'm down in Florida right now for the MATE ROV competition, but I just thought I'd throw up a quick post about Monterey.  If you want to download the latest version, please check here.  I have binaries there for Windows and OSX.  I have written some documentation that once I go over another time or two I'll put online.  It goes over the code layout of Monterey and the normal operations of Monterey and Tahoe.

Thanks for stopping by!

Chris K

Monterey 2.0.1 Beta on Windows!

It's late here and I have to go to bed, but here's a quick announcement about the release of Monterey v2.0.1 Beta for Windows!  It's been out on OSX for a little bit, but I've finally gotten around to rebooting into Windows and compiling it (even fixing a Windows-specific bug in my code)!  Here's a screenshot as proof!  I tried to upload it to SourceForge's servers, but it wasn't letting me upload anything today (servers seem to be having a permissions issue), so I'll post a different download link in the meantime.  You can find it here.  I'll get it posted to the SourceForge page as soon as I can!  

In other news, Tahoe was finally released onto the Android Marketplace (I hate calling it "Google Play") today!  Check it out if you have Monterey!

Finally, I have decided that the first video feed type I'll support is IP cameras.  I'm going to make a separate piloting GUI application that displays the video (with fullscreen support) with a fancy overlay that shows system states.  I'll post more about this soon!

Thanks for stopping by!

Chris K

New Graph for Monterey! (and other minor changes)

Great news!  Qwt is no longer needed to compile Monterey!  That may not seem like a huge deal at first, but now the code base for Monterey is much smaller and that is one less external dependency required to compile and run Monterey on *each* and every system it can run on.  That makes my job easier!  Also, I have added the blue tint to the graph to make it easier to see at a glance.  Also, earlier today I slightly modified the main window's title to display the curent version of Monterey.

Let's see..... Oh yeah!  I also changed some of Monterey's backend so now any commands sent from Tahoe to the ROV show up in Monterey's UI.  Now I just have to see if I can get Tahoe's commands to sync with Monterey.  I wouldn't bet on getting that to work just yet, though, because the communication between Tahoe and Monterey is UDP based.  I am hoping to switch that to TCP later this summer so that I can take advantage of event-based communication between Tahoe and Monterey.

Also, I need to add an LED to Monterey to show that Tahoe is indeed connected to it.  And of course, I need to finish up Tahoe.  When Tahoe is completed, I'll upload to Google Play.  I'm thinking of having a free version and a paid version, but don't worry!  Both applications will be the exact same and both will have their source on the SourceForge page.  The only difference will be that if you buy one of them, then you donate money to me.  If you buy the other, you don't.

I have no intention on making ROV-suite closed source or a paid application suite.  Let me rephrase that:  ROV-suite will never be closed source and you will never ever EVER have to pay even a dime to use the latest version!  This has been a FOSS project and it will always be FOSS.  The only exception to this are Android and (possible) iOS applications.  Those can be (read: not necessarily) paid apps to help offset development costs (paying to be a developer, etc).  But any part of ROV-suite necessary for normal functionality is, and will always be, free (the mobile apps are not key parts of ROV-suite.  They are more like plugins or addons)!  Keep in mind, all parts of ROV-suite (even the paid apps) will have their source at sourceforge.net/p/rov-suite, so you can always compile your own binary (it's easy!) if you want it for free.

Until I got my early-2011 MacBook Pro, I had an older Dell Inspiron E1505 that I ran XP on until I was in the 6th or 7th grade.  Then I started off with DreamLinux and eventually found Ubuntu.  From then until early-2011 (a couple of years), I used Ubuntu as my main OS (I tripled booted with XP and Vista).  I love free and open source applications and I have always wanted to do *something* to help give back to the open source community.  Now, I finally have my chance.  I have experience in this field because of my team and I have finally matured my programming skills enough to be able to be a passable programmer.  I would say that's the only reason why I do this, but then I'd be lying.  I love programming, but I only enjoy it when I have a goal, a project, an objective.  ROV-suite gives me that.  Plus, it's fun and I get to learn a lot about new techniques and new technologies (e.g. QML).  :)

Thanks for stopping by!

Chris K
P.S.  Sorry about the depth of this post near the end.

New Graph for Monterey?

I don't like linking to external libraries (DLLs, etc).  I avoid them at all costs.  Why?  Well, when trying to share source code, it's hard to make sure that everyone has everything that they need to have to both compile and run the code.  I use SDL for joysticks because, well, I kinda have to.  If I could do it all from within Qt or from raw *.h and *.cpp files, I would.  I found this QCustomPlot awhile ago when I was working on an Android application (written in Qt, of course) and it worked great!  Now that it's matured even more, I'll probably get rid of the current Qwt code and replace it with this QCustomPlot.  It's just one less library to link to and one less linkage that could cause someone compiler errors.  On windows, it's one less DLL to include in the folder.  On OSX, it's one less framework to bundle.  On Linux, I assume it'll be one less shared object to link to (I have yet to build Monterey on Linux).

Anyways, if all goes according to plan, I'll change out the graphs seamlessly tonight and then hopefully improve Tahoe's integration with Monterey.  Then maybe I'll get some sleep.  We'll see.  ;)

Any comments, questions or concerns?  Anyone know of a good way of getting USB joysticks to work in Qt on Android?  Feel free to ask/answer in the comments!

Thanks for stopping by!

Chris K

Update: ROV-suite (short)

Hey!  I'm super tired right now, so this post will be pretty short even though it covers some good material.  I'll go more in depth into these topics at a later date.  First, check out the latest screenshot of Monterey!  Like the new compass?  It's my first time embedding a QML widget in a QWidget application.  I personally like it, although the ring around the compass has a few rough spots that I need to (and will) take care of soon.  Nothing a little Pixelmator can't handle.

Also, Monterey is now multithreaded!  Yay!!!  You'll see a smoother, more responsive UI now on systems with a slower clock speed but with multiple cores.  Granted, Monterey currently doesn't take up *that* much power, but who knows how intensive it'll be in the future.  Monterey is admittedly my playground for learning about new technologies and new techniques.

If you haven't checked out OpenROV, check it out!  It's a pretty awesome open source (hardware and software) ROV project.  I'm working on making an Arduino binary that can act as a bottomside software for Monterey that is compatible with the current OpenROV setup.  That way, if you get that hardware, you can still use ROV-suite.

A friend of mine, Nick Sopwith, who is a whiz at electronics (although I will have to take some credit for helping teach him some C++), has recently taught me how to etch my own circuit boards in my garage using a laserjet printer, an iron and some ferric chloride.  He and I have a few surprises up our sleeves for our robotics team's ROV next year (he's a year younger than me and he's on the team).  Can you say Arduino Mega 2560 Ethernet plus lockable breakouts for sensors, ESCs and more?  With a built in digital video switcher?  And some IP addressable cameras?  It'll be fun stuff!  Speaking of robotics, when this current season is over, I'm gonna post some articles about the awesome control application that I've been working on for the team.  It's just about 5,000 lines of code and can help the ROV pilot itself.  I won't open source it (the code is kinda messy because I wrote the foundation code before learning much about how to split up my code into classes), but it has some interesting features and though processes behind it.

Woah.... I just realized that I still have features to add to Monterey before I can feel comfortable removing the "beta" tag.  That's after heavy testing, of course!  I need to link it better with Tahoe and just make sure it is polished.  I need to add more information to the debug tab as well.  I'm thinking having a grid of squares and progress bars that show motor value percentages, servo percentages and relay states.  Maybe I'll even through in a QVectorDecoder widget so that you can try your hand at coming up with a vector drive formula and be able to test it entirely within Monterey's UI.

Finally, I'd like to welcome my friend, Nick Sopwith, to the ROV-suite crew!  Like I said earlier, he is quite talented with electronics (custom PCBs, homemade Arduinos, etc), so he will be able to help us develop an entire control system based on ROV-suite's software and his circuitry!  Welcome aboard, Nick!

Thanks for stopping by,

Chris K

P.S.  I'll post some pictures of our PCB etching and describe the process in more depth at a later date.

ROV-suite: Tahoe

I've been working recently on the portable (tablet and netbook) UI for Monterey, and here's a screenshot! How does this work?  Simple!  Once running Monterey, join the same network (ad-hoc should work) with your tablet and then start up Tahoe!  The two will communicate over UDP and Tahoe's controls will operate the ROV.  Right now, Tahoe isn't complete, so this is just a sneak peak at things to come.  When finished, Tahoe will also display all of the sensor values with sensor names and units.  Even the relay names will sync with Monterey!

There are a few issues at the moment that I will need to work out.  First (not really an issue) is that Tahoe isn't completed yet.  I still need to add the code that displays the sensor values (even the code for my awesome compass that I got the background and outer ring from the QFlightInstruments project).  Also, my goal is to make a seamless sync between Tahoe and Monterey.  When a value is adjusted in one, it is adjusted properly in the other and also sent to the ROV.  Currently, Tahoe just overwrites anything that Monterey does, and Monterey does not display the change in its GUI (unless you check the debug window's packet display).

There's still work left to do on Tahoe, and same with Monterey.  But!  Thankfully the beta release of Monterey is out and since it's release, there have already been 20 downloads!  I am still working on getting out the documentation for Monterey and, of course, I'm working on writing and Arduino firmware that will act as the ROV's firmware ("bottomside code") for ROV-suite.  And as always, feel free to write your own!

Thanks for stopping by!

Chris K

ROV-suite: Monterey 2.0.0 Beta

Great news!  The beta release of Monterey version 2.0.0 is finally here!  This is the moment that many of you have waiting for since the end of 2011.  I have to say that because of the new features, better UI and cleaner code, the wait was well worth it!  Since I got this application ready earlier than expected, the bottomside code to compliment it and the documentation for both are going to be released sometime in the June and July time frame.  Since the source is available online on the repo, you can get all of the documentation you need from there (for the time being).  Also, feel free to compile it from source if I haven't uploaded a binary for your system by the time you read this!  I'll put the Windows binary up first (I'm in that OS at the moment) with the OSX binary soon following.  After that, I'll get around to putting up the Linux binary.  So far, I've only tested this in Windows and OSX (I haven't done much development work in Linux), so it might be a few days until I have the Linux binary up.

Also, I'm already coming up with more ideas to implement within ROV-suite.  For instance, how about using a wireless Xbox360 controller to pilot the ROV with an Android tablet application as your UI (due to joystick libraries Monterey would have be running on a laptop on the network)?  This could aid debugging and normal operations by increasing portability and flexibility.

But before I go off and start adding more features, I do want to put out some top-notch documentation and a complimentary bottomside firmware so that using an Arduino with Ethernet support (either Arduino Ethernet or an Arduino with a shield), you can have an operational ROV as quickly as possible!

Thanks for stopping by and expect more information (and posts) on ROV-suite soon!

Chris K

P.S.  I'm pretty tired tonight so this is kind of a brief post that doesn't go into too many details.  You can expect more technical details later.  Also... Happy 20th post!!!!!

Update: QML, Monterey and Source Code Analyzer

I've been pretty busy lately working on a few things (other than school and AP exams, of course!).  Other than menial updates to Catalina (my robotics team's topside application), I've written plenty of C++ and QML code for my team's Android/Windows/OSX/Linux application for this year's MATE competition (someone else on the team is working on the iOS version).  I'd say that it's looking pretty sharp so far!  Here's a screenshot!

The iOS developer made that ROVotics logo and he also came up with the color scheme for our team, so I used them for the Android (and Windows/OSX/Linux) application.  I got that compass backdrop and outer ring from the QFlightInstruments project.  I made my own ROV image for the center of the compass.  On the right hand side of the application, there is an "About Us" button that switches the UI's state to the "about" QML state, which has instructions, a team photo, website URL and a scrollable text field that loads text from a plain text file to display.  Underneath the "About Us" button are some lights that change based on values sent from Catalina.  The communication light turns orange when ROVotics establishes communication with Catalina (and turns back to the current grey when the communication is lost).  The relay indicators are going to have real labels ("Lights" instead of "Relay0") when this application ships.  On the right, there is the mission timer which is updated by Catalina and turns orange when the time is up.  Underneath the mission timer is a "Vector Decoder" (creative name, huh?) that takes the motor values sent from Catalina and adds them up as vector values to show how the ROV will respond to the joystick input.  It's really handy for debugging incorrect motor code!  That little white bar between the compass and the vector decoder is the vertical thrust value indicator.  It simply shifts up and down depending on the applied vertical thrust.  Finally, on the far right is the depth indicator.  Catalina sends ROVotics the maximum depth of the pool as well as the ROV's current depth.  ROVotivs takes that value and calculates the depth of the ROV as a percentage of the maximum depth.  The orange bar then slides up and down to the correct percentage value, which gives the user a graphical representation of the depth.

The entire UI is scalable (although there is a minimum screen resolution), so it should work on everything from phones to tablets to laptops with varying screen resolutions.  Let me tell you... Making a UI that scales across that wide variety of screens with this many elements is a pain.  It's simple to do (just a little math), but it's still a pain to have to set all of the x, y, width, and height values for each widget added.

Overall, I've really enjoyed working with QML so far, so I do plan on writing more UI's with it.  As a bonus over normal QWidgets, QML forces me to have better form with programming because it makes it harder to store variable values in the UI.  I'm taking what I've learned from this and applying it to Monterey to make the code top notch.

Speaking of Monterey, it's coming along nicely so far!  I still have to add joystick support (with optional bilinear reading).  I'm going to avoid mapping buttons and hats right now because in my experience, it's easier just to reach over and tap a keyboard shortcut.  However, if people ask for certain joystick mappings, I'll add them.  I am still planning on hitting my June target date!


Finally, I found out about this really awesome Qt application called cppcheck which is a very useful opensource C++ source code analyzer.  It catches those mistakes that the compiler won't catch (like not assigning a default value to a variable).  I've already gone through much of my code with it and have used it to help me spot errors.

Thanks for stopping by!

Chris K

Thoughts About the Shift in Monterey's Design

When I first set out to write a FOSS ROV controller, I wanted to make it as customizable as possible.  I wanted the user to be able to change pretty much everything under the sun without ever having to open up an IDE and recompile the code.  I did that.  I did write that code, and more importantly, I used it myself.  After spending some time with that (and directly using it as a code base for my code that I wrote for my robotics team this year), I learned a few things about Monterey.

For instance, it was too customizable.  There were too many options!  The customization code was messy (my fault) and cumbersome.  It just wasn't worth the gain when it was just as easy to change one line on the bottomside Arduino code to get the same net effect.  Not only that, but it scared off new users.  Between its messy UI and plethora of options and tabs and QLineEdits, new users were put off.

Because of my lessons learned on Monterey 1.0 and Catalina (my team's topside code), I have decided to make Monterey 2.0 less customizable, but easier to use (don't worry!  The application will still be useful and feature-filled!),  I think that this will make it less daunting for new users.  Also, by cleaning up my source code (after learning more about composition), I have made it easier for people to edit the source themselves if all else fails.

My goal is to provide, for free, the best available ROV controller for inspection-class (micro, mini and general class) ROVs* and I will do what it takes to accomplish that goal.  In doing so, I hope that hobbyists not interested or knowledgable in programming, but who are quite gifted when it comes to mechanical and electrical design, will be able to build more advanced and creative ROVs.

Thanks for stopping by!

Chris K

*I will still keep this hobbyist oriented, though.

P.S.  While working on my QML tic tac toe game, I came up with the idea of rewriting Monterey's GUI in QML to help give it a uniform look and feel across all OSes.  I'm still thinking about doing that, but that would be a later branch.  I want to hit my June release date, so I'm past the point of major designs shifts like that for the 2.0 release.  I also have a few other QML applications to make before then.

[Tutorial] QML with a C++ Backend

Recently I posted that I had uploaded my first ever QML application to Google Play.  I was pretty excited about that, but since then I've really wanted to have a C++ backend so that I can access more advanced features (settings, networking, etc) and data models.  Well, after playing around for a day or two, I finally figured out how to do that!  It's quite simple, really (thankfully!).

Most of the tutorials that I found for doing this left out parts of the code, which frustrated me greatly because then I could not figure out how and why they did things the way that they did.  To help avoid that issue, I'll post an archive of my source here so that no questions are left unanswered!

For an alternate tutorial, check here.

Step 1: Setting up the base of the application
I created a normal "Qt GUI" project using the SDK's wizard.  That created the *.pro, main.cpp, mainwindow.h and mainwindow.cpp files for me.  I then added a Qt Resource File (QRC) for holding the QML file (something that has to be done in order for QML to work on Android).  Then, I added a new, standalone QML file to the project.  These files will be the base for the application.

Step 2: Setting up the base of the UI
In the mainwindow.ui file, I added a QDeclarativeView that I would use to display the QML file.  In the mainwindow.cpp code (in the constructor), I added "this->setCentralWidget(ui->declarativeView);" right after the UI setup code is run.  This makes my QDeclarativeView fill up my entire UI and expand with it.

Step 3: Making the backend
This is a pretty simple step.  Start by adding a new class that inherits QObject (important!!!) to your project (I called mine "Logic").  For my Logic class, I wanted it to have a private bool that I could set and return the value of.  For the set and return functions, you can either use public slots or "Q_INVOKABLE".  I used slots because I was already familiar with them and because it would make more sense to use slots in case I wanted to tie more classes in with my "Logic" class.

Step 4: Linking the backend to the frontend
This is the part that took me longer than it should have.... First off, in mainwindow.cpp, declare two pointers: a QDeclarativeEngine (*engine) and a QDeclarativeContext (*cntx).  Set them to "ui->declarativeView->engine()" and "engine->rootContext()".  Next, to complete the linkage, use "cntx->setContextProperty("Logic", new Logic);".  Finally, use "ui->declarativeView->setSource(QUrl source);" to set the source of your QDeclarativeView to your QML file (located in your QRC).

Note
When calling "cntx->setContextProperty("Logic", new Logic);", the first argument is the string that you're going to use to call the functions in your QML file while the second argument is a object of class type Logic (in this case).  


Step 5: Calling your functions in QML
Once steps 1-4 have been completed, step 5 is as simple as "Logic.toggledNow()" in my case.  In "foo" terms, it would be "Foo.someFunction()" if you used cntx->setContextProperty("Foo", new myClass); earlier.

I hope this tutorial has helped you out and thanks for stopping by!

Chris K

Git Client on Android

I like to make sure that my code is well backed up.  Also, since I am the head programmer of my robotics team, I like to keep track of the changes that my teammates make to their code no matter where I am.  Awhile ago, I downloaded the Android application called Terminal IDE just for fun. I never actually tried it out until a day ago.  To my surprise, when I typed in "git" the help text came up.  A few minutes later, after becoming root ("su"), I had made a directory on my sdcard and was proceeding to download my team's private repo over ssh from Sourceforge! I was pretty happy about that!

For those of you who want a full featured git client (and editor with nano and vim), check out Terminal IDE.  I mean, hey, it's free!

So what are you waiting for?

Chris K

P.S. It works best with the Hacker's Keyboard download from Google Play because that exposes the tab, ctrl, esc and arrow keys.

First Officially Released Android Application

Great news!  I became an Android developer on Google's Playstore today in time to upload my first QML application (a tic-tac-toe game called QML-Tic-Tac-Toe)!  I wrote this game so that I could start becoming familiar with QML and so that I could release my first application on Google's appstore.

As you can see, it's a pretty simplistic game.  Users click on the tiles to place their color there, and when the game is finished, they can click the bar on the right hand side to reset the game.  You can find the source here.  I'll put up the link for this app once it makes it through the approval process.

I plan on taking what I've learned about QML and the Android Marketplace process from this application and applying it to my later apps.  I'm thinking about rewriting the Android ROV Spy application using QML with Qt C++.  That'll be a good lesson for me in tying the two (C++ and QML) together.

I found an awesome tutorial for putting apps up on the Market place by Cutehacks which you can see below:

Targeting Android with Qt

View more presentations from Espen Riskedal

Thanks for stopping by!

Chris K

Update on the Progress of Monterey

I've been working a fair amount recently on Monterey v2.0.  I've been hammering out some code, too (which is always nice)!  Extremely basic functionality is being added right now, with the fancier features to be added later.  Monterey can now send and receive UDP packets.  It can also read the UI's inputs for the relays and servos (and it defaults the motor values when no joystick is present).  Monterey is now also able to save and load settings (partially... still working on fleshing that out).  Although I do plan on making it so that Monterey's settings are stored in an *.ini file so that they are easy to share, backup and copy, I have yet to enable that in my code.  That'll be a feature that comes closer to the release date.

In other news, I'm still working on getting SDL to work with Qt on Android.  If anyone can help me out with that, I'd really appreciate it!  I took yet another stab at doing that today even though I am still only partially familiar with Android programming and I wound up with over 90K errors.  Yes, you read that right: Over 90,000 errors*.  I'm not counting the build warnings, either.  I'm solely counting those red stop signs that appear during the build process.  The picture below doesn't show 90k build errors, but that's because I took the picture before I reached that number.

*I obviously didn't build it right or I used one source version for building the shared object library and another version of the source for the includes.

Anyway, I'm slowly but surely churning out the codebase for Monterey.  It is my first application that I am really stressing OOP and multiple windows, so I'm learning a fair amount of the practical application of those (including sharing data between windows).  But hey!  What fun is working on a new project if you don't learn about anything new?

Thanks for stopping by!

Chris K