[WIP] The REAL Nav Ball Project Thread

[NeoMorph]

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

For those who don't know what this is it is me and a couple of others who are working to get a real KSP nav ball made... but made in the image of the the Apollo Flight Director Attitude Indicator (or FDAI). This will be part of the Hardware Interface Project (HIP) that will encompass ways and means of building real instruments for your KSP sim. I will be releasing EVERYTHING open source so you can rip it apart and change it as long as you give a credit to where it began is all I ask.

So to start... what does the FDAI look like... well it looks like this...

The housing is about six inches high by six inches wide by eight inches deep which gives you some idea how big the thing is. As I don't have space rated engineering tools I think my case is going to be a LITTLE bit bigger.

Working out how the ball worked took a while... until we realised the ball isn't actually a ball at all but instead it is a central stationary disk (stationary in the horizontal axis that is) and a bar through it which is mounted the two hemispheres that make it look like a ball.

So currently I am working on a prototype to check out how it works... Here is a picture of my prototype and how it is bigger than the final version that I have planned. I am using a larger version to prototype with so that it is easier to work with. The smaller ball on the left is what the final hardware will have to squeeze into. I will be using different gears for that.

The size of the motors which drive the axis from inside the ball are tiny for what they move... but with the miniature gearbox they have quite a lot of torque for their size. They are rated at 12v but they even move the sphere with no problems at 3v.

For further info on my blog go to http://forum.kerbalspaceprogram.com/entry.php/936-Hardware-Interface-Project-%28HIP%29 - From now on I will be posting updates on here and include more detail in the blog itself.

Hope you like it...

Edited November 5, 2013 by NeoMorph

[NeoMorph]

Yay, forums are back...

Well here is a stumper... the core systems in the brains were working flawlessly (and fast)... but for some reason the motor controlling the sphere axis keeps cutting out. I don't know what is doiing this but I need to find out what is causing it pronto.

I've just ordered some new stepper motors to try out. Hopefully they will fit into the new smaller sphere and have a more reliable state.

[KhaosCorp]

You know you can get a powered navball from avionics supply. Can't say I have ever priced one, but it may be worth looking into. Then you would only have to figure hot to take input from ksp. Just a thought =)

[NeoMorph]

Yup... but that would only have two axes of movement. The Apollo/KSP nav ball has three which makes it a challenge.

This is what a normal avionics nav ball looks inside...

Notice that the ball is mounted in the C clamp in a left/right config. In an Apollo/KSP nav ball the C clamp holds a fixed disk in the up/down configuration and then has an extra axis added by going through the centre of the disk and then a hemisphere added either side of the disk.

It was that third axis that really stumped me for a long while.

So as you can see, they are built quite differently. It's like comparing a Car to an Aeroplane in fact.

[regex]

This is a much better choice for updates, thanks. I've been silently following your progress and I am very impressed.

[NeoMorph]

I've also ordered some new adafruit stepper controllver boards (the V2 model) that runs on I2C which means that instead of my distributed system (needing more than one arduino) I can actually run the whole instrument panel off of one. The option to run it from extra arduino's is still possible so if running too many meters, gauges and indicators slows the system down I can still expand as needs be. In fact the one part of the project (the DSKY) will need a dedicated system but will still link to the central brain board.

This means that the system will still only need one lan cable to connect to the system. It will be cool when it is finished to link to someone in another country and watch their ship control my instruments.

[Specialist290]

Well, this certainly looks interesting. Hope all goes well.

[NeoMorph]

Project has now been screwed by Apple... iOS 7 came out the other day and totally trashed my project planning App on my iPad. I was making do with the iPhone version but that crashed as well tonight. All the details of what I had planned and my ideas are now stuck in a file and the App just crashes when you start it. The mobile App (iPhone) does the same thing but that throws up an "Auto Recovery" dialogue that gives me a choice of saving my work or cancelling. Hit save... crash to desktop. Hit Cancel and what do we get.... crash to desktop.

Ugh!

The company that makes the App say they are working on a fix but for now I'm stuck trying to remember what I was supposed to be doing and all the project notes are stuck in the file lol. Oh and to top it off I blew up one of my arduinos today when a wire came loose from the 12v PSU and shorted the main board out. I bought spares so have about 9 more Unos and a couple of Mega 2560's to work with.

[tom1499]

-Bad Stuff-

Once again Apple ruins the world. (I don't like Apple) Shame about that short too. Been following this project since the start, keep it up!

[NeoMorph]

Well good news... I will be building a new test rig this weekend after my new V2 motor drivers from AdaFruit arrived this evening.

Adafruit Motor Shield V2 for Arduino - Each daughterboard controls 2 stepper motors which is why I need two daughterboards (for the 3 Axis)

As it runs on I2C it means that the input/outputs of the Arduino are fully free to be used for other things, like the various indicators I will have on the Nav Ball. The needles for the pitch, roll and yaw (error from selected angle and rate levels) will be controlled by another I2C board by AdaFruit... the 16 channel Servo Controller Board.

Adafruit 16-Channel Servo Driver for Arduino - Each servo can drive a single meter

This will control the 6 needles for the Nav Ball and will have another 10 outputs that I can use for other meters such as fuel levels, battery power left etc.

THIS WILL BE A OPEN-SOURCE "FREE TO ANYONE" DESIGN

Once I find a control system I am happy with I will finalise the design for the nav ball's hardware. Up to now I have gotten systems working but haven't been fully happy with the performance. I will also need to work out a foolproof calibration and holding system. Once that is all done along with the software to drive it and then it will be made available to the community... free of charge. You will be able to make your own and improve on my design. My only limit is to not sell the stuff for a profit. This should be a community project.

The whole purpose of using readily available Arduino boards is to reduce the need to buy more expensive purpose build boards. I'm talking about what has happened in the Flight Sim Community. There is a whole bunch of snobbish players who pay ridiculous sums for their system and look down on those who try to make their sim on a budget. I remember talking about using recycled materials and was pretty much shunned by this one site lol.

Now ready built boards are fine but if you want to expand on what you have and include custom hardware/software then it is a bit harder to do, let alone there being only a minimal number of suppliers selling the things. The philosophy behind my system is that you can readily expand the system. You could easily have 50+ meters attached to this current system. The only custom PCB I will be making is the rotary contact that is necessary for connecting wires to a rotating object.

Rotational Contact Plate... AKA Record Player

I've still not decided on whether to have the brains on a Mega or a plain Uno. The Mega has better memory and more outputs so that is tempting... but I am wondering if I will just make this Nav Ball system on a Uno to see if it will run on a cheap microprocessor.

If I could tell you guys how much money I had already spent on this project, getting parts from all over the world, I think your jaws would drop. Still, it's actually fun trying to do something other people have said couldn't be done. And to think I started off only wanting a joystick interface heh.

John (NeoMorph)

[dizzysaurus]

I wish I had more karma to throw your way. This looks amazing and I'm really excited to see the end result!

[Kerba Fett]

That's a very cool project you've got there. Once you get all your mechanicals and interface done, have you considered how you're going to print the markings on the ball?

It seems like you know a thing or two about electronics, perhaps you could interface the navball with an inkjet printer. You pull the signal from the stepper motors on the printer and feed it to the navball controller. You mount the printhead just over the ball and print an image. The printer thinks it's moving the printhead over a piece of paper while it's actually moving the ball under the print head. It would probably take a lot of trial and error to get the programming right, but other than hand painting it I'm not sure how else do do a sphere or hemisphere. If you spray the ball with a nice flat white primer to prep it, you could probably do a nice full color print with some work.

By the way, I recognize those plastic balls. They make great ROV housings. As thin as they are they can go to 200' underwater without collapsing or leaking. (if you run a bead of silicone over the joint)

[NeoMorph]

I've got one idea....

It's called the eggbot... in this case it is the ostrich eggbot as I want to make bigger versions as well.

To get the markings I will paint the item in the base colours... ie black and white as it is an Apollo version or maybe the orange and blue for a terrestrial version like KSP is currently using (they made the mistake of looking at airplane attitude indicatiors). I then paint over the black and white sphere with masking paint and then put it into the Eggbot with an engraving bit instead of a pen. I then draw all the markings on the sphere. I then spray paint the markings by covering the whole sphere black and white (but the opposite to the base.. ie the black side I will paint white while the white side I will paint black.

Now comes the tricky bit. While the paint is slightly tacky I gently tease the masking paint layer away... leaving the paint markings behind. Black markings on white and vice versa.

An alternative method is going to be making the ball in quarters on a 3D printing machine. I have one KSP guy working on the prototype for that as well. It's early days yet but I have seen a test piece he printed off and it looks very nice as the material ends up being a lot tougher than the polycarbonate spheres I was using.

_____________

New Stepper Motor Arrives

I had some good news this morning as well. The new Nema 17 stepper I ordered the other day arrived. So now I have the controller AND the stepper to test. I just need to work out some figures as it is only a 2.8V motor instead of the 12V ones I was using before. I need a better PSU as the 5V one I was testing with was overheating as it was drawing too much current.... BUT IT WORKED GREAT so I will be ordering two more.

Another thing I will have to think about is weight as the motor is rather hefty. I had a sleep this afternoon (as I had been up late into the night working on the design for another part of the system) and came up with a way to both balance the internals AND control both axes. I will try to draw it up later on today and publish the pictures here in the next day or two..

Edit: UGH!... Impulse buy of this stepper may have been a mistake. I was looking for a high torque which means that this thing draws 1.6A per winding. Get two steppers working and it is going to be a possible 4 x 1.6A which means 6.4A which is WAY beyond what the card can handle (it is supposed to handle 3A peak). Looks like this stepper is going towards my CNC unit lol. Oh well, you live and learn.

Edited September 28, 2013 by NeoMorph

[NeoMorph]

Well it's been a LONG hard slog with a LOT of prototypes dropping by the wayside because of one thing or another. I never figured that the inside of the ball would be such a sod to cram everything in and then let me put the ball back together.

The problem was that the motors I required needed more torque to move the weight of the system and not overshoot due to inertia. Unfortunately more weight meant larger motors which meant even MORE weight (bit like the problem when deciding the size of a rocket and the amount of fuel you are going to be using).

I've got some new motors (again) and some new drivers (AGAIN) but now the torque is where I want it and isn't causing the whole thing to overheat and melt the ball (don't ask lol) so that's a good thing.

I still need to get a few more pieces that will let me build the final version (why the hell don't they make a range of gears that have the identical shaft size across all the sizes of gears ffs) but I'm going to be cutting the new chassis parts tomorrow so hopefully I will get a set of images up on here in the next few days (hopefully that is... this project has been murphy's law writ large).

Oh yeah, and strangely enough it was that EggBot above that gave me the idea of how to drive the motors. Turns out the guts of the thing is available as separate drivers which work really well.

This is the the board in question...

Looks huge here but in reality it's about the size of your index finger... My system needs three of the suckers but they are cheap as chips if you get them from China (hehe... pun unintended). Connect them up to power and an arduino which supplies the driving signal and it is fast (which is what I was aiming for). I will be about to spin the globe 360 degrees in less than a second so I think that is going to be quick enough for space travel hehe.

[sal_vager]

About the overshooting, what if there was a brake of some kind to stop the ball?

[NeoMorph]

The overshooting doesn't happen now. I even tried it with a heavily weighted disk to test whether or not it could do it... didn't think it could but WOOOHOOO... it worked perfectly.

The problem is when you move fast the holding torque drops through the floor. Slow it's no problem because A) it's slow and it has high holding torque. It's just when your spacecraft gets into a crazy tumble after a collision and then it hit something and goes from crazy spin to dead stop... that's the overshoot problem that was causing me grief. These new motors I got though have decent torque which helped and the new drivers allow me to microstep at 1/8th rate which lets me have better control. The real trick is to move it into SLOW movement mode and it acts like a really strong braking system. I tried moving the shaft when the brake is on and I couldn't turn it.

The only problem is that I've got to rebuild the central disc to that mounts the two internal motors so that they fit properly... oh and get some new gears because I'm now mounting the lower motor parallel to the Pitch shaft instead of using a bevel drive (basically the mounting area inside the sphere is crazy small for what I am fitting in there).

I'm also still in two minds as to whether to include and auto calibration unit. I think I will probably leave it out until I get a working base prototype that can handle everything I can throw at it. Calibration is pretty easy though.... just throw a switch to "cage" the ball (ie make the ball go to what it THINKS is the 0 Pitch, 0 Roll and 0 Yaw) and then use some rotary encoders to manually turn the ball to the proper position. Then uncage and away we go. Same thing will be used for the Pitch, Roll and Yaw rate needles. That's the easy part thank god. Then there are the error needles which will be done the same way. Still need to figure them out from Telemachus though.

Still, things are progressing.

[NeoMorph]

This is what the nav ball is looking like (this is a view I did to see if I could fit the new motors into the ball without touching the sphere). It's not the final version because I made a few changes since then so I need to remove the thick support circles and replace them with copper plating that is definitely better (looks a bit steampunky atm).

[Patupi]

So it looks like you went for an internal orientation? I'm curious, did you consider external? I know there are some serious drift problems with that arrangement, but it would probably be an awful lot easier to run. Three sets of driver motors, each driving a wheel, and each wheel has small free spinning wheels at right angles to the main drive wheel's axis arranged around it's rim (Think a series of rings threaded onto one big ring). It simply attempts to roll the ball within the drive cage, and when one axis is driving, the small freespinning wheels allow it to spin in those directions. IE the 'big ring' is the driver, and the small series of rings free rotate.

Problems with that are that errors creep in fairly rapidly due to mismatch on the friction with the ball. You could make some sort of internal reference, maybe a magnetic system, that could check it's current orientation and correct the software I guess.

Just curious to see how this was developed.

[automcdonough]

i think you are taking the wrong approach on this, and that it can be mechanically less complicated.

consider a globe sitting on 3 caster wheels. yes the wheels themselves would all need 2 motors, but they would all be stationary in the base.

[FenrirWolf]

I'm guessing he wants to avoid gimbal lock or something.

[Patupi]

That was something similar to what I was suggesting, but as I said there are problems with that approach. Solveable, yes, but I'm not sure how difficult what he's doing is. Might be this is easier overall.

[automcdonough]

It occurred to me that instead of 3 wheels acting as casters it could be 3 simple rollers with 1 motor each. Kind of like how a mousewheel works, but there needs to be 3 for rotation as well. The trick is the ball itself has to be hard enough to slide on the roller when it's going perpendicular to it's rolling direction.

edit:

no looks like 2 and a turntable..

Edited November 8, 2013 by automcdonough

[automcdonough]

this method would require a way to calibrate itself though. perhaps a mark on the ball that it homes to. The more I think about this, the more I can see the merits of staying on your current path.

do you have any intention of marking the prograde/retrograde on it? This seems like a difficult idea. maybe a light screen in front of the ball? aim laser pointers at the face of it? mechanical crosshairs?

I'm not trying to derail your effort here, but I think if it were me I would consider 2 options:

1. Just use a dedicated LCD screen buried in there. perhaps even with a globe face + mini projector setup. I don't consider it a cop-out, modern and future craft are not likely to use heavy mechanical things for this. Plus marking targets, prograde, etc is cake.

2. use the normal avionics, the compass orientation would be a separate gauge next to it. This is a little bit of a copout but could make displaying additional information such as prograde much easier.

what's the main purpose here?

Edited November 8, 2013 by automcdonough

[Patupi]

It occurred to me that instead of 3 wheels acting as casters it could be 3 simple rollers with 1 motor each. Kind of like how a mousewheel works, but there needs to be 3 for rotation as well. The trick is the ball itself has to be hard enough to slide on the roller when it's going perpendicular to it's rolling direction.

edit:

no looks like 2 and a turntable..

The problem with this is if more than one axis is moving at one time the 'slide on the roller' bit is going to stop that roller from being able to roll the ball on it's axis well. That's why I was suggesting using rings with freewheeling runners on their rim. Motion around the main ring would be from the drive on that ring. Movement perpendicular to that would be free and driven by the other two axis rings. Of course this is making things way more complicated.

[NeoMorph]

automcdonough, basically all your suggestions were things I thought about at the beginning of the design process and discarded because they just wouldn't work... and then I found this graphic from the Apollo manuals that showed this method of driving the ball...

My design is a complete ripoff of this Apollo design.... been a few hiccups (err... understatement there) but it's good now.

Actually the node indicators are going to be linked to the error needles like how Apollo did it in real life. Working out how to link the data to the needles was the first thing I actually got working. In fact 95% of the design I am using is what is in the real thing so I've just had to adapt for what hardware I could lay my hands on. Using wheels like an upside down mouse would have so much drift and lack of calibration lock that it would be next hopeless and would have needed cleaning a lot and would have eventually stripped the paint off the ball due to drag.

The current design I am using is solid. One of the test models I have built has ran for over 6 hours with a capsule tumbling in space (went to bed and left it too it heh)... when I tested for calibration when I woke up I found that all but the roll was still spot on. The roll problem was just due to a overbind on the gearing (ie the gears were pushed together too much). What is even cooler is that the ball was linked to my LAN in the living room and KSP was running on my PC in the bedroom. Using the Arduino LAN adapter has been easier than I thought.

I haven't done any more work on the current build in the last week because I am waiting for some specially cut gears as I'm replacing the plastic ones with metal for the final prototype now. Should turn out ok (I hope lol). I'm going to leave the current ball transparent so that others can see the innards working when I get around to doing a video.

To be honest, what I really need is a CNC machine to make cutting my parts easier and more accurate. One plate that I cut and spent ages on looked perfect but the one motor mounting hole was off about a degree and it meant that the motor was straining at the gear meshing (which is what messed up the roll data as it caused slip). As the motors are using 1/8th stepping it means I have got 1600 steps per revolution so it's a slow creep of losing one step every few rev due to friction... but it adds up. Re- zeroing was easy though.

Still lots of work to do... Got to work out the final painting method that I am going to do the sphere surface with. I'm going to get the eggbot and do some mods so that it will handle an engraver bit better and have a better pen up/down method that the floppy arm they currently use.

Oh and my new Xbox will be arriving in a couple of weeks so I can see that eating into my building time too... I know it's not as powerful as the PS4 but I just can't handle Sony controller layouts and Xbox has all the exclusives I want (Titanfall, Quantum Break, Halo, Forza etc). Japanese games feel weird to me (like Metal Gear Solid games... the voice acting is like they are on some real heavy psychedelic drugs or something).

I'm not giving up on this Nav Ball project. In fact it has already let me design my flight simulator artificial horizons (which are easier to make than the Space versions as they only have two axis).