Home

viperacr edited this page May 4, 2015 · 51 revisions
Clone this wiki locally

Welcome to the coptermanager-arduino wiki!

Overview

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

Components:

  • 1.Amic A7105 Wireless RF 2.4GHz Transceiver Module 2400-2483M 3.3V FSK GFSK
  • 2.Breadboard
  • 3.Resistor
  • 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:

A7105 module

Symbols Function Description
GND Ground
VDD RF Module Supply Voltage Input
NC No Connection
SCS SPI Chip Selection
SCK SPI Clock
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:

Final Circuit Connections

For the second half of the project we upgraded our circuit to a perf board and converted into a shield for the arduino/galileo.

center|Transmitter Shield

A more detailed description of the Arduion pins can be found here:

http://arduino.cc/en/uploads/Main/Arduino_Uno_Rev3-schematic.pdf

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:

Code Function
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 :

https://github.com/napsternxg/coptermanager-arduino

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:

https://github.com/napsternxg/coptermanager-simple

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)
GIO1 0 0
VDD 3.3 3.3
GND 0 0
SCS 4.15 4.15
SCK 0 0
SDIO 3.79 0

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

center

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:

Arduino Galilao
Rx (Pin 0) Tx (Pin 1)
Tx (Pin 1) Rx (Pin 0)
GND GND

The GND to GND connection is really important for the communication to happen.

This is how the final circuit looks:

Galileo to Arduino communication

*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

Resources:

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.

For reference:

http://developer.android.com/tools/studio/index.html http://unity3d.com/unity

References

Hubsan X4 hacking: http://www.rcgroups.com/forums/showthread.php?t=1954078

Hubsan X4 TX/RX protocol - https://bitbucket.org/PhracturedBlue/deviation/src/10c40cb9b6712bbfb7e6bac10d1768eb1dc6f732/doc/Hubsan.txt?at=default

http://www.instructables.com/id/Easy-Android-controllable-PC-Interfaceable-Relati/?ALLSTEPS http://hackaday.com/2013/11/19/hacking-a-cheap-toy-quadcopter-to-work-with-arduino/