Jump to content

[1.0.4] (2015-07-04) Telemachus – Telemetry and Flight Control in the Web Browser


Rich

Recommended Posts

OK here's some pictures of a linux terminal screen running a first jab at providing flight data using the Telemachus API. There are two basic displays so far, one showing telemetry data about vehicle position, and the other showing some basic radar info. The radar info has about a 1% error, and rounds altitudes. The telemetry lat and long also have a built in error.

First is a screen showing everything working as planned. The "-" next to telemetry altitude is no showing a negative altitude, it's showing that the number is trending downward.

http://i.imgur.com/2JbJXlA.jpg

Second is a screen showing what the controller would see if telemetry was lost. It shows an error and displays the last data it got. I haven't figured out how to query whether or not the antenna is active (help!) so for now it just returns failures randomly about 10% of the time for testing. Radar data is unaffected.

http://i.imgur.com/pUP8SWj.jpg

Last is a screen showing normal operation outside the range of the radar. The radar range is configurable but I have it set to only work around Kerbin between 500m ASL and 7Mm ASL.

http://i.imgur.com/CUK1DRL.jpg

Ok, so here's my prototype UI that i've been working on the last few nights.

- It's a lot more visually orientated and the modules are based off of the look and feel of the existing UI for KSP.

- It's designed as more of a ksp 'remote' for mobile devices and display for second monitors rather than a raw telemetry readout.

- It's completely modular - add as many modules or as little as you need via a drag and drop grid.

- The layout is saved automatically between refreshes and can be exported/imported so you can share your own custom control screen.

- You can add custom resource modules (i.e to track Food, Water, Kethane...) in addition to the stock ones.

- There is a template structure for the individual modules that you can use to (in theory) code your own.

I can confirm that it does run smoothly (albeit with a few bugs) on both an iPad and Android Tablet, but I won't be prioritizing optimization for phones due to screen size limitations and general clunkiness.

http://i.imgur.com/ZqkFZ00.png?1

The add module GUI has filters for different types. There are buttons, scales, dials, screens/displays and resources.

http://i.imgur.com/PNnncnH.png

You can drag and drop any element to where you want it and delete by hitting the cross at the top right.

http://i.imgur.com/BZyVeNE.png?4

Pretty much all of the modules are functioning. Note the added 'Oxygen' resource which comes from TAC life support.

http://i.imgur.com/g6gp2wa.gif http://i.imgur.com/jFOBrNw.gif

Just to show the animation in action.

My mouth is watering.

Link to comment
Share on other sites

Sweet mother of <deity>. I suspect something as intense as this would benefit from websockets.

Absolutely! I've done some work with Node.js and Websockets in the past and it can be lightning quick (I built a small multiplayer game with it). At the moment I am seeing a small amount of lag in getting data over wifi, so hopefully the switch to sockets rectifies this, else there will be a lot of prediction going on to keep things looking smooth haha.

I started work on implementing a three.js navball...

oEAYq30.gif

1Hy4n2g.png

Please excuse the colour, I wanted to keep the fps on the gif quite high. Works a charm locally on my desktop but there are massive fps and delay issues for this on the tablet that I will have to look into, that is at least partly related to the interval at which it gets data and partly just because mobile browsers suck at running anything javascript related, especially jQuery.

Edited by Sli
Link to comment
Share on other sites

Absolutely! I've done some work with Node.js and Websockets in the past and it can be lightning quick (I built a small multiplayer game with it). At the moment I am seeing a small amount of lag in getting data over wifi, so hopefully the switch to sockets rectifies this, else there will be a lot of prediction going on to keep things looking smooth haha.

I started work on implementing a three.js navball...

http://i.imgur.com/oEAYq30.gif

http://i.imgur.com/1Hy4n2g.png

Please excuse the colour, I wanted to keep the fps on the gif quite high. Works a charm locally on my desktop but there are massive fps and delay issues for this on the tablet that I will have to look into, that is at least partly related to the interval at which it gets data and partly just because mobile browsers suck at running anything javascript related, especially jQuery.

The loss of colour is worth it to see the excellent sync between the actual nav ball and the web representation.

Link to comment
Share on other sites

I was screwing around in PS.... I like the idea of using my tablet as a Apollo-esque command console

http://i.imgur.com/jOcDKP6.png

This is EXAAAAAACTLY what I need.... I guess I just have to go and laser-cut myself a holder for the tablet and maybe some kind of buttons and stuff and wire everything with and Arduino... BUT I GOTTA HAVE MY LAUNCH CONTROL CONSOLE !!1!1!!! :D

Link to comment
Share on other sites

A friend and I decided to give a team-flying, 'mission control' setup a go. I have telemachus running, and he was able to connect, only the data updates to him were uselessly slow. Like, one update per minute.

Now, I have terrible internet. I live in Canada's far North, where all the options are satellite, and they're all poor. That said, this was in a realm well beyond what I normally experience. I can play MMOs with lag usually in the 600-700ms range ... not 60 seconds.

Is this a known thing with telemachus and high-latency connections, or is something else up here?

Link to comment
Share on other sites

Has anybody else stumbled upon an error that causes the longitude output (v.long) to have a strange offset?

I normally have good readings at start but I've encountered several times that v.long was reading large negative numbers, such as -410. This causes the map display to show the ship well outside the map, and obviously causes my telemetry display some amount of confusion in converting to East/West coordinates :P

Edit: Should note that it still seems to reset once per orbit, it's just that the number is offset.

Link to comment
Share on other sites

A friend and I decided to give a team-flying, 'mission control' setup a go. I have telemachus running, and he was able to connect, only the data updates to him were uselessly slow. Like, one update per minute.

Now, I have terrible internet. I live in Canada's far North, where all the options are satellite, and they're all poor. That said, this was in a realm well beyond what I normally experience. I can play MMOs with lag usually in the 600-700ms range ... not 60 seconds.

Is this a known thing with telemachus and high-latency connections, or is something else up here?

The issue is known but the root cause is not, and I am hoping that the addition of web sockets will either solve the problem or point towards it.

Has anybody else stumbled upon an error that causes the longitude output (v.long) to have a strange offset?

I normally have good readings at start but I've encountered several times that v.long was reading large negative numbers, such as -410. This causes the map display to show the ship well outside the map, and obviously causes my telemetry display some amount of confusion in converting to East/West coordinates :P

Edit: Should note that it still seems to reset once per orbit, it's just that the number is offset.

I believe KSP is to blame in that it sometimes provides longitude values which are correct to some modulus of 180/360. Are you using the latest version of Telemachus (1.4.16.0)? As I am pretty sure I fixed the map view at least. If you are using the latest version then I will take another look at it.

Great mod but it needs vessel mass and it also need to be fixed to work with nathankells real fuels. Also it should have a way to print out a log of the data over mission time.

I will ask Nathan about his real fuels and maybe one day I will get round to writing a logger.

Link to comment
Share on other sites

I believe KSP is to blame in that it sometimes provides longitude values which are correct to some modulus of 180/360. Are you using the latest version of Telemachus (1.4.16.0)? As I am pretty sure I fixed the map view at least. If you are using the latest version then I will take another look at it.

I am running 1.4.16.0, yes. I'll try to do some more testing and see if I can spot a pattern. So far I have never had an error with the reading on the launchpad. At prelaunch check everything matches up, it always pops up later.

Link to comment
Share on other sites

OK I just stuck a ship with a MechJeb2 on it into orbit and monitored the surface info longitude in that side by side with the Telemachus map and v.long value. Interesting, if odd observations to follow.

At the launch pad, we know that the longitude is about -74.55 degrees. The telemetry however is showing the proper map position, but giving a v.long of 285.442. As I launched, this number increased normally as I headed eastward, and then suddenly changed to a negative number which corresponded perfectly with the longitude readout of MechJeb2. At no point did the map display show an incorrect position. As I neared 0 degrees longitude, all displays were synchronized perfectly, as they were at 180 degrees. Here, they diverged, as MechJeb2 "crossed the dateline" and now began counting from -180 toward 0. The map displayed correctly, and v.long continued rising until a reading of about 240 degrees longitude. At this point it switched over to a negative number and was again synchronized with MechJeb2. Interestingly, upon passing KSC in orbit on this first pass, v.long read -74.55 degrees. I time accelerated to lock down exactly where the switch from positive to negative occurred, but on my second pass, it happened somewhere around 230 degrees. The next pass it was even earlier. The map was still displaying correctly however.

I then did a revert to launch to see if the 285.442 reading on the launch pad might have been an error on my part, since it displayed correctly when passing overhead. It once again read 285.442. However, about a minute later it suddenly switched to the correct reading, without a launch. Not much in the way of a theory on my part, but hopefully the data will mean more to someone else than it did to me.

Link to comment
Share on other sites

Wow great looking mod! I'm working on an arduino control board and we really want to include flight data displays. I'm quite new to using APIs, can anyone give me a brief idea of what the C++ code might look like to retrieve data such as altitude and resource level from Telemachus? Much appreciated!

We will be posting progress of this project in another thread eventually if anyone is interested.

Link to comment
Share on other sites

hey rich, how come i cant use the dpad or touchball to change pitch roll or yaw while sas is enabled?! something broke?!

I will check it out, but it might be a limitation of the KSP API.

OK I just stuck a ship with a MechJeb2 on it into orbit and monitored the surface info longitude in that side by side with the Telemachus map and v.long value. Interesting, if odd observations to follow.

At the launch pad, we know that the longitude is about -74.55 degrees. The telemetry however is showing the proper map position, but giving a v.long of 285.442. As I launched, this number increased normally as I headed eastward, and then suddenly changed to a negative number which corresponded perfectly with the longitude readout of MechJeb2. At no point did the map display show an incorrect position. As I neared 0 degrees longitude, all displays were synchronized perfectly, as they were at 180 degrees. Here, they diverged, as MechJeb2 "crossed the dateline" and now began counting from -180 toward 0. The map displayed correctly, and v.long continued rising until a reading of about 240 degrees longitude. At this point it switched over to a negative number and was again synchronized with MechJeb2. Interestingly, upon passing KSC in orbit on this first pass, v.long read -74.55 degrees. I time accelerated to lock down exactly where the switch from positive to negative occurred, but on my second pass, it happened somewhere around 230 degrees. The next pass it was even earlier. The map was still displaying correctly however.

I then did a revert to launch to see if the 285.442 reading on the launch pad might have been an error on my part, since it displayed correctly when passing overhead. It once again read 285.442. However, about a minute later it suddenly switched to the correct reading, without a launch. Not much in the way of a theory on my part, but hopefully the data will mean more to someone else than it did to me.

It sounds like I just need to place the same safe guards on the table output as I have on the map view.

Wow great looking mod! I'm working on an arduino control board and we really want to include flight data displays. I'm quite new to using APIs, can anyone give me a brief idea of what the C++ code might look like to retrieve data such as altitude and resource level from Telemachus? Much appreciated!

We will be posting progress of this project in another thread eventually if anyone is interested.

1. The arduino will need to be connected to the same network as the computer running KSP.

2. Use libcurl to make HTTP requests to the Telemachus server.

HTTP requests take the following form.

http://127.0.0.1:8080/telemachus/datalink?alt=[B]v.altitude[/B]

The text in bold is the API string and a full list of these can be found on the landing page served by Telemachus.

Link to comment
Share on other sites

We will be posting progress of this project in another thread eventually if anyone is interested.

Please be sure to add a short notification here as well so we don't overlook your new thread. Sounds so amazing it would be a shame to lose sight of it :)

Link to comment
Share on other sites

1. The arduino will need to be connected to the same network as the computer running KSP.

2. Use libcurl to make HTTP requests to the Telemachus server.

HTTP requests take the following form.

http://127.0.0.1:8080/telemachus/datalink?alt=[B]v.altitude[/B]

The text in bold is the API string and a full list of these can be found on the landing page served by Telemachus.

Fantastic thanks!

Please be sure to add a short notification here as well so we don't overlook your new thread. Sounds so amazing it would be a shame to lose sight of it :)

I'll keep you posted, right now we are just working out our parts orders but we'll get a thread going soon.

Link to comment
Share on other sites

Figured I'll drop off a little update on the terminal using the Telemachus API.

We've done some early tests with a pilot in a Raster Prop Monitor capsule with two mission controllers. We found that two scripts running continuous requests for data was... a bit much for our system, or Telemachus. But never fear, I did some rewriting and now have a separate script which gathers the data from Telemachus and then distributes it via RabbitMQ to as many separate screens as we want. So now we're on to designing screens for EECOM, FDO and Booster. Here's a pic of the latest version of the Flight Directors summary screen.

jHqt2Tm.jpg

Link to comment
Share on other sites

gathers the data from Telemachus and then distributes it via RabbitMQ to as many separate screens as we want

Wow, now stuff starts to get really really amazing.. :cool:

Next level of dream: distributed Multiplayer control where the "Flight Officer" controls the Munar Approach while the "Science Officer" controls which experiments are being performed when, each player using his/her own laptop / tablet / purpose-built flight control setup :0.0:

Link to comment
Share on other sites

Quick update on development progress:

The web socket server is "working", in that a command can be sent from a browser to request a subscription to a data stream. The subscription request doesn't do anything when it gets there, but to fix that is just a matter of hooking it up to the same code the HTTP server uses to grab KSP data.

With advice from alexmun the following protocol has been put together:

{
"subscribe": [
"v.altitude",
"v.name"
],
"command": ["v.stage"],
"unsubscribe": [ "v.surfaceSpeed" ]
}

The above command when sent will: activate the next stage; subscribe to the altitude and vessel name streams; unsubscribe from the surface speed stream.

All dictionary keys are optional; that is, "{}" is a valid command but does nothing, and the following will just activate the next stage.

{
"command": ["v.stage"]
}

Next:

Pack KSP data up and stream it back to the browser.

Edited by Rich
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...