Quad/GoPro Camera Test

This video shows one of the first test flights using a GoPro camera strapped to my quadcopter. The camera is mounted using the included straps and is free to move around a little bit, so there is some movement and vibration evident in the video. Although way off balance, stability and power aren't much of a problem, but the batteries drain noticeably faster with the camera attached. The throtte is being hard limited to 75% for indoor testing.

Here the camera swings a lot so the video can be hard to watch:

Here the camera is mounted in a more stable way, top-side:

Quad-Copter: Control and Feedback

  The quad has been working well using the MultiWii RCSerial protocol and custom XBox controller for basic flight controls, so it seemed time to add additional capabilities. The controller code now uses the same type of implementation used in the actual MultiWii code for building and sending RCSerial commands, so commands are easy to structure and send. The default failsafe code doesn't currently work with serial commands, so some simple modifications were made to accomodate the serial based control. Additional mods to the protocol are still being made to accomodate some additional commands and features as well.

   
  The flight control board has been updated with a GPS module and connections to monitor the battery voltage. Initial testing shows the quad can handle incoming commands while sending out data , so some initial coding was done using the Static Google Maps API and Processing to receive serial data from the quad, then display it on a map and plot the path taken during flight. 

  The sketch was designed to use the least amount of reasources possible, by passively listening for data to be sent periodically, and making use of the existing APC220 tranciever module on the FC board for communication. Here is a screenshot of the current iteration showing what it looks like in use. Here, the quad is actually sitting still, and the GPS is tracking around way off course for some reason, but it makes for a good demo of the tracking:

The above sketch is intended only for GPS functionality and basic status info, so will be kept fairly simple. It still needs work and requires some minor modifications to the MultiWii code. Right now it does the following:
- Displays location from GPS data
- Displays heading from magnetometer data
- Logs I2C errors with timestamps
- Plays warning sound if I2C errors are detected
- Zoom In/Out

Processing Sketch: 
MultiWiiGPS
Notes:
- Requires minor changes to MultiWii. See the included readme for info.
- Will work with any serial-data based transceiver
- If it stops getting maps, get an API key here
- Requires ControlP5 library
- Ubuntu users require this fix for audio to work
- Designed/tested with MultiWii_dev_r1240

  In addition to the GPS sketch, here is a link to the XBox controller code with initial integration of the RCSerial protocol. It is a work in progress, but the code is very stable, and it works great. See previous posts for details of the controller build.

Arduino Sketch:

XBox Controller RCSerial 

 

Quad-Copter: Free at last

The quad has come a long way in a short time since the previous post. After a fair bit of reading, adjusting and testing, I was finally able to get my custom flight control board working with the MultiWii software, and the initial results are better than expected.

I was able to get it working initially with the flight software by converting the data to PPM Sum at the receiver, and it worked fairly well in testing. This required the use of an additional microcontroller to receive the signal and convert it, so was not ideal.

Below is a short video showing the Quad-Copter while I attempt to learn the controls and work out some of the details on my custom controller. There are many things that still have to be tweaked, tuned, adjusted, and implemented but at this point, it is looking pretty promising for a custom rig:

After some more looking at the RCSerial protocol built into MultiWii, I was able to build it into my sketch and communicate directly with the flight control board using serial data via APC220 radio module, and my customized XBox controller. I had some troubles finding examples of direct control using the RCSerial protocol, so here is the working but incomplete sketch I have been using. In the next video, the flight control board is closer to completion, with the rf module, gyro/accel and magnetometer all soldered into place, and is using the 'Angle' and 'Mag' modes in MultiWii:

This mode is a lot easier to fly in, and after a few more flights like this, I'm comfortable that this setup is going to work pretty well, especially after some tuning and adjustments. As can be seen, the motor mountings are bent a bit, and the propellers also have some big cracks in them due to previous crashes, but it flies fairly well regardless. The throttle is being hard limited to 3/4 just for safety indoors, and I'm not getting close, so it will be interesting once this thing is outside. Additional features like low battery detection needs to be added, and some extras like GPS, a barometer, or an LCD screen may be added too, but a few bugs need to be worked out first. And yes, that is in fact a breadboard plugged into the Arduino Mega like a shield in the first video.


Details of flight controller on Summary Page:

Building a Quad-Copter

Why a quad-copter? Time spent working on various projects involving robotics and automation have led me to a single conclusion: Flying Robots!

My first searches on the subject turned up various projects that offer pre-built units you can simply buy, connect, and fly, but the point here is to build a unit with interchangeable and customizeable Arduino-based flight and radio controls, and hopefully learn a few things along the way. This will also allow me to build, tweak, add or modify any component as required.

After receiving the main components: frame, motors, ESCs, battery, etc., the first thing I did was test out a single motor and ESC using DIY speed control (An Arduino). I have some 20A Turnigy MultiStar ESCs, so connected the orange wire to pin 9, brown to ground, and left red unconnected. Then, with the power connected to the battery, and using the servo library, I was able to get the motor going by using servo.writeMicroseconds(700); and ramping it up to about 800 to hear the beep indicating it is ready to go, and then up to 900 to get the motor turning. Ramping it up higher increases the RPM, so it seems pretty simple to control. Later experimentation showed that starting at 1000 and ramping up from there seems to work the best.

Setup for spinning motors up and first liftoff:

The initial testing was done using commands sent over the serial port, and the next step was to use wireless remote control so, of course, I used the newly customized XBox controller from the previous post to acheive that. The controller sends a variable and/or a value, (such as "S 1000" for a speed of 1000) and reception is as simple as Serial.read(); etc. Since there are multiple rotors, two must spin the opposite direction of the other two, along with having reversed propellers. The ESCs come with a simple programmer, so direction is easily controllable electronically. Along with the servo library, I was able to spin up all four motors and get the quad-copter airbourne for the first time, if just for a few seconds.

Next is final assembly of the unit and to try for some DIY flight stabilization. My first attempts at flight control will use the Proportional-Integral-Derivative (PID) library which takes an input (pitch,roll, etc) and adjusts an output (motor speed) to maintain a constant reading. This is the same type of thing the line-following-junkbot code attempted to do. Currently, I have an MPU-6050 gyro/accellerometer module connected, which I hope is enough for some simple stabilization. Prior testing required the device to be strapped to the floor with a few inchess of slack, just enough for it to get airbourne, and the same setup will be used here. As luck would have it, my frame kit is lacking in nuts and bolts, so I had to scrounge some up from various broken electronics, and the "feet" are not connected.

First stabilization attempt

Above is the video showing the initial flight using untested and untweaked settings for the PID library and stabilization. Without PID enabled, the quadcopter lurches and jumps when the ropes pull tight, so this flight demonstrates that the stabilization is at least somewhat effective. Next will be to tweak and tune the PID, timing, and associated code for more stable flight, then probably on to controlling its movement.

This next video shows the quad once the PID settings are tuned a little bit better, as it demonstrates some actual stability. It is connected to the board via a large elastic, so whenever it pulls taught suddenly, there is a tendancy to jerk to the side, which the copter succesfully counteracts to a large degree. It took a fair bit of work to acheive this much stability, so a pre-bought flight control board is starting to look appealing.

More progress towards stabilization

Judging by its stability when under load and encountering some additional outside forces (from the tether), it may be time to start working on movement controls. They would simply adjust the balance point for the yaw and pitch, allowing me to direct its movements, and do some more fine tuning on the PID adjustements.

The MPU-6050 will be used in conjunction with an HMC5883L, which pretty much gives me the equivalent of the FreeIMU v0.4 board, minus the barometer. I've run the FreeImu GUI software, and succesfully calibrated my device, but the MPU-6050 library below seems to provide much more accurate readings, so I've been sticking with that. Since it works fine with the FreeIMU library, I attempted to use the MultiWii libraries, but have not had any luck. The sketch below is pretty basic, and only uses yaw, pitch, and roll readings for stabilization.


Libraries and Sketch:

Rough sketch
MPU-6050 library
Modified PID library


Hardware info on Summary Page

                   Original Box Controller: Arduino-based Wireless RC Conversion V2

Here are the details of my second conversion of an original XBox controller into a wireless controller for Arduino-based devices. I chose an XBox controller since it offers a well designed unit for little to no cost, replacement parts are easy to find, and it offers many inputs in the form of buttons, triggers, and joysticks. I chose an old controller that stood up well in its day and is about the same size and shape of a current XBox360 controller. Info and code regarding the first iteration of this can be found here and here.

This version will be similar to the first with a few differences:
a: Now using a UART driven radio module. Rx/Tx is as easy as using Serial.read/write. Fairly long range: 1000m
b: Wiring is simplified by using internal pullup resistors for every digital input
c: Better design of wiring and layout.
Other design considerations/options:
- Arduino Mini seems better suited, but did not have one on hand.
- If use is 'static' and predetermined, microcontroller can be completely embedded with a DIY board.

Below are the detailed steps showing the installation of an Arduino Nano into the controller along with an APC220 radio module. 

Pics:
The XBox controller as original and opened for the first time. This just required the removal of some screws and a sticker.


A look at the insides with the cable cut away and close-ups of joystick and potentiometer that will provide an analog reading to the Arduino.


A closer look at the insides of the controller before and after removing the big plastic center piece.


The center black piece required a soldering iron to remove. Plenty of room to work after removal:


The method I used to cut the circuit board was to grind or cut through most of the copper layers with a knife or rotary tool, then I cut through the remaining part with scissors. Without piercing the copper, it kind of shatters when cut. Shots of the board with center piece cut away. As seen in the right side picture below, could have more easily connected the wires to the group of solder points instead since there is one for each button after removing the smd resistors.


Now to finish wiring it up. The controller has a total of 14 digital outputs (buttons/d-pad) and 6 analog outputs (potentiometers/joysticks), and I will be using all of them except the buttons attached to the joysticks. The pictures show how it is wired up in reality, and in theory, the buttons are wired as shown here while joysticks/triggers are as shown here. Some descriptive info can be found in a prev post here. The idea is to cut out or grind away any connections leading from the + side of the buttons and potentiometers, then run your own wires in their place. In this case, the pots on each side shared a common positive lead, so I left that in place. Removing the triggers was necessary to get at all the leads.


Final pics showing the assembly of the modified controller. A small part of the inside case had to be ground away to make room for the wires to be run underneath it The board with the arduino and RF module attached was also ground down a bit in a few places to make it fit inside the controller a bit tighter, as shown in the last picture.


The output from a simple test sketch displays the 12 digital and 6 analog readings. Despite my less than skillful soldering work, all readings are testing correctly except those from the the B and X buttons, which were not responding at first, but turned out to be due to loose connections. Not too bad for the initial powerup!


The next step was to transmit the data, which ends up looking exactly the same when sent over the radio link to the PC or an Arduino. Then the top cover piece was modified as shown to make room for the ends of the electronics and to fit the battery inside. I will probably make room for the battery to slide back farther, but it fits nice and snug, so will leave it for now



Troubleshooting and Details:
- Test for short circuited connections after soldering a large number of wires, and before powering up for the first time. Small wires being heated tend to melt together.
- Seems best to secure the wires to the board since they need to run through certain paths in the case, and it helps to prevent wires from coming loose or being mangled. A small grinding tool helps to make room.
- A multimeter is essential for finding the correct leads and troubleshooting 
- Interfacing to the existing USB connection may be possible with a USB host shield, but that would add additional hardware, size and cost.
- The parts etc. were all chosen for simplicity, but more customization could make a nicer integration.
- I tried to avoid using the software serial library via the method described here, but went back to it due to what seemed like buggy behaviour.

Main Required Parts for Build:
1x Arduino Nano
2x Serial-data RF Module (APC220 or other)
1x Original Xbox controller 

Connections/Pins (Arduino Nano):
2-10:  Buttons ABXY, UDLR, black
A0,A1 - R JoyStick U/D,R/L
A2,A3 - L JoyStick U/D,R/L
A4,A5 - Buttons Start,Select
A6,A7 - Triggers R,L
12 - APC220 SET pin
11 - APC220 Serial RX pin 

Arduino Sketch:
Found here. The sketch is designed for controlling MultiWii based devices via the built-in RCSerial protocol.
Note: Sleeps after 5 seconds of inactivity. Press A to wake up.

TMRpcm Arduino WAV/PCM Audio Playback Library Update

This is an update to my Arduino PCM/WAV audio llibrary detailed here and in previous posts. I now have the files hosted at GitHub, and I added an optional proof-of-concept library that enables RF (wireless) audio streaming capabilities to Arduino. Currently it will support two remote devices, but can be easily modified to stream to more. Arduino Mega likely needed for RF (wireless) audio host due to compiled size.

Source: here

Library Package: here

JunkBot & XBox-RC Code Update:

Finally cleaned up the code for my JunkBot and XBox-controller based transmitter. I mainly went through and organized variables into arrays and loops as well as trying to simplify things where possible. The compiled controller code is 1KB smaller, and JunkBot code is about 4KB smaller than the last posted version. There are no real functional additons, but many improvements. Technically the JunkBot code should work with any Arduino-based RC unit that uses two motors for movement and a VirtualWire capable receiver.

The JunkBot is a small radio-controlled device made out of spare parts, and the main controller is an XBox controller with an Arduino Nano embedded inside, with an RF transmitter module attached. Details of both devices are in previous posts.

JunkBot Sketch

XBox Radio Controller

Over-the Air (RF) PCM Playback with NRF24L01+ and Arduino

Previous posts regarding the playback of wav files from an SD card were related to another project I am working on involving NRF24L01 radio modules. Since these are capable of around 20KB/s in a real-life scenario, I thought it would be worth a shot to try sending the audio over the air. Basically, I wanted to get feedback from an Arduino operating remotely in the form of sounds, but I don't have room for an SD card locally on the controller, and I also wanted the remote Arduino itself to be able to give feedback in the form of sounds when events are triggered or commands are received, etc.

This is the sketch I have been using to work out some of the details and the bugs. Right now it is geared up to work with two 'controllers' in that if you send the letter 'g' over the serial port to the 'transmitter', it will randomly play a beep on one of the three devices and continue randomly on as fast as it will go. (audio files not included) There is also a data transfer rate test that can be enabled, so one can see exactly how fast data is flowing. It will also play a sound file over the RF link, but thats kind of boring. The sketch is being posted mainly for my own reference, because in its current form I can't do much with it, and its not really useful for anything, but it does demonstrate the capabilities and how to use them.

This RF side of this also uses improved code for PCM playback, which I will likely include in the library previously posted. The timer is run at a minimum of double the actual sample rate, so as to maximize audio quality. Low quality 8khz sample rate sounds sound much, much better this way. This is very similar to the PCM libary, so sounds can be anywhere from 8-20khz sample rate, 8-bit, Mono, but it won't handle 20khz very well, since that is basically the max transfer rate. Speaker is pin 9 on Arduino Uno,Nano, etc, and 11 on Mega.

The system works using ack-payloads and interrupts to coordinate the data transfer and simultaneous playback. What is referred to as the 'transmitter' is actually set to PRX(primary reciever) and sends sound data in the form of ACK(acknowledgement) packets, with 32bytes payload. The 'receivers' just send out commands till one is answered, and then request the data as they need it. The 'transmitter' only sends out data in response to an incoming command.

 This could theoretically work on a larger number of devices, since it only uses a single data pipe at a time with different addresses for each device, but I don't really have any use for that.Change the data pipe to [1] before uploading to a second receiver.

The SD 'Transmitter' is a big sketch, and at the moment is just a bit big for the ATMega328, and I have been testing using a Mega 2560. The receivers are tested with a Nano328. Again, these are just rough sketches, but they work fairly well at this point: 

Controller/Receiver: here

SD Transmitter: here

This is the library for the NRF24L01+ I have been using: nrf24l01  Disclaimer: I did not author this library, it was found here . I just hacked in some extra code for testing which is required for this version of the sketch, and wanted to archive it for future reference.

Asynchronous WAV/PCM: Arduino Audio Library Update:

 This library allows asynchronous playback of WAV files using only an Arduino, SD module, and a speaker.

 A little while ago, I decided to create a library for simple wav file playback using an Arduino, since I couldn't find any that fit my needs

Logical Functionality: 

I posted two previous versions of this libary, one that used a buffer, and one that used interrupts to load the data. Each had its tradeoffs, and neither were perfect. The interrupt based version had noticeable sound quality issues, and the buffering version could not be easily stopped during playback, or the volume adjusted, etc.

 The problem as I understand it, is that a read from the SD card will actually read 512 bytes at a time, so the buffering interrupt would not always complete before the music interrupt was set to trigger next. Since only 1 interrupt will trigger at a time, timing was an issue and so created other issues.

Searching through the datasheet for some functionality that would allow me to do what I wanted, I stumbled across mention of 'nested' interrupts. It took a little bit of time to figure out exactly how to use them in this application, but here is a brief overview of how the timer and interrupts work together:

OVF: This is an interrupt overflow vector that is triggered everytime the timer 'overflows'. (every cycle) Here, it reads a byte from the buffer into OCR1A, and therefore changes the pwm duty every cycle (@16khz)

COMPB: This is an interrupt compare match vector that is triggered when compare match is made during the timing cycle (TCNT1 == ICR1). This interrupt vector is used to read data into the buffers. Can be interrupted by other interrupts via 'nested interrupts'.

a: Interrupt vectors enabled: OVF, COMPB
b: When COMPB is triggered, it disables itself, but leaves OVF enabled. Global interrupts are automatically disabled while an interrupt completes. To enable nested interrupts, global interrupts are enabled manually before reading from the SD card.
c: If ready to buffer data, it begins (OVF can now interrupt COMPB while it bufferrs data)
d: COMPB completes, and re-enables itself to trigger again while it waits to buffer more data

Thanks to nested interrupts, I finally have what I wanted, with the basic functionality one would expect. I think the code can still use a bit of tweaking though, since I haven't fully tested its limits.

Updated Features:
- Sound Quality/Distortion issues have been resolved
- Uses a single timer (timer1)
- Asynchronous (interrupt driven) playback and buffering allows other code to run while music plays 

iTunes Conversion: 

a: Click Edit > Preferences > Import Settings
b: Change the dropdown to WAV Encoder and Setting: Custom > 16.000kHz, 8-bit, Mono
c: Right click any file in iTunes, and select "Create WAV Version"
d: Copy file to SD card using computer

Function Usage:

tmrpcm.play("filename"); //plays a file

tmrpcm.speakerPin = 11; // set to 11 for Mega, 9 for Uno, Nano, etc

tmrpcm.volume(1); //raises or lowers the volume: 1 or -1

tmrpcm.disable(); //disables the timer on output pin and stops the music

tmrpcm.stopPlayback(); //stops the music, but leaves the timer running

Individual Files:

TMRpcm.h

TMRpcm.cpp

keywords.txt

music.ino

Library Package:

TMRpcm.zip (OLD)
(now hosted on GitHub here)

Updated: 
Added Functionality:
Automatic detection of sample rate (8000 - 22000Hz)
WAV format verification
Memory buffer 300 bytes
Phase/Frequency-Correct and Fast PWM modes
 
Added functions: 
tmrpcm.isPlaying();  //returns 1 if music playing, 0 if not
tmrpcm.pause();  //pauses/unpauses playback
tmrpcm.pwmMode = 1; //set to 1 for phase/frequency correct mode, 0 for fast pwm 
tmrpcm.volume(0); //CHANGED from prev version, now uses either a 1(up) or 0(down)

Tested with: Arduino Nano/328 and Mega2560 
TMRpcm.zip  (OLD)

(Current version on GitHub here)

WAV/PCM Library Update:

 After reading into the capabilities of the Arduino timers, it seemed possible to generate an audio signal from PCM/WAV data using a single timer. Reading through the documentation, and looking at examples like the Timer1/Timer3 libraries, I found that I could use OCRnA to control duty cycle, ICRn and prescale for frequency, and use an overflow interrupt to update the value of OCRnA according to the defined SAMPLE_RATE, all with one timer.

How it works:

16-bit timer 1 is used for compatibility with different Arduino boards, but 16-bit Timers 3, 4, or 5 could be used on a Mega also.

The timer is set to Phase and Frequency Correct Mode, and set to run at a defined sample rate. The settings for prescale (TCCR1B) and input capture (ICR1) are what determines the frequency of the PWM signal when timer 1 is used, and OCR1A controls the duty cycle.

 An interrupt is attached to trigger every time the timer hits bottom. (Generally 16000 c/s) At this rate, an interrupt is generated 16000 times per second, and a new value is set for the duty cycle(OCR1A), then a new value is buffered for the next cycle.

In short, a signal is generated at 16000hz. The length of time each cycle stays turned on is determined by the value read in from the WAV/PCM file, which is updated every cycle.

No buffering: I am not sure of read speeds for SD cards, but testing indicates slightly higher sample rates can be achieved with no modifications. The SD library appears to default to SPI_HALF_SPEED, but will leave that inquiry for another day...

Whats new:

a: This version is completely controlled by interrupts, allowing other functions to run while music is playing. 

b: There is no longer a requirement for a large memory buffer, bytes are loaded as required

c: Added function to raise/lower volume: tmrpcm.volume(1);

d: Due to interrupt-driven playback, ability to stop/start music at will is added 

Data Format: unsigned 8-bit pcm, 16khz sample rate

iTunes Conversion: 
a: Click Edit > Preferences > Import Settings
b: Change the dropdown to WAV Encoder and Setting: Custom > 16.000kHz, 8-bit, Mono
c: Right click any file in iTunes, and select "Create WAV Version"
d: Copy file to SD card using computer

Function Usage:

 TMRpcm tmrpcm;              //Declare new object

 tmrpcm.speakerPin = 11;    //set to 11 for Arduino Mega, 9 for Uno, Duemilanove, etc

 tmrpcm.volume(1);             // 1 to raise volume, 0 to lower volume

 tmrpcm.play("filename");     // plays an unsigned 8-bit wav file from SD card

 tmrpcm.stopPlayback();     //stops playback

 tmrpcm.playing();               //returns true during playback, false otherwise

Updated Files / Source: 

Notice: This version has audio quality issues. See newer blog post for updated version

Source:

TMRpcm.h

TMRpcm.cpp

keywords.txt

Example: music.ino  //Plays music while blinking a LED via the loop function 

Library Package:

TMRpcm.zip (Current version here)