[WIP] The REAL Nav Ball Project Thread

[richfiles]

So, I had an opportunity to actually buy a real FDAI. I think it was from an F-4 Phantom simulator. Do you know anything about actually interfacing the real deal? it's not quite as fancy as the Apollo ones. It doesn't have all the needle indicators that that one does, but it is a 3 axis ball.

[ArsenioDev]

So, I had an opportunity to actually buy a real FDAI. I think it was from an F-4 Phantom simulator. Do you know anything about actually interfacing the real deal? it's not quite as fancy as the Apollo ones. It doesn't have all the needle indicators that that one does, but it is a 3 axis ball.

First I''m going to need images of the connectors to get a rough idea of the currents involved. Its going to need several things including a gyro voltage, then slewing (?) control signals

[richfiles]

She's real beaut, this one...

That ball turns smooth as butter! OHCRAPOHCRAP!!! Neilmon, you're getting mighty close to gimbal lock... Oh wait... Kerbals DID get an extra gimbal for Khristmas!

The reason a Kerbal Pilot can hold vectors and nodes and such, is the Scientists and Engineers ask what direction "Z" and "M" are. Jeb says "You're kidding, right?"

That Raytheon "chip in a can" has a date code of 1974! This puppy is 5 years older than ME!

This type of FDAI uses a 115 volt 400 Hz signal, driven through synchro control transformers (rotated by the gyro assembly). There are 9 synchro signal lines (3 per synchro/axis) as well as the base inverter reference signal going into it. My FDAI is an ARU-11A, from an Israeli F-4 Phantom simulator... Mil spec site says 3 axis, specifically "Three axes attitude indicator used to provide continuous pitch, roll and azimuth information". Funny, I used to BUILD synchros for both the US DoD and some weather tracking equipment suppliers at my old job! IF ONLY I STILL HAD SOME SYNCHROS!!!

Elsewhere, I found the pinouts: "The heading, pitch and roll can be moved using synchros. Pin connections are: A=Ground, B=115 V- 400 Hz, F=Heading-x, G=Heading-y, H=Heading-z, J=Glide-slope-flag+, K=Glide-slope-flag-, P=rate-gyroscope-power-warning-flag+, R= rate-gyroscope-power-warning-flag-, S=glideslope-pointer+ , T=glideslope-pointer-, U=vert-ptr-flag+, V=vert-ptr-flag-, W=horiz-ptr-, X=horiz-ptr+, Y=vert-ptr-, Z=vert-prt+, a=pitch-x, b=pitch-y, c=pitch-z, d=roll-x, e=roll-y, f=roll-z, g=lighting (5 V), h=lighting (GND), C,D,E,L,M,N and j not used.

Funny thing, I almost panicked and thought that I had bought a 2 axis unit by mistake, cause I couldn't see the yaw X, Y and Z in the pinout. Using heading as the label threw me WAY off! I eventually figured it out.

The flag items are small solenoid like actuators that flip out warning flags on the unit. The pointers are basically analog meters. I do not know if they are voltmeters or ammeters. I have not yet determined this information. The lighting only requires 5 volts.

A person could operate this two ways... Software emulation of the three synchros. You could use something like an arduino with 10 analog outputs (smoothed PWM, I guess) and processing to simulate the the 400 Hz reference sine wave needed, plus the amplitude multiplier for x, y, and z representative of the angular position of the rotor on a real synchro, and feed those into an amplifier that can drive the 115 volt outputs at the 400 Hz frequency...

The other way is to buy three synchros, and mechanically pair them to some stepper or closed loop servo motors, and drive the motors using a more traditional motor control program to represent the three axes. Then all you need is a single 115 volt, 400 Hz inverter to supply the FDAI and synchro control transformers.

Also... It is painted with a thick paint (I know... I've DONE THIS to products we made back at my old job)... Any trace of screws are well and thoroughly covered. I do want to pop it open at some point, but not if I risk damaging it in any way shape or form... So for now, I shall resist the urge, and just focus on getting it to work. i also gotta say, the pics don't do it justice... It really looks bigger in person. The visible portion of the ball, the aperture that it is exposed though, measures 3 inches in diameter (7.35 cm). That size quite literally doubles the width of the ball I have on screen! It's also QUITE visibly pleasant to look at. You don't EVER strain to see the numbers or markings. They are simply clear, and highly contrasting.

I certainly still wanna see this project come to fruition. Not everyone can get their hands on one of these.

Also, to an earlier post regarding tape gauges... If one were to go to a vinyl/screenprinting shop, I'd say price out a strip of vinyl from them, screen printed with the gauge. If you go with something on a clear base (not sure if you can do that or not), then you could make the tape wider than the display glass, and have an encoder strip on the side. That gets you your position feedback. To reset, roll to zero, detect index, and then count up and down as your values fluctuate.

Edited July 18, 2015 by richfiles

[Stoney3K]

Another option here:

http://eclecti.cc/computergraphics/snow-globe-part-one-cheap-diy-spherical-projection

http://eclecti.cc/files/2011/08/snow_globe-e1312774018118-700x1050.jpg

If you want to go the spherical display route, you would only need a hemisphere since you can't see the back of your navball anyway. Get a frosted plastic or glass hemisphere and a pico projector and you're pretty much done.

But frankly, this would replicate the look of ancient oscilloscope-style CRT displays more than it would look like a mechanical ball, might still be neat for other instruments or camera views.

[richfiles]

Back to my comments about tape meters... sewing tape measures. These are flexible rulers, usually marked between 0-150cm (or 0-60 inches, sometimes both, one scale on either side), used for making fabric and tailoring measurements. If you spool one of these things up on two motorized reels, and have an optical sensor to watch the ticks on the back side of the tape, you could index off of that, while moving the tape up and down for your readout. Just an option. Also, I've since built my DAC/Pre-Amp board for my synchro emulator!

Crude wire wrapping, cheap Chinese made LM386 audio amps, and DACs marketed for Arduino usage, all cobbled together. I still need 10 transformers, and I need to build the power driver for the reference voltage output, which also functions as the FDAI's power supply... But I think I'm making progress!

(This is old news from the hardware simpit megathread, but I figured since I started discussion here, I may as well follow up on it)

[csx23]

So someone thought that having a thread would get more views than a blog so I thought, what the heck...<snip>

just discovered this via your not-so-subtle signature and glad I did. wow man all the hardware, cool B/W navball picture from the 30s and stuff - on a serious note I applaud your keenness.

you call it your "your KSP sim" - it is more like a comic-character-game for me but that's the evidence of Squad's success, I guess this game can be what you want it to be. at least the building block for it

also many thanks for the clear picture with your fingertips - finally got you Neo. wait there, we'll be with you in 5!

[NeoMorph]

I keep trying... I really need a CNC machine but every time I get close to having enough money to buy one something else pops up... like my fridge dying and then my main router, then the hard drive in my home server... it's just one thing after another.

I'm still working on it... BUT... (and it's a big Kardashian butt)... I need to engrave the sphere... which is another reason I am going a bit wobbly on the enthusiasm. I would have to really learn 3D CNC engraving and omg would that be a tough thing with my memory.

Still, every summer (only time I can do any work due to disability) I get out my plans and try to update them. The software side works (or it did do last year) but that is only because of the lovely Telemachus mod. I'm probably going to do a sim that will be a fixed version (hopefully 1.1) to build the sim around. That way I will know what mods work or not.

I'm still playing KSP... and I doubt that will stop anytime soon and once I get the 3 axis version working (got a 2 axis aeroplane one working for a friend's sim) I'll carry on posting. I will keep on trying.

[Deserdi Verimas]

What is your sphere made of?

[Space_Artist (4 real)]

Your construction project is about a NavBall that would connect to KSP for game purposes, but I am looking forward to an actual self-made NavBall that would stay in the same direction to show the rotation of a craft. Is it possible to build a NavBall's wich stabilisation system consists of the stabilisation force of gyroscopes coupled with the axis system posted by NeoMorph at the end of page 1. Are there such things as miniature good quality motor-driven gyroscopes that could fit inside a NavBall and, if so, what manufacturer produces them?

 

Also, NeoMorph, are you a standard-looking neomorph or are you customized and, if so, just how comfortable are full float traction belts? I'm not sure wether or not I should visit Timbl or content myself of Talsit sessions...

==========================================EDIT===========================================

I forgot to mention but this project is great keep goin'!

Edited July 18, 2016 by Space_Artist (4 real)

[thehellhound]

I'm trying to build an interface for a ROVsub and everyone just uses I-pads with digital displays, which lead me to KSP for ideas on physical hardware. I had a thought, it really doesn't need to be a real nav-ball, just walk like one and talk like one right?

turn this upside down and you have a three axis high speed nav-ball. If you used motors with encoders, or stepper motors you could position the ball with very high accuracy and calibrate to a home position. A small spring mounted ball on the top would hold the "nav-ball" against the drive wheels without needing to fear the ball jumping. Being as the drive wheels have one drive axis and one free wheel axis, your ball wouldn't suffer from skidding on the drive.

[NeoMorph]

Welllllllll.... after all this time I am STILL coming back to this project and looking for ways to make a real nav ball work for me. Sooooooo many small and large hurdles but the one really hard part was money as I only live on a disability benefit. The problem with my project is that the tools I would need to build this thing small as the Apollo FDAI is just beyond me... yet there are now, real world parts that are smaller versions of the parts that are in the FDAI (such as the attitude error servos that drive the arrows you see above, below and to the right of the 8-ball). So overall I think my bodge should be reasonably sized (i.e. Not football sized heh).

So hopefully I will have some new progress pictures here shortly... I've got to wait for some more parts to arrive from Europe and China you see before I can finish prototype 6. I really wish I hadn't lost the pictures of the failures I've had so far... 5 was really spectacular (and that is why I took a long break). Damn thing tore itself to bits when I induced a fast roll to the rig.  Then it started smoking and killed the driver board due to a bad short.

I was NOT amused... but I suppose it was very Kerbal. It was an expensive failure though.  Something I really couldn't afford. Home made pcb... kaput (cpu chip died but at least I bought a bunch of them for this very reason.  In the end it was all my fault (badly made contacts in the ball itself unfortunately... but man.... the amount of smoke it made... I thought it was going up in flames). 

We will have to see if this is failure 6 or success 1. But this time I'm backing up my photos via USB (I pulled the card out last time and the damned thing came apart on me). Oh and the the thing that keeps me trying is a saying I believe in... "Every cock-up teaches you at least one new thing". I learn a lot!

Oh and I think that if I get this beast working the REAL hard part will then be engraving a sphere. I know how to do it but I'm going to have to make a couple of custom rigs to do so... and yeah, I'm going to have to learn cnc arrggggh.

[NeoMorph]

Well, another year and I'm starting my prototyping again. But I have realised that because I haven't really coded anything for several years I am vastly out of practice. Plus the fact that I learned too many languages means I keep getting them mixed up.

Basically I need help on the KRPC to Arduino coding side!

As a programmer its tough asking for help. It means I can no longer keep up with the current systems... but as they say, "If you don't use it, you lose it!" which is very true. I suppose I could kickstart my brain if I could just see some code that lets me extract the data that my navball needs. I've seen people code software versions using KRPC which looks even harder than what I need so I know it can be done.

I'll post the requirements shortly because I need to go do some real world stuff. Oh and my brain is still hurting from trying to figure out stuff.

 

 

Link to old Nav Ball Thread ->     http://forum.kerbalspaceprogram.com/index.php?/topic/46264-wip-the-real-nav-ball-project-thread/

Edited June 29, 2017 by NeoMorph

[NeoMorph]

Oh the horrors of eBay...

Just received the heavy gear I needed for the main axis. Only when I went to try fit the gear to the axle... it doesn't fit. Measured the axle 9.98mm... gear hole... 9.18mm... and I ordered 10mm for both.

*facepalm*

So now I've got to go out and get a brand new 10mm drill and drill the hole myself... through a big chunk of metal.

Edit 2: I've now asked the supplier to send me a better one... all the other gears came out perfect... it was just this one that is a botch job. Here is one of the good ones (this is the supposed matching gear to the botched one).

 

Edit: And here is the offending item....

This hole was supposed to be for a grub screw... but he somehow screwed it up and then he just left it. Also note the dents in the teeth... was this a 12 year old making it? I think I made better when I was at school.

Edited July 4, 2017 by NeoMorph
Added photos of gear.

[Freshmeat]

Good luck on the endeavor. There has been a lot a talk about the hardware in Mulbins thread, but I have not seen a software solution anywhere. I don't want to bother the esteemed gentlemen, but Stibbons have done a lot of work on a navball display and Richfiles has been giving advice on the hardware side.

[artwhaley]

I'm happy to help with the krpc side, if you're still wondering about that part?   Do you just want heading, pitch, and roll, referenced to the planet you're orbiting? 

[NeoMorph]

Heading, pitch and roll (or properly said, X, Y and Z axis) are the basics but then I want the rates of change for all three too... then that pesky target you get on the nav ball when you set a burn too will be translated to the error needles on the FDAI (that's the error or how far out of alignment you are to the burn target in the X, Y and Z axis). So that's 9 variables I need.

Oh and thanks for the help. I've programmed in all sorts of stuff over the years, from huge mainframes to tiny embedded stuff... but living on morphine really defocuses the memory... and without memory I end up spending more time looking something up than coding these days.

The way I will set up the navball will be to have a Cage option where the switch disconnects the FDAI from the input and returns to 0, 0, 0 position (or where it thinks the 0 position is) and then I just offset the ball using rotary encoders to align the ball... pretty much like how the Apollo Astronauts did...

 

I'm also going to have to select the guidance mode from surface to orbital a target which should affect the FDAI 8-ball like the KSP navball.

 

Changing the guidance mode is easy (joystick button) but I don't know (yet) how it affects the data coming out to the nav ball. My motors can change the orientation really quickly but I think I will include a ramping system to stop any sudden jolts (I think I broke prototype 4 that way... may have been 5). Because my old version wasn't balance right it was like something had hit the prototype with a metal bar. I had used 2 point support made out of crappy acrylic sheet layered together and the thing just shattered when I switched instantly from prograde to retrograde in a tiny craft. To say I jumped when the thing just disintegrated in front of me was an understatement.

I will probably shift to weaker motors when I build a production model design (if I do that is) but I want to see how fast I can drive he changes without it falling apart. 

The reason for this is that I'm using 10mm acrylic to make the cage and outer chassis so you can see the thing working inside. If I stress test it and it stays working I won't even need to switch to metal.

Oh and here is how the ball is actually two hemispheres connected through a central disk of metal... and actually the pitch and yaw motors are INSIDE the ball.

 

Edited July 5, 2017 by NeoMorph

[NeoMorph]

Well... got some good news...

Quote

Hi, dear customer,
Thanks for your picture. We apologize for the problem/. Pls take ot easy, we will be responsible for your purchase. Thanks.
Would you mena that the large gear was defective and in wrong bore diameter, right? To solve it, we would like to resend a new and correct bore size large to you, is that Ok? 
Look for your reply. Thanks. 
Have a nice day! : )

Best regards

I so love Chinglish... heh. But the good news is they are sending one out with the right bore size.

[NeoMorph]

Even more good news... these arrived...

 

can anyone guess what they are?

They basically replace this record player thing in the 1960's FDAI...

 

 

 

[NeoMorph]

21 hours ago, artwhaley said:

I'm happy to help with the krpc side, if you're still wondering about that part?   Do you just want heading, pitch, and roll, referenced to the planet you're orbiting? 

Art, do you happen to do physical interfaces too? 

[artwhaley]

The physical side of it is probably more than I should get into, though it seems like it wouldn't be hard to use pyserial to command movements to an arduino or similar, and use the arduino to drive the stepper or continuous rotation servos?

 

Here's a quick script to get you started with those nine variables.  I'm SURE there are ways to streamline it... and I need to think more about if there's a way to get more useful numbers for the error indicator needles...  since as it is the heading and pitch needles correspond to the arbitrary roll value that isn't very important to node burns...  and it would be better if they just responded to the vessel's pitch and yaw instead?  But it should get you to the next stage of testing!  It, of course, just prints the values - but you shouldn't have trouble finding pyserial examples, or similar, for how to pass them out to a microcontroller to drive the motors.

 

import time
import krpc

def main():

    hz = 10  #update rate in updates per second!
    
    #Setup KRPC
    conn = krpc.connect()
    sc = conn.space_center
    v = sc.active_vessel

    last_pitch = 0.0
    last_head = 0.0
    last_roll = 0.0

    surf= v.flight(v.surface_reference_frame)
    while True:
        
        #First, grab pitch, heading and roll, referenced to the surface.
        pitch = surf.pitch
        heading = surf.heading
        roll = surf.roll

        #calculate rate of change
        pitch_chng = pitch-last_pitch * hz
        heading_chng = heading-last_head * hz
        roll_chng = roll-last_roll * hz

        #and store current values for next time
        last_pitch = pitch
        last_head = heading
        last_roll = roll
        
        try:  #If there's a maneuver node, grab it's data
            node = v.control.nodes[0]
            nav = v.flight(node.reference_frame)
            pitch_error = nav.pitch
            heading_error = nav.heading
            roll_error = nav.roll
        except: #otherwise center the nav needles
            pitch_error = 0.0
            heading_error = 0.0
            roll_error = 0.0

        print("NavBall     : {:03.2f}     {:03.2f}     {:03.2f}".format(pitch, heading, roll))
        print("Change Rate : {:03.2f}     {:03.2f}     {:03.2f}".format(pitch_chng, heading_chng, roll_chng))
        print("Nav Needles : {:03.2f}     {:03.2f}     {:03.2f}".format(pitch_error, heading_error, roll_error))

        time.sleep(1.0/hz)  #delay 

##This calls the main function which is at the top of the file for readability's sake!
if __name__ == '__main__':
    main()
    print('--')

 

[NeoMorph]

The physical engineering side of things I've finally sorted out (thank god) and I just need my damned bearings to arrive and I can finally put together prototype 7 which will be the first "all up" build with all three axes modelled and will include the control panel and associated parts.

The weird thing is that the bearings were ordered from 3 different suppliers and none have arrived yet items ordered from Hong Kong two weeks before I ordered the bearings have arrived already. I hope they haven't vanished somewhere in Europe...

I hope they arrive soon.

Regarding the programming... where is that code running? This is the problem that got my brain in a fug. There are so many different languages that krpc supports and I can't find an example of getting that data down to an Arduino yet I know it's possible. My previous setup (several years ago) used Telemachus and I had the data transmitted over the network and the Arduino used an Ethernet shield. I basically got a line of numbers separated by comma (iirc). The Arduino took that line, split the data and passed it to the motor drivers.

 

 

Edited July 8, 2017 by NeoMorph

[NeoMorph]

LOL.... please forgive this rough code but this is from the early version I was running back in 2013 (yeah, long project heh). I can't seem to find the later ones yet I know they existed because they were the ones that crashed Prototype 5 so dramatically and set the driver board for one axis to smoking like a firebomb...

I tend to really code in simple to read blocks these days (and add numerous comments) becase all my streamlined code I used to write back in the 90's is basically gibberish to my drugged up brain now. Hell, I used to code in APL Darn it and if you have ever seen it you would have thought it was in greek lol... mind you it does use a lot of mathematical notation.

Anyway, this was the first example to get the data across the network and into the Arduino.

/*

This is the basis for the Aduino Main Brain reading from Telemachus on the net

*/
#include <Ethernet.h>
#include <SPI.h>

////////////////////////////////////////////////////////////////////////
//CONFIGURE
////////////////////////////////////////////////////////////////////////
byte server[] = { 192,168,1,182 }; //ip Address of the server you will connect to

//The location to go to on the server
//make sure to keep HTTP/1.0 at the end, this is telling it what type of file it is
String location = "/telemachus/datalink?pitch=n.rawpitch&roll=n.rawroll&yaw=n.rawheading HTTP/1.0";


// if need to change the MAC address (Very Rare)
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
////////////////////////////////////////////////////////////////////////

EthernetClient client;

char inString[50]; // string for incoming serial data
int stringPos = 0; // string index counter
boolean startRead = false; // is reading?

void setup(){
  Ethernet.begin(mac);
  Serial.begin(115200);
}

void loop(){
  String split = connectAndRead(); //connect to the server and read the output

 // Serial.println(split); //print out the findings.
  
  //String split = "pitch:328.6074,roll:64.62955,yaw:143.8955";
  String AllPitch = getValue(split, ',', 0);
  String Pitch = getValue(AllPitch, ':', 1);

  String AllRoll = getValue(split, ',', 1);
  String Roll = getValue(AllRoll, ':', 1);

  String AllYaw = getValue(split, ',', 2);
  String Yaw = getValue(AllYaw, ':', 1);
 
  
  //Serial.println(split); 
  
  float fPitch = getFloat(Pitch);
  float fRoll = getFloat(Roll);
  float fYaw = getFloat(Yaw);


  Serial.print("Pitch:");
  Serial.println(fPitch);
  Serial.print("Roll:");  
  Serial.println(fRoll);
  Serial.print("Yaw:");
  Serial.println(fYaw);
  Serial.println("====================");

  

  delay(30); //wait 5 seconds before connecting again
}

//========== Subroutines ====================

float getFloat(String inputString)
{
   char carray[inputString.length() + 1]; //determine size of the array
   inputString.toCharArray(carray, sizeof(carray)); //put readStringinto an array
 //int n = atoi(carray); //convert the array into an Integer
 float f = atof(carray);
 return f;
}

String getValue(String data, char separator, int index)
{
  int found = 0;
  int strIndex[] = {0, -1};
  int maxIndex = data.length()-1;

  for(int i=0; i<=maxIndex && found<=index; i++){
    if(data.charAt(i)==separator || i==maxIndex){
        found++;
        strIndex[0] = strIndex[1]+1;
        strIndex[1] = (i == maxIndex) ? i+1 : i;
    }
  }

  return found>index ? data.substring(strIndex[0], strIndex[1]) : "";
}


String connectAndRead(){
  //connect to the server

  //Serial.println("connecting...");

  //port 80 is typical of a www page
  if (client.connect(server, 8085)) {
    //Serial.println("connected");
    client.print("GET ");
    client.println(location);
    client.println();

    //Connected - Read the page
    return readPage(); //go and read the output

  }else{
    return "connection failed";
  }

}

String readPage(){
  //read the page, and capture & return everything between '<' and '>'

  stringPos = 0;
  memset( &inString, 0, 32 ); //clear inString memory

  while(true){

    if (client.available()) {
      char c = client.read();

      if (c == '"' ) { // is our begining character
        startRead = true; //Ready to start reading the part 
      }else if(startRead){

        if(c != '}'){ // is our ending character
          inString[stringPos] = c;
          stringPos ++;
        }else{
          //got what we need here! We can disconnect now
          startRead = false;
          client.stop();
          client.flush();
          //Serial.println("inString:");
          //Serial.println(inString);
          return inString;

        }

      }
    }

  }

}

I seem to remember there was a problem with Telemachus back when I was coding this... namely Telemachus would crash and burn if you requested data too quickly. Considering I was only requesting 3 values over a gigabit network I should have been able to access it faster but programs are notorious for doing stuff they shouldn't.

Regarding the choice of motors, I finally decided on steppers over all other different methods. I tried using a continuous rotation server with a resolver to find the position the ball is at, I tried using a motor and optical led locator, I tried using a motor and limit switches... but in the end the KISS principle is ultimately the easiest way to go... So I'm making Prototype 7 an oversize version of the final version to make it easier to access the mechanics and install the motors and wire them up. I also had to order a new ball because I dropped the old one.

There is another fun part to do once the prototype is proven to work... and that is labelling the darn ball itself. I've got the fix in mind already but that is going to be a seperate project in itself.

EDIT:

Hmmmm... just came across this that would definitely make it better. Instead of a fixed time to transmit data you could only transmit when the data changes using "available()".

#include <Ethernet.h>
#include <SPI.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 10, 0, 0, 177 };
byte server[] = { 64, 233, 187, 99 }; // Google

EthernetClient client;

void setup()
{
  Ethernet.begin(mac, ip);
  Serial.begin(9600);

  delay(1000);

  Serial.println("connecting...");

  if (client.connect(server, 80)) {
    Serial.println("connected");
    client.println("GET /search?q=arduino HTTP/1.0");
    client.println();
  } else {
    Serial.println("connection failed");
  }
}

void loop()
{
  if (client.available()) {
    char c = client.read();
    Serial.print(c);
  }

  if (!client.connected()) {
    Serial.println();
    Serial.println("disconnecting.");
    client.stop();
    for(;;)
      ;
  }
}

https://www.arduino.cc/en/Reference/ClientAvailable

 

Edited July 8, 2017 by NeoMorph

[Dr.Vulpinus]

Wow NeoMorph!  That is quite the setup you have!  I have been trying to figure out how those navballs worked for quite some time, but I have never been able to figure it out.  I would suggest kRPC is the way to go, I am familiar with C# and I used it to send data using USB serial before.

Also, I saw in your previous posts  about trying to machine the navball on a CNC and the massive hassle that will be. Why not 3D print?  You could even print the lines into the ball and then just paint in them to highlight them.

Keep up the great work!

[NeoMorph]

Wahoooo... finally got Krpc running and wanging data over to one of my Arduinos today. Then I got sidetracked fixing an LCD 20x4 display with a busted backlight (I just want the LCD to monitor the values being sent over to the arduino to verify).

Really feeling great now I can at least see two sides of this project linking up for the first time in 4 years. 

Oh and for those who eventually want to build their own I will be posting how to do it yourself (and hopefully get you sucke... errr, fine people... to improve it).

KSP has given me hours, no WEEKS of fun... I just want to see how far we can push it. Now who's going to make a DSKY linked to kOS? 

Edited July 8, 2017 by NeoMorph

[NeoMorph]

I've decided that until I get this project running I will be doing a post every Sunday evening (if my disability lets me).

9th July 2017

So what have I done this week... well, a lot actually. I managed to finally get data from KSP into one of the motors I will be using for my 16cm model. To say I was happy when the servo turned when the navball did was an understatement. 

So now it's time to start work on the full 16cm model. First it will be the  main axes and getting them right followed by the 3 error needles and 3 outer rate needles. The  production blueprints for the final version will be made based on a 12cm ball and general made out of the lowest cost parts I can get working but to make it easier to test I'm building this one a little oversized (cramming everything into a 12cm one right away is probably what led to Prototype 6 bursting into flames... well maybe not flames but lots of smoke heh. 

It would be simple to make a navball that works but costs £500 but I want it to be buildable by anyone. Granted the research on this project probably has cost me more than £500 since 2013 but I've enjoyed myself along the way. I've gone from not knowing how they got the real nav ball working to pretty much understanding everything about it now... well except the math... oh god... THAT MATH!... Euler error rates sounds like something an American football team does when they drop the ball a lot.

So what have I bought for this project over the years? This photo below is a small collection of bits that I'm currently using to build Prototype 7. The clear plastic ball is what it eventually will be built around.

 

Yikes... that's a bunch of parts for one Navball!

 

One thing that has amazed me is that my final sim will probably be running on 5 separate voltages.

• 220v ac for the the computer, display and power supply to the sim
• 24v dc for the motors driving the ball (this still might change down to 12v).
• 12v dc for the Arduinos (yes multiple but only one for the FDAI navball), indicator lights and control systems.
• 5v Warning and fault generation system, switch arrays (powered by USB from the computer).
• 3.3v for the pro-mini Arduino that will be handling the error and rate needles in the nav ball

I do know I aimed big and several times down the road I thought it was going to beat me... but thanks to Chinese parts (and of course eBay) I think I'm on the final lap. And yeah, hopefully I will be drawing up plans so you can make your own... and sadly, no, I won't be making and selling them.

Thats all for this week. Keep the faith... this WILL be done.