Progress on MKIV cyclic base

This gimbal takes the best from the MKIII reinforced model and adds even more strength and precision along with some usability improvements!

The device has 3 Ethernet sockets – 2 for I2C bus connections (one for the grip and one for the base – no more cable with a plug) and one for FTCR button. The weight of a new base totals at 2,12 kg! It can be mounted to the GUNDE chair onto the same rail as before, but it needs to be reversed as shown on the picture below. The master controller will be moved to a more convenient place.

It will be released fairly soon after some testing will be done. Meanwhile, you can try it as well – MKIII assemble guide can be used as a reference until the new one will be posted. Note that you will need 18x8x6mm threaded hubs.

MK IV collective base is now available for testing

Finally, Mark IV base files are available for download! Assembly manual will be posted with its release, which will happen quite soon.

All major stuff was tested and should fit together nicely at this point, so we can call it a release candidate. For now, you can use MKIII software with it. Later, some cool new features like mode switch, MCU reset button, and easy flashing support will be added. The base is compatible with all MKIII levers.

2 * 18mm long 6x8mm threaded hubs are needed to assemble it.


Thoughts on Mark IV controller

Guys, I would like to hear your opinion. I’ve been thinking of a way to go past the memory limitations of Leonardo board, while continuing using the Joystick library, that really helps to keep code simpler.

In the previous post, I’ve shared some ideas on the 1st MK4 device, the simple collective. One guy asked me about motion platform compatibility, and I’ve decided to make a lever, designed for use with one. That means no counterweight – and thus the lever needs to be compact and lightweight, so no heavy head.

With this in mind, I decided to modify the base and introduced a pedestal – a small panel on the top of the lever that can be used to place some switches and other stuff, like the radio panel. The cool thing, the mount is standard and allows for mounting pretty much anything you want there (as long as it doesn’t interfere with comfortably placing your hand onto the lever)!

That means, to keep things functional and cool, we need a mode switch and some related software magic. Probably, for each of devices! That, in turn, means a lot of code, and looking at the current situation, there’s no way to put it into a single Leo board.

Simple colletive with a basic pedestal
Yet another pedestal idea, The ministick can be used to replace a mouse in VR, or smth like that

So, here are few thoughts about what I would like to see in MK IV controller:

  • 3 independent Leo boards: one for collective, one for cyclic and pedals, one for miscellaneous stuff
  • flashing peripherals from the controller (integrated USB-UART board and a separate RJ-45 socket for flashing)
  • modular design – user manually chooses devices he wants to include in the configuration tab
  • built-in USB hub

I would like to hear your thoughts on this and what else can be added / changed to make it better!

Mark IV is coming!

As you guys probably noticed, there’s been only a fairly moderate number of updates lately. And that’s because I’ve been actively working on the 4th generation of devices!

We will actually see the first one quite soon – here’s the new compact collective lever!

I ‘ve been wanting to resurrect an early MKIII model of the simple lever for a while now – for those of us who just want something reasonably compact and inexpensive, yet precise and functional. It features 2 pushbuttons and a 2-way spring-loaded switch – you can operate a starter, throttle latch and a governor with these. It may also receive a mode switch installed to the base to triple the number of buttons and an MCU reset button for effortless firmware updates.

This lever does not need the pneumatic mod – and that saves a lot of space in your flight cubicle. Otherwise, it’s 1:1 same size as the MKIII single lever.

Every part of the collective was redesigned and improved: 4th gen offers even better precision and durability. Single and twin levers will be updated shortly after the release of the compact one.

Stay tuned!

Huey-style collective mount for IKEA GUNDE chair

For those of you guys who use IKEA GUNDE chair, fly Hueys, or 412, or whatever else has its collective mounted at an angle, here’s a nice lever mount that should place the Simchair one in a way that’s pretty similar to the real thing:

No changes to the lever itself required, just flip the counterweight box to the other side of the lever and move it slightly further down the rail.

As always, you can download files from the repo.


A year of Simchair MKIII

Today it’s been a year since I started this site =)

Because of your continued support and interest, I’ve been able to develop some cool new devices like the VRMax head, and improve existing ones to the point where they are really enjoyable!

Software-wise, we’ve started from the very basic non-i2c firmware and analog controller, and now have some pretty advanced stuff going on under the hood. Actually, we may be quite close to Simchair IV!

Here are some thoughts on what may be happening in the near future:

  • reinforced cyclic gimbal v2 – even better precision, improved stick mount, pneumatics support
  • reinforced collective hinge – with the cyclic gimbal v2 design elements adopted
  • return of the simple collective – for those of you guys who just need a compact and simple, yet good and reliable lever. Will be great for the Rotorway in FFS and Robinsons
  • pedals v2 – stronger frame, pneumatics support, toe brakes mod
  • Bell 206 style collective head
  • donation shop – you will be able to order magnets, springs, buttons, etc from me for a smooth building experience
  • guidelines page – it will help to choose from the variety of mods to create your perfect set of controls
  • simchair_models repo cleanup – I will be merging mods that I use for every lever I make with default models
  • controller upgrade – that will mark the beginning of Simchair IV

Huge thanks to everyone who supported the project, or built Simchair controls by theirselves =) Together, we make helicopter simulation better and accessible to everyone!

Single collective hotfix, reinforced gimbal v2 sketch

I’ve finally tested changes I made to the single collective to fix incorrect M4x80MM screw socket cut length in throttle frame p2. It worked perfectly:

I have also added a modified throttle grip with a texture, somewhat MI-8 style, you can see it on the picture =)

Another cool thing – I have tried to address the only problem of the current reinforced gimbal version – stick frame rotation when mounted under the chair. I have adjusted the structure to fit 2 M8 bolts instead of 1 to connect cyclic lever:

The housing diameter is increased by 15mm. This is just a sketch so far and files WILL be changed, but if you need them, these can be found in “dev” folder under peripherals dir.

An important master controller software bug fix for pedals and some news

Sadly, the more one works on creating and polishing controls, the less time it leaves for actually flying with them. Sometimes I only fly to test another thing I’ve just made and then proceed with other pressing matters at hand. Sometimes when I implement something cool I break something else 😀

I’ve just noticed and fixed an important pedals related bug in force trim – trim position hasn’t been resetting on FTCR button press. Please update the master controller firmware!

For those of you guys who’s interested in creating their own custom cyclic grips with more than 2 hat switches, please look at an example in “dev” folder. Note that with that particular example I chose to use the built-in Arduino read function, though it’s slower than reading registers directly, for the code to look cleaner – as hat pins happen to be connected to different registers.

Those files are in a separate folder because we’re at the limit of what Arduino Leonardo can do. I will be thinking of the best way to resolve it without losing compatibility with current devices.

Some news on latest updates

It’s been a while since the last post, for some reason I thought there was nothing big enough to write about. For the last few weeks, I was mainly busy with fixing minor bugs (like strengthening the throttle latch pin of the physical throttle latch mod), testing and applying improvements to the firmware code kindly offered by Pavel Fueyor (this process is sadly going really slow, and that’s a shame!), and then Connor noticed that there was a bug in the single collective, the M4x80MM screw was too short to reach the nut, pressed into the throttle frame p1. I have at first changed it in the manual and went shopping to buy an M4x100mm screw. Sadly, it turned out to be quite hard to find. That’s why I decided to implement some design changes, which I will release after some testing in a couple of days.

The bug is not super critical, as I have been using my copy of the lever for more than a year now without any issues, (that means, no need in fixing it in existing levers!) but it definitely has to be addressed, so if you’re building the lever right now, might be a good idea to wait for these changes to be applied. Models affected are throttle frame parts 1 and 2, so other stuff will remain untouched.

Looking for a better way to organize project files

Recently I noticed that the project has grown up quite a while since I’ve published it on GitHub and started this site, and thus initially chosen file/folder structure doesn’t work particularly good anymore. The problem is, we have a lot of optional mods, and it’s becoming hard to maintain and also hard for you guys to find what to print for your build. We also have a lot of repeating files: for example, all of the collective levers use the same base. Right now, if I design a better one (like the latest housing with a revision hatch mod), I have to either change it everywhere, in all related assemblies, replace STLs and re-orient them, or just publish it as a mod. The latter is what I actually do more often, as it takes less time to do so.

Now, that gives us a choice, and it’s good, but then a new user needs to know what to choose for his project. That’s why I want to add some “building guidelines” page with suggestions of what parts to choose for various applications.

But, this doesn’t solve the problem completely – we will still have quite a while of duplicated files. The answer may lie in splitting stuff into smaller assemblies – for example, collective levers may be divided into the common base and levers themselves. On the other hand, it’s quite convenient to develop stuff as a separate assembly, to avoid breaking other things.

So, to sum it up, what I want to achieve is:

  • it should be clear what parts are available (this may be achieved by publishing guidelines, but if it can be with some folder structure as well, that would be better)
  • reduce the number of duplicated parts across assemblies, as these parts become outdated and as their number increases become a pain to manage

If you guys have some thoughs and suggestions on this matter, please share!