Here is two short videos to demonstrate how stick input are mixed with RCHome. The first video show ailerons differential with two servos. Differential rate is approximately 40%. Servos moves in opposite direction:
Next videos shows a snap flap mix, elevator to ailerons. When pulling the elevator, both ailerons servos moves in the same direction:
29 janvier 2009
27 janvier 2009
Mixers& settings
Now the main part of mixers/settings/tuning logic is coded, but not tested. All settings currently are changed in the PC, and then downloaded in the radio. This is the second version of the sofware. It should still fit in the Atmega168, provided not too many settings are configured. I tried to put as few as possible limitations in the software, to allow any number of mixing and tunings. The first tests should give a better idea of the performances and if more tuning is needed. This is going to be interesting !
13 janvier 2009
Radio settings & programming
I had the opportunity to get in hands several types of RC transmitter. Most of them share a common approach to enter the model settings: they use menus which provide functions with sometimes obscure names like AFR, ATV, snapflap, differential,... lot of abbreviations which may be not also in your native language. As long as you understand what each function and its potential side effects is doing, that's ok. But if you don't, be prepared to spend time and have some headache to understand what they are doing. Futaba, JR tend to be more and more obscure and far much too complex for the modeller who wants to fly, not to spend hours to tune the settings of his radio. The more radio are evolving, the more they have tons of functions, the more they become obscure and useless. Look how much time you spend now to program your radio!
Unfortunately, there is no changes in this trend, even with the 2.4Ghz revolution. Futaba, JR looks pretty much the same when it comes to program models. Multiplex has always had a much more open approach which gives flexibility especially to create new settings. There is also new programming way emerging such as the one introduced by the "turborix" by the use of the PC. But it does really changes the way you enter your settings, and the way to tune them.
And these high end radios have still serious lacks: for instance, they do not offer an easy way to set and tune the model while flying (except Multiplex Evos). On Futaba for instance (12Z), you can't automatically store the settings you made while flying. You have to land, remember your new setting, change it in the proper menu, etc...
In today's world of modellers, programming a new model should be straight forward and easy. In fact, when you buy a kit, you should get together a CD with all the model settings already programmed that you just need to apply on your transmitter. It should be also easy customizable, depending how your are used to pilot (mode 1-4, sensitivity, auxiliary positions, etc...)
Radio should also become more and more intelligent, just defining the right setting by themselves without the need of long and boring tuning sceance. Well, it's a bit of a dream, but imagine a radio that can automagically reduce the elevator sensitivity based on your way of flying and movements of elevator stick. Imagine a radio that can avoid a tip stall by automatically reducing the elevator course, etc...
Ok, but stop dreaming. In a first step, I will do a fully customizable model settings in the RCHome project. The goal is not to remake a Radio programming language such as the very good RCCL language, but have a more synthetic approach.
The hardware (AVR 8 bits) will probably limit the number of operations that can be done during mixers computations. But still, after some computations, it still should be possible to make all the various mixes needed. The approach I am using is a bit different from traditional Radio programming, and should be more "visual". By "visual" I means that you won't see on a display a picture of your model with moving surfaces, but have a global functional schema to better understand the various effects on a servo channel. Let's see what it will come out of this. In a first step, I will use the Arduino as it is good enough. Removing the display part will provide a lot of flash and RAM spaces, so that even complex mixers will be possible.
Unfortunately, there is no changes in this trend, even with the 2.4Ghz revolution. Futaba, JR looks pretty much the same when it comes to program models. Multiplex has always had a much more open approach which gives flexibility especially to create new settings. There is also new programming way emerging such as the one introduced by the "turborix" by the use of the PC. But it does really changes the way you enter your settings, and the way to tune them.
And these high end radios have still serious lacks: for instance, they do not offer an easy way to set and tune the model while flying (except Multiplex Evos). On Futaba for instance (12Z), you can't automatically store the settings you made while flying. You have to land, remember your new setting, change it in the proper menu, etc...
In today's world of modellers, programming a new model should be straight forward and easy. In fact, when you buy a kit, you should get together a CD with all the model settings already programmed that you just need to apply on your transmitter. It should be also easy customizable, depending how your are used to pilot (mode 1-4, sensitivity, auxiliary positions, etc...)
Radio should also become more and more intelligent, just defining the right setting by themselves without the need of long and boring tuning sceance. Well, it's a bit of a dream, but imagine a radio that can automagically reduce the elevator sensitivity based on your way of flying and movements of elevator stick. Imagine a radio that can avoid a tip stall by automatically reducing the elevator course, etc...
Ok, but stop dreaming. In a first step, I will do a fully customizable model settings in the RCHome project. The goal is not to remake a Radio programming language such as the very good RCCL language, but have a more synthetic approach.
The hardware (AVR 8 bits) will probably limit the number of operations that can be done during mixers computations. But still, after some computations, it still should be possible to make all the various mixes needed. The approach I am using is a bit different from traditional Radio programming, and should be more "visual". By "visual" I means that you won't see on a display a picture of your model with moving surfaces, but have a global functional schema to better understand the various effects on a servo channel. Let's see what it will come out of this. In a first step, I will use the Arduino as it is good enough. Removing the display part will provide a lot of flash and RAM spaces, so that even complex mixers will be possible.
09 janvier 2009
24 décembre 2008
Sticks
Finally I received the sticks. There are from a Futaba FC-18 transmitter. Their price is reasonable (approx 50€ each, dec 2008).
Quality seems good. They are accurate et pretty smooth. Stick have 5k potentiometer, and trim have 10k potentiometer.
Trims can easily be removed from the stick. They are just fix to the stick frame with two screw.
Quality seems good. They are accurate et pretty smooth. Stick have 5k potentiometer, and trim have 10k potentiometer.
Trims can easily be removed from the stick. They are just fix to the stick frame with two screw.
21 décembre 2008
Transmitter box
Sorry for the bad quality, it is still a very early draft.
I intend to make it as ergonomic as possible while keeping it simple. Both side are rounded to be confortable in hands, and below the low cover is embeded leaving some space for fingers.
As you can see, there is no trim. The idea is to use "auto trim" as described by jef raskin who pioneered the human-computer interface at Apple (not less!). The principle of autotrim is simple: move the stick in the position and press the button. Then release the stick. But problem of autotrim is their lack of accuracy when you need small changes. For that, the coding wheel (above the stick) can be used to control the small offsets. It will works like this: first select which trim you want to set, by pressing on of the button (corresponding stick must be released), and then fine tune the trim with the coding wheel. This is fairly simple and should be ergonomic, everything falling under the hand.
Between the sticks, there is the lcd display (The first version will probably have a smaller size than the one presented). The switches below the sticks, and the coding wheel will be input for the lcd. One or several leds above the lcd will monitor the battery status.
I intend to make it as ergonomic as possible while keeping it simple. Both side are rounded to be confortable in hands, and below the low cover is embeded leaving some space for fingers.
As you can see, there is no trim. The idea is to use "auto trim" as described by jef raskin who pioneered the human-computer interface at Apple (not less!). The principle of autotrim is simple: move the stick in the position and press the button. Then release the stick. But problem of autotrim is their lack of accuracy when you need small changes. For that, the coding wheel (above the stick) can be used to control the small offsets. It will works like this: first select which trim you want to set, by pressing on of the button (corresponding stick must be released), and then fine tune the trim with the coding wheel. This is fairly simple and should be ergonomic, everything falling under the hand.
Between the sticks, there is the lcd display (The first version will probably have a smaller size than the one presented). The switches below the sticks, and the coding wheel will be input for the lcd. One or several leds above the lcd will monitor the battery status.
and why not multi-microprocessor ?
After having play just a bit with the AVR32, I am not convinced. This chip looks young, there are not many people developping on it, it is still in an early phase for Atmel, can't found that many examples, it requires the use of an OS like freeRTOS, flashing under USB and linux is a boring, etc...
To stay with simple 8 bits chips, I am thinking to use a multiprocessoir architecture, like mrdunk robot each processor dedicated to its own task, all communicating through i2c. The drawback of this, is that it add more electronic, but the good thing is that it is more flexible, new feature can be added to the transmitter without worried too much about performance and impacts on the other components.
To stay with simple 8 bits chips, I am thinking to use a multiprocessoir architecture, like mrdunk robot each processor dedicated to its own task, all communicating through i2c. The drawback of this, is that it add more electronic, but the good thing is that it is more flexible, new feature can be added to the transmitter without worried too much about performance and impacts on the other components.
Inscription à :
Articles (Atom)
Articles
