Design of a controller Part I: Introduction and construction

Introduction

This is the first of a three-part project about the full design of a universal remote controller. There will be a link below to the other posts/parts when they are created.

In this first part, I discuss the general considerations of the project as well as the construction of the controller.

In the second part, I will cover the electronic design, manufacturing, and electronic testing of the PCB.

Finally, in the third part, I will cover all the software-related aspects, notably the programming of the microcontroller, and also the design and implementation of the HMI (Human-Machine Interface).

The three parts are not chronologically arranged, i.e., in the construction of the first part, I assume that the PCB is already available.

Although this is an advanced project, it has been designed in a way that tries to be accessible to the vast majority of the amateur community. For example, we chose the Atmega2560 because of its popularity in the community.

I want also to note that I will gladly answer any question about the project. You can text me or post a comment and I will try to answer, at least during the first years :).

Disclaimer. This is a personal project that I'm sharing with the community. I am not accountable for any injury or damage produced by explosions, fires, electrocutions, or attacks that can arise from the replication of this project and further command of any kind of robot.

This project has been possible thanks to the Universitat Politècnica de València and its special sponsoring program, Generación Espontánea, which has funded a wealth of Makers UPV projects.

Motivation

As a Maker, I have developed various robotics projects and I have always stumbled upon a problem: the communication with the robots.

I have always used a development board connected to the PC and to a radio or Bluetooth module. This method presents a lot of issues. To name a few: you can't control the robot in an organic way unless you add some potentiometers or gimbals, and if you do so everything becomes even more messy and bulky. The wires sometimes get detached, occasionally with catastrophic consequences; and last but not least, it looks horrible. These are the main reasons why it is a good idea to have a proper controller, but there are many more.

As an alternative, you can use an off-the-shelve remote controller but all its functions are predefined and you cannot modify it as you please. The restrictions that impose a non-programmable controller make it unadvisable unless you only want to fly your drone or other usual tasks.

I am not the first Maker that has faced this problem and between a lot of shabby controllers similar to the ones I used, there are a couple (maybe three, no more) of nice projects.

https://howtomechatronics.com/projects/diy-arduino-rc-transmitter/ was and is one of the best. However, it keeps being by far unsuitable for advanced projects: you don't have the ability to transmit or receive complex instructions such as trajectories or paths, it does not have a USB port, it works with cells, it uses joysticks instead of gimbals... And the list goes on.

To sum up, I want capabilities similar to those of the OTS controllers from FrSky, DJI, FlySky, etc, but I also need my controller to be fully programmable. It seems that I want to eat my cake and have it too, but actually it is possible to have it all.

Components selection

This section summarises the requirements analysis and the selection of the components that arise from such analysis. Even if this is presented in an ordered and sequential method, the process is iterative and mutually referential. For example, the selection of the voltage level depends on the electronic components such as the battery or the display, but their selection is in turn heavily constrained by the voltage level.

Voltage level: 3.3V

This is probably the most important decision of the project. We considered two voltage levels: 3.3V and 5V. In the professional world, 5V is legacy and even 3.3V is already being displaced by 2.5V or 1.8V. However, in the amateur world 5V is widely used. This is mainly due to the fact that the traditional Arduino boards were designed at 5V.

During the preliminary design we had the problem that some of the selected components required 3.3V (radio, bluetooth, gimbals) but others required 5V (USB port, display). A compromise solution would be to use both, but this poses other challenges that I will discuss more in detail in part II.

With regards to power consumption, 3.3V would definitely be the preferred solution, not only because of the voltage difference, which is directly related to consumption, but also because level conversion is not required (voltage regulator or boost converter).

At the end, after some unorthodox fixes, the controller could work exclussively at 3.3V. For deeper design considerations, read part II of this guide.

The battery: Lipo 1S 2800 mAh

Traditionally, there are two ways of powering standalone projects: batteries and cells. The latter ones have the advantages that you can stack them fairly easily to obtain the desired voltage level and, if they run out, you only need to replace them. Nevertheless, they have plenty of drawbacks. They are bad for the environment, they are quite bulky, they don't come in flat packagings and they are not rechargeable (there are rechargeable ones but they have more problems).

Therefore, we chose a battery. The two main options are valid: Li-Po and Li-ion. They have the same nominal voltage and they are quite similar. Generally, the packaging of Li-ion is a bunch of AA cells, which is quite thick; while the Li-Po batteries used in tablets are very thin and large, which is perfect if we locate them at the back of the controller. They are also easily available.

We also had to choose between one and two cells. The maximum and minimum voltages of a cell are 4.2V and 3.2V respectively. If we used one cell, the minimum voltage in which the system will work properly would be around 3.5V. This would leave a small portion of the battery capacity unused. If we used two cells, we would not have this problem, but as they are not used in tablets the packaging is thicker. Moreover, a balanced charger would need to be implemented, which considerably complicates the PCB design (see part II for more information).

In the end, we chose the one cell option.

The microcontroller: Atmega2560V

The AVR family is the most famous microcontroller family in the Maker community. This is thanks to the most known Arduino boards: Arduino Uno, Arduino Mega, Arduino Micro... Other alternatives such as the ESP32 based boards or the Teensy boards are also popular but they are more complicated to use. In the professional world, ARM-Cortex microcontrollers dominate the market.

The difference in almost every aspect between the AVR family and an ARM-Cortex Mx is abysmal. If we were working for an enterprise, we would have opted for one of these microcontrollers, for example, one from ST. However, to make it accessible to the makers community, we decided to choose between the ones from the AVR family.

For those who are not very familiar with the terminology, Arduino Uno is the name of the board, the PCB, which contains an Atmega328P which is a microcontroller (the one displayed in the photo), which belongs to the AVR family (like the Atmega2560). A microcontroller can be used in a myriad of different boards. A microcontroller (MCU) family is a group of MCU with the same ISA and very similar architecture (hardware) but with a different number of peripherals (for example, different number of pins).

The peripheral requirements of this project are around 12 GPIO, 6 ADC, 3 UART and 1 SPI. From the ATmega subfamily, we considered the ATmega2560. There is another subfamily which is the ATxmega which really is a huge improvement over the ATmega. However, choosing the Atmega2560 would let the community replicate it much easier with an Arduino Mega. Then in order to keep things simple, we chose the ATmega one.

Before ordering it, however, we have to take a look at a critical factor: the are two submodels, the one with a V and the one without. This is explained in the Speed Grades subsection: the ATmega2560 can only work at 5V. As we use a 3.3V power supply, we have to choose the ATmega2560V and the maximum clock speed is limited to 8MHz which should be more than enough. The other numbers you can see in the photos are variants with less flash and fewer ADC channels which we are not interested in.

The gimbals: FrSky M9 Taranis

The gimbals are a critical component in which you should not look at the price. I recommend buying one of the best. The experience and the comfort of touching good gimbals are very important. It's so satisfying! If you are only interested in the engineering part, good gimbals are almost immune to noise and they are less prone to change their output after hours of use.

The procedure for choosing the gimbals is quite easy: you select the biggest controller companies like FrSky and you search gimbals in a web browser. Then, you pick the best ones they have.

The display: Nextion NX4024K032 (3.2")

The selection of the display was easier than expected because of all the requirements it had: RGB, touchscreen, easy to interface with a microcontroller via a SPI or UART interface and 3.3V compliant.

There are two possibilities if you want a touchscreen: TFT LCD and the Nextion displays. OLED displays were discarded. E-paper displays were also discarded because a decent refresh rate was required. The selected microcontroller, as it has a lot of GPIO was well suited to work with LCDs and they usually work at 3.3V. Moreover, the LCDs that work with SPI can reach a decent bandwidth.

Nextion displays worked at 5V, communicated via a UART port and they were slightly more expensive. However, they have really great assets that make them unique. They are not only the display per se, they are a standalone board, with an integrated microcontroller (ARM Cortex M0 I believe), integrated flash, SD reader, and other auxiliary functions. They store the program themselves and they only need to communicate with our microcontroller to notify about events or to receive commands. This is great. This is actually really great! In addition, they provide you a program (Nextion Editor) in which you can develop their applications. If you are using an LCD display, all the information about what is being displayed is stored in the external microcontroller and you have to use primitive drawing libraries, not convenient at all. The Nextion Editor is not a very good HMI application designer but is much better than using the crappy C libraries.There was however a requirement that the Nextion displays did not meet: 3.3V compliant. If you take a look at their datasheet which, by the way, does not tell almost anything, you can clearly see that it works only at 5V. But why? The ARM Cortex for sure works at lower voltages as well as the flash and the SD driver. The quick answer is: for compatibility with traditional Arduino boards. It does not use the 5V voltage level in any of the ICs.

If we wanted to use this display, we would need to boost the voltage up to 5V to power up the display but, as it does not use this voltage level, it would lower it to 3.3V which is the voltage level that we had at the start. This is stupid!

However a little bit of reverse engineering could solve it: once we had checked that all the modules worked at 3.3V with a multimeter, then we located the voltage regulator and we removed it with tweezers and a hot air station. Then we only needed to short circuit the 5V input with the 3.3V output and keep our fingers crossed. It worked!

The lever switches

The number and location of the switches are determined by personal preferences. What is important is that they look like the ones from the planes seen in the movies and that they produce a nice and satisfying noise. We also chose a fancy rocker power on switch.

The radio module

This project aims to be a guide to further controller-related design activities. A component that easily changes between projects is by far the transmission module. Generally, if we wish to transmit data at long distances (hundreds of meters to kilometers), the preferred technology is radio. Bluetooth can make the job but only at very short distances.

The communication between a radio module and the microcontroller is generally quite standard: an SPI interface (sometimes UART can do the job) and a couple of auxiliary state or control pins like an IRQ (Interrupt ReQuest). With these considerations, we have designed a couple of SPI headers with 2 auxiliary GPIOs that can both receive interrupts.

We had initially planned to use the nrf24l01 module, which is probably the most popular radio module in the community and it can reach, with the antenna, several hundred meters. We had also plans to use Xbee radio modules (which use the ZigBee technology). Some modules can reach several kilometers at low transmission speed.

In order to make it as flexible as possible, we designed the case with several screw holes in different positions so later we could embed a board with the radio module. We have also included in the PCB a header compatible with the HC-05 which is a very popular Bluetooth module that interfaces by means of an UART communication. The idea is that the Bluetooth module is used to transmit data to/from a close device such as a Laptop rather than with the commanded devices.

For a detailed description of the communication interfaces implemented in the PCB, please read part II of this guide.

The case

I had the chance to collaborate with a design engineer student (Ferrán) from a university group called YuDesign. He designed and manufactured the frame.

I gave him controller references as well as the components except for the PCB that wasn't even designed at that time. I explained to him where I wanted the components to be and a couple more indications.

Egor Nesterov, a partner from Makers UPV, made an amazing 3D copy of the gimbals. The other components were roughly made and a 3D model of the PCB was generated using Eagle and Fusion 360. You have all these files ready to download in the CAD section. As you can see in the photo below, the designs attached in the CAD section are not the ones used to print the case. These are the ones I had in the cloud. However, his storage unit died months later and he could not provide me with them. In the last version, he added ribs to improve stiffness.

The fourth version was the final and approved version of the controller. First, the tolerances and diameters of the fits had to be adjusted with a couple of printed probes. Then we printed the frame several times. We used a high-quality PLA called INGEO870. Other plastics were considered such as a couple of ABS but Ferrán decided that this PLA was a better option.

Finally, the casing was sanded, primed (with a plastic primer), painted, and varnished.

The assembly

In this section, I will briefly explain the construction with a bunch of photos. I will not enter into details. If you have any doubts, feel free to contact me. You can take a look at the PCB schematic. It is not the last version, but the pinouts are fine.

First, we wired the gimbals and the switches. The gimbals come with their own connectors, we had to replace them with ours. As there is not too much space inside the controller, the length of the wires was righteous adjusted so all the wires don't clog the middle. Therefore, the switches wires were not shorted to their propper length until the PCB was assembled.

Then the display was screwed to the case with the socket head cap screws and spacers. The touchscreen cannot make contact with the plastic case so, at the edge of the screen, we stuck and stacked thin layers of foam tape. The photos displayed below are actually with the screen assembled upside down (we corrected it later but we forgot to correct the photos).

The next step is to assemble the PCB and connect all the wires with the help of the datasheet. The power button must be connected between the PCB and the battery: it opens and closes the negative/positive terminal of the board. At this moment the radio module is also connected. As we did not design a proper mounting hole for the radio and it tilted to one of the sides, we stuck it with hot glue (I know, it looks horrible, but!). The battery is attached with Velcro at the back of the case so that it can be easily replaced.

Finally, with much more pressure than expected, the case could be closed and sealed with 8 fancy socket head cap screws.

Epilogue

This is the end of part I of the guide. Feel free to comment or send me a message about anything related to this guide. Good or bad it surely will help. The layout of this guide (explaining the assembly before the PCB design, I have referenced part II at least a thousand times) is unconventional so I would be glad to hear feedback about that.

This project has been possible thanks to the Universitat Politècnica de València and its special sponsoring program, Generación Espontánea, which has funded a wealth of Makers UPV projects.