Hempstead

While the other half of mold is being printed.... Got a new idea. The original idea was to print a negative mold of the shaft, then take a woven carbon fiber sleeve, stick it inside (3 layers, I think)... and epoxy up, put on release film, and absorption mat, and outer plastic tube bag through the middle, fold back and wrap around outside of the whole mold... then vacuum/seal. Sure, theoretically it will work... it's just that... practically, that OD=1" - 0.4mm tube is a bit difficult to apply epoxy from the inside and then do all the other things... so the idea was to pre-apply epoxy resin on the fiber sleeve, fold over twice, and epoxy the mold, and do all the other things.... Sure... still a pain. So, what if I print the negative tube inside with the Breakaway material? I just have to adjust the negative tube's diameter to compensate for the thickness of the carbon fiber epoxy layers... Well... the OD will not be precise... But so what? Wrap some tennis racket anti-slip tape and then screw it down inside to compress it tight. Or, worse comes to worst, epoxy the whole damned shaft inside the stick body, permanently. Sure, that will make the assembly of other buttons/HAT a big harder... but not impossible. Maybe... I can take the breakaway plug, apply release agent, wrap chopped carbon fiber around, epoxy, then apply release agent on the mold, then screw down... making it a forged carbon fiber composite? Or use woven carbon fiber sleeve still? This way, I have best of the both, accurate OD, and still easy to make. Just have to make sure the infill is not too dense making tear it out a PITA.

Oh… I have Blender… for me, it’s now the new king of mesh based creation, and editing, and much more. I even bought a Wacom tablet specifically for it. Ok, that was my excuse, and I am sticking to it. I don’t think review of scanning methods would help, I keep taps on them anyway. The troubles I am encountering are just typical of the Maker movement… does it work? Sure. But how well does it work? What do you mean? It works, see? These Chinese cloners basically have a similar mentality - quickly make something work to make profits, but do not go through the time consuming and costly validation process to verify how well their products work. To their defense, these are not industrial products… and never advertised as one. They are toys. Perfect for scanning and printing bubble heads. I just didn’t know they would all be this trashy, even from a “big” company. The question is, is it possible to make use of these toys in a manner that is useful to my requirements. No worry, I think I have figured out a way to correct some of distortions and accumulated errors…. theoretically. It’s just that I will have to build a specific scanning rig to help me correct the problems I observed in the manual reverse engineering process. We will see how well that works out, once I received the parts I ordered. There are good reasons why some “real” scanners cost tens of thousands of dollars apiece. But, hey, at least this new scanner finishes the scanning process, unlike my older one which crashed all the time and rarely got me any usable scan. If I succeed in coaxing some accuracy out of the toys, I will let you guys know.

I have decided to try making the control stick shaft with carbon fiber composite. So, I designed a split mold for a woven carbon fiber sleeve with vacuum process. That's half of the mold in the picture with "normal" profile....

These Chinese made scanners are disturbingly inaccurate! The scanned models might look just right, nothing matches when I tried to reverse engineer them manually in Solidworks! Ha! Automated scan to 3D would have GIGO! The angles are here 2 degree off, 3 degree there. My guess is that they have local accuracy, but the accumulated errors add up. They either don’t understand the underlying engineering principle, or they don’t care, or these are consumer grade “toys.” I will have to find some way to inject correct dimensions and angles to “twist” them back to match without introducing too much inaccuracies, i.e. inaccuracies at where it doesn’t matter.

I use this mod. I got so used to it that I use it to control everything on the F16, except HOTAS, rudder, Alt. Hold, and gear up/dn. Even rotaries work quite well. I even fly my DME Arc with it, which requires adjusting the course dial on the HSI frequently. I have the laser pointer on, and the laser only turns on when I hold down the palm button. The palm button activation is necessary, b/c otherwise when the controller is hanging right next to the throttle, it’s quite easy to hit the gear down accidentally. With the new Oculus Pro controller, drilling two holes for running the wire through is quite difficult without fully disassembling the expensive controllers. So, I bought a pair of rubber sleeves for the pro controller and hang them the same way.

The following is a screenshot of decimated first with scanner vendor supplied software, then used Solidworks' ScanTo3D to import. I want the high resolution of the coordinates, not the high resolution of more mesh triangles. Probably could use Blender to decimate and fix the mesh as the in between processing step. Blender is designed to deal with meshes from the start. Solidworks... nope, although it has improved tremendously in the last 10+ years, it's not what it's good at. 50K should be plenty enough (actually way too many already) to use as the basis for reconstruction in solid.

Pico is going to use Raspberry Pi Pico board, just USD$4, Pico W $6. And they are dual core, 133MHz. Most likely I will force it to be Pico W, so it has network ability for configuration, and perhaps communicate with other non-real-time controllers and form a cockpit mgmt system (I have already chosen which system to use, but not telling yet.) The force sensor I chose is about USD$30 apiece. Other parts are mostly 3D printed and off the shelf stuff, like a couple of screws, nuts, etc. The right sized spring is a different story… expensive for quantity of 2. But essentially, it's using springs and force sensors to simulate hydraulic feel. I may ditch the 1st stage spring to simulate the “before contact” spring feel. Total cost, still way cheaper than a motorcycle hydraulic brake assembly I bought for testing.

From my new 3D scanner. Imported into Solidworks, decimated from something like 5.6 million triangles to about 100,000, then converted to mesh model. I still yet to convert it (manually, instead of automated) into a solid. And yes, I do have the other 3 pieces.

One thing to mention so people don't get the wrong expectation. The Hempstick Pico will be designed only for high speed, low latency operations, like the control stick, throttle, and rudder. Unlike the original Hempstick, which was designed for high speed, low latency, but with an eye toward expandability toward all instruments in the cockpit. Hempstick Pico will NOT be designed for general purpose cockpit instrument controls. For instance, most likely it will mandate that all the switches/buttons used require no software debouncer, or have hardware debouncer. That is, if you hook up a toggle switch to be the missile fire button... it might fire 5 missiles at one press instead of just one. I most likely will not implement software debouncer that degrades the latency. For general cockpit controls, like caution panel, steam gauge altimeter, ICP etc.... I am working on something else, like the following video. They will run regular RPis, with full Linux, and something else that I am not telling yet. It may not be RPi4, it most likely will be a fleet of RPi Zero 2 Ws, plus a few RPi 4s (ICP and the two MFDs use one RPi4, but the caution panel can just do fine with a $15 RPi Zero 2 W.). In other words, Hempstick Pico will not be a pig that does everything badly. The other one will be the pig.

Nah... the hydraulic feel is slightly different from simple spring. The first part is the simple spring... then, when it hits, i.e. the brake pads contact the rotor, it then becomes similar to force sensor, but not quite. A pure force sensor would be like hitting a hard surface... abrupt stop. But it's really like it gradually switching to a very short stroke strong spring, like the hydraulic hoses would expand slightly, so the piston will go slightly in a tiny bit. Now, this tiny bit then gets amplified by the level length of the brake pedal... so, it's not exactly a strong spring, nor is it a straight force sensor / load cell... So, I plan to simulate it with a force sensor, but with a strong 40lbs 1" spring (paid an arm and a leg for the low volume to Lee Springs). Then, perhaps I will add a longer stroke, but much weaker spring to simulate the "before" stroke. It's not a high priority task... because DCS's F-16 brake is a bit crappy... does it even have differential brake? I couldn't tell. Plus.... the toe brake part of F-16 is a low priority thing to begin with... so, it has a low priority of low priority ranking on my job list.

In case you have never seen it. This is my RudderCore prototype. Please note that I no longer use the central pivot bar (requiring CNC milling, but could be made by hand if you are very skillful). The pedals are bronze casting. I made it myself with the tried and true Lost Wax process. Why bronze? Well... I took some bronze casting class at a local arts institute. Artists do bronze... they don't do aluminum. Since this thing will fly at exactly 0 agl... weight isn't a consideration at all. The motor on top is an industrial servo motor serving as my "force generator." That motor itself is something like USD$400+, and there is a USD $150+ power supply (not shown). Except the pedals, all of the parts can be bought or made at home with just some simple hand tools and some basic machinery, like an el cheapo drill press.... but some would benefit with a milling machine (for instance, the central bar with motor mount... you could made it one piece by jig saw for hours, or you can mill it, or you can make it out of two pieces and bolt them together). The anti-torque rail mount... there is one part that would be a bit difficult to make by hand, but if you are patient, you can just use a hand file instead of a milling machine (maybe 10 minutes filing apiece would do it; you need two). What's missing are: 1. the Hempstick Pico to read the hall sensor and then drive the motor accordingly. 2. My design of force sensor... for the toe brakes. I have the design, and some prototype parts, but not completely done yet... some modifications still needed. Why force sensors on toe brakes? Well... to simulate the feel of hydraulic, of course... kinda... I bought some hydraulic brake assembly for motorcycles... didn't like the heavy heavy sticktion at all.

Well, in that case. I will answer both. Yes. I bought a Bodnar board years ago. I found it….. average. 1. 12 bit ADC. Pretty much every MCU made after 2010 have 12bit ADC(s), if it has one at all. So, unless you are using already outdated MCU when Arduino was first designed…. You’d have 12bit. So stay away from those Arduino boards using AT90xxx or ATMegaxxx MCUs. 2. Not a clue what the sampling rate is, advertised or real. 3. no provision to do MLX hall sensors, or anything like that. You can only do analog ADC at your native ADC resolution. 4. no possibility to do force sensor…. my way. The last two are the killer that drove me to write my own. Arguably, I never achieve #3 fully with the original Hempstick, but I did the configurable oversampling to go up to 16 bit. I did have a partial MLX90333 digital mode code, but lost that in an HDD crash. #4… I never started. Not that I had a design to test on at that time. But, now I have 2, rudder, and stick. Hence, the idea of Hempstick Pico to do it all. Also, Bodnar board is a general purpose joystick board. It’s market is in general purpose joysticks. It does not do anything special like, read a TI Delta-Sigma ADC, which is hooked up to two force sensors for toe brakes. Even though it later tried to be a bit more modular and expands its market to load cell boards, it’s still a general purpose load cell module. I chose that TI chip to drive the specific force sensor I chose. It’s not possible for Bodnar to anticipate. That is, if you want to go off the beaten paths, you have no choice but to do it yourself. But, if you are staying on the trodden paths others have already gone before, Bodnar board is a good choice. It works for what it’s designed for, general purpose joystick, and it works well for that. It’s just that I am not doing any run of the mill thing at all! Now, look at what I have shown you from the RudderCore, to the stick base 2, to the faux F-16 stick, to the optical sensors, to the Hall Mini Stick, which one is on the beaten path? Which joystick firmware is capable of using force generation to create force curve (think electronically programmable CAM, instead of mechanical CAM pioneered by Milan; and I have ideas that go beyond just simple CAMs). There is just no such thing in existent…. I have no choice but to write it myself. Ask yourself this question, do you design something that a Bodnar board can’t do? If not, then use a Bodnar board. If yes, consider modifying an Arduino joystick firmware. Suck as they are from a software engineering PoV, they do work! The question is how well do they work? Well, if you don’t know how well “what” work, then it doesn’t matter to you anyway. No offense, if you want to use an external ADC to get higher resolution, which Bodnar board can’t do. Then you got one question and one solution you can ask that dreadful question. If you care about stable sampling rate, then ask how an Arduino busy loop can satisfy that. Don’t wait for the Hempstick Pico. Even I have no idea when. Could be years.

I have no intention of being compatible with anybody's interface, and be bound by their old rationale. I don't even intend to make money out of it... so no marketecture considerations of being compatible with anybody's stick or base either! For instance, if I put an RPi Pico in the stick body, I don't even need an electrical interface (ok.. maybe I will put in an SPI plug to read the Hall sensor and another plug for the force generation, just so you can unplug the stick and put in another stick shape). The stick has its own USB connector(s). But, remember that the stick has up to 30 buttons/switches, plus 2 axes. And I have provision for force generation. I would need at least 4x cascaded shift register chips if I went that way.... not exactly compatible with TM's interface either (not that incompatible... pin compatible, but not software compatible, just program it to do 32 instead of 24 bits). Anyway, even an RPi Pico does not have enough pins.... you might notice. What if I put two RPI Picos in there? Running as two separate USB controllers? DCS wouldn't mind. Says who there can be only one? The corporate bean counters might balk at the idea of two MCUs... I ain't got no bean counters. It was actually funny... When RPi Pico first came out... I was like... OMG... this is like custom designed as the new Hempstick! Except... damn... two pins short! Damn it! So close, yet so far! So, I spend a couple of days studying the MCU spec., the PCB design... trying to squeeze out two more GPIO pins. And one day... I had to slap my own forehead... doh... just stick two RPi Picos in there... done! Now that I came out of the stupid loop.... with n > 1 Picos... I am free to add more switches/buttons. Hey... each Pico board is only USD $4! Even one of my optical sensor costs about that much, let alone I have up to 30 of them in there! Negligible! I might use Pico W... $6. Maybe I will put there Picos in there. Two in the stick body taking care of all the buttons and switches... and one in the base to take care of just the Hall sensor and the force generation. You know, a bit more modular. No more wires going through the stick! Makes my life simpler! What TM PS2 connector interface? Ha! I count 21 pins in the real F16 stick connector.

Shift register is a good alternative to the matrix circuit, which I personally think is a better solution than matrix although others might disagree. But, remember, the shift register and matrix circuits are “solutions” to the problem that you don’t have enough GPIO pins on the MCU. Both are great solutions to the problem. But, why use them if you have enough GPIO pins? It would be wagging the dog! Why apply the solution when the problem does not exist? Ok… there is the number of wires to route. But, the real ones could do it, so could I. Challenge accepted! BTW, I have about 100 of those shift register chips in one of my part bins.

Well.... that's an idea!

I have been working on the stick base 2's sliding mechanism prototype... time consuming... because I had to adjust the depth of bearing seats.... by experiments (the CAD calculation... using geometry to constraint it didn't work quite well; Call me old school... I was trained in drafting class, yes, with pencils, to use construction lines to constraint my final constructs.). That is... print it... test it, adjust, print, test... Luckily, I can just slice up to only a section of 0.5" high ring for the body and print just that to test. Still each section takes about 4 hours to print... That alone consumed the past few days, ran through one spool of PLA filament. Now... Tada! It works beautifully as I expected. This is the design that allows zero dead center, no sticktion (practically). It's inspired by TM Warthog's these two problems. That is... I set out to solve these two problem, and several years later, I proved I solved the problems! Now I have to solve the 25 wires routing problem and the anti-torque problem. Currently, I am inclined for an external solution. Yes... I had reserved some space for the wires to to through internally, but it's very little space. it's a ring shape of space of only 1 mm to 1.5 mm wide. I could get it through with 30 gauge wires, but what I worry about is the still-to-be-patented linear curve restoration mechanism will have moving part around that ring space for wires.... that could cause pinching and chaffing.... Oh, no... not on F-16! Some cosmic poetic justice thing? It's uglier to have external solutions.... but maybe, just maybe I can make it not so u.g.l.y. BTW the main body in the picture is split into 4 pieces... it could be two... but I split it into 3. The top piece that ring under the stainless steel was a printing mistake... the filament got stuck so that piece wasn't printed correctly. I just slice that part up and print it. That's one of the great things about switching to the 3 to 6 long screws to assemble the main body, I am free to split the main body to any # of piece >= 2. 3 is great because 1. it split along the original aluminum cover lines, and 2. it makes assembling the bearing and bearing tensioning blocks a whole lot easier than unibody. (think if it were a unibody... the main sliding tube has no choice but to go in from the top... and what about the bearings and tensioning blocks that are deep inside that main cavity... very tricky to assemble!). Also, the mechanism does not have to be this long (the main tube is about 4.5" long). But the longer the better... i.e. the long it is... the less dead center, which is the problem with TM Warthog, the center "piston" spring platform has to tilt slightly to avoid the corners of the 4x steel rods from binding, about 1" long. My design won't bind because I use ball bearings to solve this binding problem. But still, the shorter it is, the more "physical slack" due to manufacturing/tuning imprecision will be amplified. My "guess" is that it has to be at least 2" long, if not 2.5". My original design was indeed 2.5" long. But one day, it hit me... why don't I just stick this thing into an F-16 stick base, which I already have a 3D model? Ok... make it as long as that thing would take! 4.5" it is.

No problem…. We all forgot to plug in the power once or twice. Since you are new… the other thing DCS is really “surprising” to new comers is that it will detect all the analog axes for all the controllers you plug in and assign the roll pitch yaw to all of them…. Yes… yaw will have multiple analog axes from multiple controllers assigned to it. Same goes to pitch and roll. So, you “might” have to clear all of them out, manually and then assign just one you want. Otherwise, you might get into situation where you pull on your P51, and it also roll left violently and crash, or sone weird input coming out of nowhere, The kicker is… if you plug in any new controller in the future, it will be detected, and its analog axes assigned to roll pitch yaw again, for all your planes. Hence, you will have to clear that new controller’s analog axes again….. for all your planes.

I am assuming that you have "Allowed access to Data", and activated the Quest Link. And you are launching DCS from the 2D Desktop in VR from your description. First, make sure you have in the Oculus software on desk, go to [Settings] (on the left pane) -> [General] -> Check [Unknown Sources] Second, in the DCS [Settings] -> [VR] tab, make sure you have VR turned on.

A slip of a fat finger... made the socket head screw size M2 instead of M3... oh well... nothing a little drilling and a 1/4" end mill on a drill press couldn't fix. Fixed in the model now. Trigger now works perfectly... no interference anymore. Just sand off the flashing and install. Don't have the right length M3 socket head stainless steel screws... Needs something like M3x0.5x34... odd length. I'd need to cut it down anyway... so I use some M3x0.5x50 I have at hand, and cut off/grind. One piece print will probably work fine. However, there will be two problems. 1. On an FDM printer, you get stronger body, you don't want to print this whole thing up right due to the weakness of the layers. If you print it horizontally, you get ugly underside... that will require a lot of sanding/filing works to restore. 2. Putting the center reinforcement aluminum main tube will be difficult. But, it's possible to slip in 1/2 of the tube only on the bottom halve (that's intentional... when I made that one curvature to two straight lines plus one constant radius... in case I want this option). But even if you choose this weaker option, you will need some way to fasten the tube to the main body. This usually means at least two screws, unless you are thinking about gluing. But splitting into two halves, I also needs two screws, and it's stronger than the "half measure." Other than the visible split line, I see all positives for splitting over unibody. So, I think the splits here is the best option -- left half, right half, and top cover. Makes it easy to install and assemble, and easy to make. Plus, if one day I decide to bronze or aluminum cast these... the existing two halves make it a breeze to make the wax pattern, pretty much as is with some minor fixes. Or... instead of using lost wax casting... I can actually do a lost PLA casting... (lost PLA works great, and all I have to do is to plug up the 4 screw holes and glue them together for investment).

null

nullCorrected some of those aforementioned problems... split the palm rest in two, exported and the merged the main body.... both left hand sides of course. Why? Why not just merge then split, instead of split the palm rest, export to another file and then merged back? Simple... this last split of the palm rest is meant to be the last operation. So, if I ever regret it, I could still go back to the original idea of the main body is pretty much a straight tube with a bulge on top (no split), suitable for a woven Kevlar sleeve to encapsulate, and then epoxy and vacuum bagged. With that bulky irregular shape of the palm rest at the bottom the Kevlar sleeve would have trouble. Hence, the bottom of the main body is straight, and the palm rest could be slipped up and screwed down. Since the current experiment is to split the main stick into three pieces just like Warthog does and forego the Kevlar sleeve with just the plastic 3D printed body with an OD=1" aluminum tube inside to reinforce, there is no reason for me to still have that separate palm rest piece... BTW, I am printing with PLA... the easiest to print, and it seems to be plenty strong enough. I can assure you that after sanding/filing, Smooth-On XTC-3D, and more sanding, PLA could be actually quite beautify and smooth. Moreover, after priming and painting, you wouldn't be able to tell anyway.

Needs a few minor adjustments, a little filing and sanding to get them to fit, mainly the tigger opening obstructed a little bit of the trigger movement. Also, the opening for the mil spec. genuine trigger is slightly too narrow (didn't quite account for the filament thickness...). A little sanding makes it fit perfectly, but I will adjust the 3D mode for these. The whole thing feels quite solid in my hand... not entirely sure if I would need the Kevlar-epoxy outer layer. I mean, it would probably stand by itself... and I also have an inner aluminum main tube for reinforcement... The outer Kevlar-epoxy layer would seem a bit over the top. If that's the case, then there is no reason to split off the palm rest off, since I am already splitting the main body into two for easy installation of the main tube. Might as well integrate the palm rest with the main tube, just like Cougar and Warthog, and then bolt the two halves together with some socket head M3 screws. Also, found there is not much space between the head, the main tube, and the trigger to run the wires... have to design some "spaces" for the wires to route through into the main tube. null

The whole stack test fit. No optical sensor soldered on yet. Because, they are expensive, and 16 of them! Not going to solder on until the whole thing is test fitted correctly. Moreover, likely I will have to file some slots in the PCBs for running wires (and cut out on the next revision of the PCB). null