Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Welcome to the coptermanager-arduino wiki!
This project involved hacking into a mini quad copter system (Hubson X4) to be able to control it using an Arduino. There were three main stages :
- Building the Transmitter circuit
- Coding to Bind and Fly
- Controlling through keyboard inputs on a webserver
Building the Transmitter Circuit
- 1.Amic A7105 Wireless RF 2.4GHz Transceiver Module 2400-2483M 3.3V FSK GFSK
- 4.Jumper wires
- 5.Solder equipment
- 6.Lab space and patience
The objective is to replace the controller for the quadcopter by the arduino. Thus,we use the arduino coded with the transmit instructions which are then relayed wireless-ly to the copter by an RF Tx module.
RF module pin config:
|VDD||RF Module Supply Voltage Input|
|SCS||SPI Chip Selection|
|SDIO||SPI Data I/O|
|GIO1||General Purpose I/O1|
|GIO2||General Purpose I/O 2|
The circuit was built on a breadboard.
For the transmitter the circuit schematic is as follows:
For the second half of the project we upgraded our circuit to a perf board and converted into a shield for the arduino/galileo.
A more detailed description of the Arduion pins can be found here:
Code for Copter Bind and Fly
The copter was coded with a fixed set of instructions describing a particular path. The controls for the throttle, rudder,aileron, elevator are al listed in the code and can be changed to alter the path.
The Bind refers to establishment of connection between the Arduino and the copter. In the initial state the copter has a pair of blue LED's that blink. When the bind is achieved, the LEDs stop blinking. (This is specific to the copter used).
Flying data is transmitted as 8 byte packets in following format:
|Byte 0||throttle 0-255|
|Byte 1||Yaw 0-255|
|Byte 2||Yaw_trim 0-128|
|Byte 3||Pitch 0-255|
|Byte 4||Roll 0-255|
|Byte 5||Pitch_trim 0-128|
|Byte 6||Roll_trim 0-128|
|Byte 7||Fly/run 0=fly, 16=run (toggle button on handset)|
The code used can be found using the link :
Video Demo: https://www.youtube.com/watch?v=K07c37xvlz4
Using Keyboard inputs over a web-based server
Using the same serial protocol we can talk to the copter through the computer as well. The copter is controlled through keyboard inputs on a webserver.
The code can be found here:
Issues with porting on Galileo
We tried running the same code with same pin connections on the Arduino part of Intel Galileo Gen 2 but we were unsuccessful. The issues is probably with the SPI pin header.
We faced a major issue in the SPI pin configuration. Pin 11 on the Galileo was not acting the same way as Pin 11 on the Arduino. We checked the voltage across major pins on both arduino and galileo and found the difference only on Pin 11 which is connected to the SDIO pin on A7105. The voltage on Pin 11 is 0 when using on a galileo but on arduino it gives a good 3.79 volts.
Below table shows the exact chart of difference in voltage values on Arduino and Galileo as recorded on the A7105
|Pin||Arduino (in Volts)||Galileo (in Volts)|
We feel the difference in the SDIO pin which is connected to the MOSI pin on the respective boards is the issue. We also found that there are some known issues related to the SPI pin config on Galileo.
Some references to the SPI pin issues on Galileo: http://www.emutexlabs.com/component/content/article?id=203:getting-started-with-intel-galileo-gen-2 Galileo pin config: http://www.intel.com/newsroom/kits/quark/galileo/pdfs/Intel_Galileo_Datasheet.pdf Arduino pin config: http://arduino.cc/en/main/arduinoBoardUno Arduino Galileo: http://arduino.cc/en/ArduinoCertified/IntelGalileo
Arduino vs Galileo
After several attempts to figure out the difference between the two boards, we learnt several new things. Initially, we found the voltages on the MOSI( Pin 11) of the boards to be fairly different which led us to believe that the boards have a different circuit architecture. The voltage comparision is shown in the previous section.
The next step was to figure out if any other pin on the board could be used for the purpose of our project. We found that the ICSP pins had a MOSI pin as well. We tried that out and found it to behave exactly the same way as the MOSI (Pin 11). However, it was not useful for the project.
Intrigued by the differences, we made use of a Logic Analyzer to visually interpret the voltage differences between the corresponding pins of the two boards with the same code. This experiment gave us a pretty good insight on the difference in the nature of the two boards.
###Arduino Uno MOSI and Clock
###Galileo MOSI and Clock
On comparing the MOSI signals between the two, it was found that unlike the signal on the Arduino, the MOSI signal on the galileo was active low (i.e its idle state was HIGH). This was found to be a significant difference in the functioning of the two boards.
###ICSP MOSI and Clock We could confirm that the ICSP MOSI and clock pins are similar to the Digital PWM MOSI and Clock pins.
Arduino Galileo Communication:
We decided to try out another approach where in we run our transmitter module on the arduino but send the signals to the board using the serial port pins of galileo instead of the USB serial connection from laptop.
The serial port of the Arduino and galileo can be accessed using the Rx (Pin 0)/Tx (Pin1) pins of each of the board.
This required the following changes in the circuit:
|Rx (Pin 0)||Tx (Pin 1)|
|Tx (Pin 1)||Rx (Pin 0)|
The GND to GND connection is really important for the communication to happen.
This is how the final circuit looks:
**In this setting the arduino should be powered by its own power supply instead of using power from a USB port. **
Next, we can try to send data from galileo to Arduino using the Rx/Tx pins.
The, code to setting up the the serial port or galileo is:
cd /sys/class/gpio echo -n "28" > export echo -n "32" > export echo -n "45" > export cd gpio28 echo -n "out" > direction echo -n "0" > value cd gpio32 echo -n "out" > direction echo -n "1" > value cd gpio45 echo -n "out" > direction echo -n "1" > value stty -F /dev/ttyS0 115200 //change to the baud rate you want to use echo "Configured Rx Tx pins" echo -n "value" > dev/ttyS0 //change value for what you want to write cat /dev/ttyS0 //read from UART
- How to open serial port in Galileo Gen 2?
- How to program UART serial from Linux on Galileo Gen 2?
- Arduino Serial
Issues with Galileo
After setting the communication circuit between galileo and arduino, we were not able to get the communication working. The galileo was not sending or receiving or sending any signals.
We used the same node.js code on galileo, as was used on the laptop to communicate with the arduino, to send copter control data to the arduino. We were getting an "Illegal Instruction" error while running this code. This points towards the fact that some of the libraries, especially the serial communication library (suspected) is causing the problem. The error is a node specific error which happens when the binaries for a library are not built for a given architecture.
In order to solve this issue I tried the following commands: opkg update opkg upgrade opkg upgrade --force-overwrite
The last command seemed to have caused some major issue because of which the board stopped working and even on rebooting the SSH communication was lost.
Integration with Google Cardboard
Further work was started with regards to controlling the quadcopter with Google Cardboard and VR, but current problems with migrating over to the Galileo were undercutting any use in expanding the project to cover Cardboard. The idea was to use the coordinates from the phone's accelerometer and gyroscope and the calculate quaternions to build a location that the VR headset's normal is pointing to, and to use the magnet on the side as a control interface for the throttle. However, there is a serious lack of control interfaces on the Google Cardboard anyhow and most development for the Cardboard involves using Android Studio in conjunction with Unity. However, the lack of any desirable results on the Galileo in terms of a serial connection and SPI communication across the 3-wire SPI bus led to a complete halt on the VR portion of the project.
Hubsan X4 hacking: http://www.rcgroups.com/forums/showthread.php?t=1954078