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.
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.
14 décembre 2008
Next phase: AVR32
I have started to play with the AVR32 chip on the board from alvidi. Well, it is not as easy as arduino board, or AVR 8 bits chips. First, there is no "pure" avr-gcc" available, but a gnu-toolchain version made by Atmel. As I am working under Linux, I used the Linux version. You can forget the simple "PORTB" or "DDRB" register names that are used on AVR8. Names are mostly different ahd hardly understandable. But Atmel provides a software development kit that brings basic libraries for most devices available on the AT32UC3A.
One good thing with this chip, it that it can be flashed directly through USB. It took me some time to find that I should install the "flip-3.2.1" software available on Atmel site to do this job. But there is still a problem: this software is not up to date for its linux version, so the flip program itself can't be used. Fortunately, there is in the package another program called "batchisp3" that can be used by command line. But the bad news is that this version is not working correctly with last Ubuntu 8.04. So to flash the AT32UC3A1512, you will need to hack it. I found an interesting thread on avr-freak: you'll need an Hexadecimal editor, and replace /sys/bus/usb and /proc/bus/usb instead of /dev/bus/usb. Hopefully, once this hack done, it worked.
The first application I tried was to light some leds. For this , I used the GPIO local_bus_address example delivered in the Software development kit. I modified the Makefile to take the hacked batchisp3 for download, and added the full path for the .elf target as batchisp3 need the complete path to find the file.
After the traditional make to compile, or better make clean and make, it need a "sudo make isp program run" to flash and run the software on the target. The "isp" option specifies to use batchisp3 program instead of avrprogram, and "program" do the flash. But don't forget also the "run" otherwise the application will never run.
Ouf.
Now the next phase will be to run FreeRtos on the target. Currently it does not compile due to some bad header files. The problem is known, but there is not yet good solution.
One good thing with this chip, it that it can be flashed directly through USB. It took me some time to find that I should install the "flip-3.2.1" software available on Atmel site to do this job. But there is still a problem: this software is not up to date for its linux version, so the flip program itself can't be used. Fortunately, there is in the package another program called "batchisp3" that can be used by command line. But the bad news is that this version is not working correctly with last Ubuntu 8.04. So to flash the AT32UC3A1512, you will need to hack it. I found an interesting thread on avr-freak: you'll need an Hexadecimal editor, and replace /sys/bus/usb and /proc/bus/usb instead of /dev/bus/usb. Hopefully, once this hack done, it worked.
The first application I tried was to light some leds. For this , I used the GPIO local_bus_address example delivered in the Software development kit. I modified the Makefile to take the hacked batchisp3 for download, and added the full path for the .elf target as batchisp3 need the complete path to find the file.
After the traditional make to compile, or better make clean and make, it need a "sudo make isp program run" to flash and run the software on the target. The "isp" option specifies to use batchisp3 program instead of avrprogram, and "program" do the flash. But don't forget also the "run" otherwise the application will never run.
Ouf.
Now the next phase will be to run FreeRtos on the target. Currently it does not compile due to some bad header files. The problem is known, but there is not yet good solution.
06 décembre 2008
Out of RAM space
Well, the Arduino SRAM start to be too small for this application (no surprise). I coded too many static objects in a first implementation, so it went out the 1kbyte of memory. After some new lines of code, it's much better. No more RAM problem. But now, Flash memory space is reducing a lot. There is only less than 5kb left and only few more features will be integrated.
So few features implemented: servo neutral, servo course high and low, and transmission type (RC@Home, O24RCP) so that O24RCP receiver can be used.
I'll provide some pictures of the screen soon. But the story with this hardware will finished shortly, I believe I can't do much more without rewriting a lot of sofware.
So few features implemented: servo neutral, servo course high and low, and transmission type (RC@Home, O24RCP) so that O24RCP receiver can be used.
I'll provide some pictures of the screen soon. But the story with this hardware will finished shortly, I believe I can't do much more without rewriting a lot of sofware.
02 décembre 2008
01 décembre 2008
Neutral + course
The coding of menus and actions logic start to be consistent. But it takes more space in flash than I expected. It's now around 9KB and still 6kb left.
This is a small video which shows the menus I just coded to set the servo neutral and maximum course. The values are kept upon reboot. Still one or two little bugs, but it works fine.
This is a small video which shows the menus I just coded to set the servo neutral and maximum course. The values are kept upon reboot. Still one or two little bugs, but it works fine.
Inscription à :
Articles (Atom)
Articles
