Recent additions to my GCS include the APM binary stream and the UavDevBoard (Matrix Pilot/Serial UDB Extra) data stream plus playback of UDB text file on the Data File tab. Quad model is also a new addition (many more models coming soon). Screen is now resizable and depending upon the instruments size, either the glass cockpit or 3D model can be clicked and selected as the "big" instrument. Minimum screen size is now 800X400 which should work well on older laptops and netbooks.
Next on the To-Do list is APM 2-way with MAVlink support, Installer and more models. Still hoping to add AttoPilot support shortly.
If you're having problems installing, make sure to run the DirectX download EVEN IF you have the latest DirectX installed. These include additional drivers MISSING from the standard DX installer.
Minimum requirement still includes .NET 2.0, Google Earth and the Google Earth API.
Download the latest here: http://code.google.com/p/happykillmore-gcs/downloads/list?saved=1&ts=1291154906
Links to minimum requirements here: http://code.google.com/p/happykillmore-gcs/
Comments
Hi Grant,
I suggest you repost your question to the UDB discussion group.
Best regards,
Bill Premerlani
Grant, I'm not sure I can help you. MatrixPilot is in constant flux to the best of my knowledge. You'd probably have to ask Peter are the compatibility at this point. I also think they were planning on going to MAVlink at some point, not sure how far they made it with that.
Hello Paul
I'm also a newby to the scene. I have a simple scenario as follows:
I've set up a UDB4 running MatrixPilot V 3.2.1 to use "#define SERIAL_OUTPUT_FORMAT SERIAL_UDB_EXTRA" in the options.h file. I have attached an OpenLog to the port on the UDB which is successfully logging channels output to the SD card. As I understand MatrixPilot outputs ascii text to the port and OpenLog just logs the data in a text file. Now when I connect the same port (I use the gnd, RX2 and TX2 pins) to my com1 serial port on my windows XP laptop and I connect using HK GCS Lite - v1.3.33 in the Serial Data tab, Raw Data window I keep getting the message IN: Unknown Message: followed by unreadable text. with the field GPS Type: changing between 20% and 35 %.
My questions are:
1) I believe I should see text that I observe in the files logged by OpenLog (for eg. the "F2:T0:S100:N0:E0..."), should I expect this?
2) When I disconnect the serial cable the GPS type changes to 0.0% but I still see the IN: Unknown Message: followed by unreadable text scrolling in the Raw Data view. Should the data not stop scrolling?
3) If what I assumed in 1) is correct then either my communication port is not properly connected (I am just using the UDB GND, TX2 and RX 2 connected to COM1 GND, RX and TX) or HK GCS needs to be set up to recognize SERIAL_UDB_EXTRA messages. If that is so would you please advise me on how I would do this?
Thanks in advance for you assistance
Grant
Rana,
https://docs.google.com/document/pub?id=1bPovneDV1UXBBEQE6yC3Ms9CCI...
1) I'm not sure what to tell you on the altitude issue. According to the MatrixPilot spec the altitude value is above mean sea level. Which means you should not be using the home location as your offset. You should be using sea level. My best guess is that Google Earth has a mistake on your actual hieght above sea level or your GPS is not accurate enough....but I'm just guessing. According to GE, your location is at 223 meters above sea level. If you set your offset to sea level, what is your UDB's altitude showing? I'm using the "A" variable.
2) I'm making assumptions that the format of the MatrixPilot output matches the spec sheet exactly. I'm assuming that variable #2 is always Time Stamp and #3 is always Status bits. Since the variable "Header" is not always 1 character or 2 characters.... it's more difficult to test for each...but I guess I'm going to have to.
The Modes 0-3 you state do not match what is shown in the spec sheet for the "S" variable. Only the last bit shows Manual or Autonomous mode. They also call it a "bit" instead of a number so it will only ever be 0 or 1. Mode 2 and 3 don't exist there. fgs may have the answers.
If the Emulator is giving you that message then I have no idea what the problem is. The next line is checking to see if a folder exists.
Happy, whatever findings, I reported recently are same even in v1.1.25.
I'm following your GCS project with great interest and I'm using it when developing firmware for the UDB. Until recently your GCS parsed the "SERIAL_UDB_EXTRA" format just fine, even if I used XBee API activated in the GCS XBee (That means that the data becomes somewhat "garbled" since the API expects the data in packets. The result is that eh XBee adds some characters to the data, but the "raw" data is still there intact. A few versions ago I realized that this didn't work anymore. No great deal since I only use the API mode on the GCS XBee if I need to adjust the XBee aboard the UAV, but nevertheless it was an extra step to do each time. Now, today (29 Dec. 2010) I downloaded the latest(?) version 1.1.25 and can't get it to parse the "SERIL_UDB_EXTRA" format at all. I see the data coming in at 57600, but it doesn't become translated. (I must add that I have some extra strings in my personal telemetry use for controlling the XBee.) The 866MHz PRO has a duty cycle of 10% and therefore has to be reset at least in 6 minutes intervals). I do this via the telemetry data. Another important note is that I use this on a lab bench setup with X-Plane for HIL-simulation. That means that there is no actual GPS in the setup. The GPS data is fed to the UDB from X-Plane and later to the telemetry port. Have you lately changed the parsing so that my setup is "disqualified", or is there anything else going on here?
Otherwise, keep up the great effort of creating a useful GCS for every UAV nut ;)
Kind regards
Marc
will email!
I'll do some testing tongiht. I'm sure I've got a few bugs in there. I added a bunch of Time/Date parsing stuff recently to get ready for my new and improved parsing routine for saved files. I should be able to determine the correct playback speed for most of the protocols my GCS understands. The ones missing date fields are ArduPilot, ArduPilot Binary, ArduIMU, Gluonpilot and MediaTekv1. All those protocols will either have a combobox to select the rate at which messages are parsed or it will default to something like 4Hz. If the output is saved using the GCS this is a non-issue because I add a timestamp to every message. All other protocols include either a time or a date/time stamp on at least one of their messages.
What I'm getting at is the date/time parsing probably has a localization error due to periods or commas as decimal places. What protocol were you playing back? Any chance you can send me the .hko file? happy@happykillmore.com
OK - ran a few more things. Was running a previously recorded mission hko file
Works great using both your server and mine. Reversing also works.
Mystery behavior is it works only with a live serial connection. Running a recorded mission data set is what is generating the script error. If I startup with a serial connection, disconnect, then try to run a recording, I don't get the script error but webbrowser1 doesn't update. Same result using a fresh record file and a previously recorded file from 1,1,14.
Hope this helps
-
1
-
2
-
3
-
4
-
5
of 17 Next