So many of us have built quadcopters, or to be more exact, our “n-copters with n even”. However, seems that interesting solutions for a pilot’s console, desktop, “The Base station” or however you may call it, are scarce. The industry has already seen that gap and in recent years, few quite advanced solutions appeared. However, I’d like present a one of my own.
The solution which I designed is quite elaborate, in terms of features, scalibility and size of the project. I designed and built a small computer which lets you not only control your plane (whatever the plane would be), but also watch the state in realtime on one of few displays which you could possibly see in a real plane. Among other features there is a possibility to connect the console to the laptop, for forwarding data from your plane directly to your computer.
You could ask (as my friends did) why I haven’t decided to use some cheap palmtop for that and just develop software. Let me explain my vision:
- I can extend not only software, but hardware as well, when needed. For example, I plan to install some rotary encoders to work as real autopilot heading bugs.
- I can have multiple displays (currently 4), for certain reasons.
- I plan to add long-distance radio link, and the current design lets me perfectly have as many radio interfaces as I wish.
- I really think that the traditional equipment user interface beats the modern approach, which tries to make every button or knob a virtual button on a screen. I prefer a fairly direct access to all switches, on contrary to some of those “mouse&display” gizmos. This especially holds true when one has to respond quickly to real-time events, and that’s certainly what pilots have to do.
Now, so that we all know what is being talked about, here you have a photo of “The Base”.
Sorry for all those scratches, the unit has been intensively used (couldn’t that be another reason why I haven’t decided to use a palmtop for this?)
The block diagram below shows what’s inside the box.
And here is a brief description of information which goes through various links drawn in the diagram above:
- the analog joystick and the analog thrust lever provide pitch/roll and thrust information encoded as a ratio of the common supply voltage; that’s typically called “ratiometric” signal. As an ADC the internal, 10-bit converter of the main microcontroller is used. The ADC’s reference is the common supply voltage, thus processing the ratiometric signals is trivial.
- the keyboard&sound module (abbreviated KS) communicates by I2C. When designing the KS module, I just thought that I’ll save design and manufacturing time (and costs!) by combining the both parts not only inside one module (board), but within one MCU as well. The key readout requests are transmitted to the main MCU, and the sound play requests are transmitted from the main MCU to the KS, when needed. One 4×4 matrix keyboard and up to 32 push switches can be handled by the KS (16 of 32 are currently used). The sound part uses 12-bit serial DAC for producing analog sound with 8 kHz sampling rate. One could say this is nothing nowadays, I agree, but believe me, for achieving the goal this is really enough. The sounds which may be played are stored in the onboard flash memory, and they constitute of NATO alphabet (alpha, beta, charlie, …), digits and a rather vast set of standard expression (“battery warning”, “link lost”, …). Having samples of digits and characters enables trivial but powerful “reading aloud” of various states which may happen on the plane or locally, in the console (have you ever seen plane landing from the cockpit, when a voice synthesizer reads aloud height above a runway: 100-50-30-20…? )
- ADS1110 is simply used for monitoring local battery voltage.
- critical safety buttons (and especially, red “emergency” button) are wired directly to external interrupt pins of the main MCU. When one presses the emergency button, software will send by the radio special packet requesting stopping of all motors of a plane.
- UART link can be used for text console of the operating system, or for routing the flight data to your laptop or other computer.
- displays, that’s a long story. All four of them are of the same type and have identical controllers (designed by me). What basically goes by the SPI from the main CPU are just binary-encoded commands requesting drawing various graphical primitives, like a line, a bar, a line of text, etc. Such a command may “weigh” from 5 to 15 bytes for non-text primitives, and 7 + string length for text requests. This way, even though having 4 cool graphical displays, I can keep the main CPU’s utilization sane enough to have still a lot of processing power for other tasks. The displays are bound to type of graphics they show: there are “commands”, “local”, “slow”, “fast”.
- the radio interface uses the second USART of the main CPU.
- power supply board just provides a number of power connectors. The only data connector is basically ADS1110 I2C socket, that’s been described above, though.
What would that be without software, huh?
The software is based on my b5 operating system, and normally there are 12 tasks running concurrently (however some dynamic tasks are allowed; there’s init task as well, but it terminates once the system is up&ready). Just for geeks, here is a list of tasks:
- net – network services server. It is an interface between the radio chip and the layer of software applications in the system. It provides a nice layer of simple networking to the tasks, with ports, automatic retransmission, etc. It keeps the radio link busy all the time to maintain synchronization and to react when (and if) the communication with the plane gets down.
- guislow, guifast, guilocal, guicommands – tasks which maintain graphical user interface of the 4 displays
- fctrl – used to pass flight control data to the plane, namely, the desired general motors power, the desired angles of orientations or pitch&roll (depends whether we speak about a quadcopter or a plane with wings), etc.
- keyboard – for transferring key-readout and sound-play requests to/from KS
- sstatrx – receives, parses and publishes all state data from a plane (orientation, motors status and power, lights, accelerations, just everything). The published data are then accessible to all other tasks in the system, in particular for gui* tasks, so the state can be drawn somehow.
- periodic – for executing periodical operations which are noncritical for reliability.
- ana – for controling the ADC, processing conversion results and publish system-wide information about analog controls (joystick, lever, …)
- rcond – is a remote shell interface between the plane’s system console and the local console (so all messages printed from the plane’s onboard computer are transmitted by the radio to the local console and printed on the “slow” display); I plan to extend it to work as a shell gateway directly between plane’s console and the computer, when it is plugged in by USART interface
- idle – the OS’ idle task
I’ve got a tiny application like Unix “top”, which I can run in the system. That’s what it shows (few first rows):
There’s also the radio link diagnostic tool, one of the screens which shows statistics about it:
How does it taste like?
That’s difficult to express using photos. I promise I’ll record a movie soon.
But I’ll try to keep you satisfied with photos.