Hibernation

Hi everyone!

While is seems like this project has gone into hybernation, the people behind certainly have not. The flying-machine adventures continue even if the project in itself is finished.

I just want to say here that the project report has been submitted and as soon as it is approved we will upload it to the site so you can comfortably sift through our findings and conclusions in a more scientifically angled format (without having to wade through thousands of my puns).

So, will keep you posted on the report!

//Jens Walker, project manager

Such a poser.

There has been a slight lapse in updates here, since we are now about to finish the project (or rather finish off what we're working on right now for someone else to continue) and we are currently writing our parts for the final report. Since we have run in to quite a few speed bumps along the way, we didn't manage to complete the whole project and produce a complete prototype, however a lot of the grunt work has been done. Hopefully we'll find the right place on the internet to upload all the code so that it'll be of use to someone else. We'll also post the final report here, so if someone's interested they can read it when we're done.

We were actually about to fly it again yesterday, however one of the motor axles broke and we have nowhere enough time to get another one, since the final presentation is monday which marks the official end of this project.

However, Albin has taken our little lovechild to a studio and taken some very flattering pictures, which combined with a few images from in-flight and a 3D-reconstruction made by Alexander makes for some nice presentation material.

Flying against a clear-blue sky.

About to land.

Studio pic 1, simply the copter.

The app started on a phone with the telemetry module next to it.

The copter with it's best friend the controller.

A fused 2D-mapping of an area outside the school.

The same image, but in 3D.

ArchCopter apping!

The Android app has gotten nowhere enough attention here on the blog, so it's about time we correct that! This is what greets you when starting the application:

ArchCopter app splash screen!

Progress has been steady and according to plan and Albin has produced a selling poster view of the app, seen below:

Promotional poster of the application.

What it does is that it takes asks the user to specify a polygon (the corners of the area in question), then it divides it into segments of appropriate width, then sets waypoints such that the whole area is swept.

Apparently the app should be ready for testing soon, and hopefully the copter will be up to the task. 

Testflight again!

So, after Jens cut down the print-time of the hexacopter from about 7 days to 3 with some smart redesigns we where ready to fly again! Since we only have one Raspberry Pi camera and don't want to crash it (yet),  we used a old digital camera and used some duckttape to attach it to our machine. It was a bit bulky and the video isn't that exiting, but it's still a video from mid air!

And here is the flight we where the camera was attached.

The flight after we noticed midair that we had forgot the antenna to the RC-controller. The magic here was that Jens quickly set the hexa to land (it can do that automatically) and somehow it got that command and did the best landing so far.

Me (Anton) and Alexander are working on the case for the RasPi and all the electronics, and hopefully the whole design including camera, gimbal and all the sensors will be easily attached and done in the end of the week.

Stay tuned!

Fatal flaw

Another video of a stable flight. 

Gonna try a backflip next time so that you won't get bored!

So, this is starting to become routine now: We assemble the copter, head out and make one very successful flight. Then we land and try to take off again only to crash. However, this time we had a fairly calm landing, but it broke nonetheless. After further analyzis, we realized that we have a very crucial design flaw regarding the current design of the copter. The small contact area of the crossbar in the lattice work is not enough to sustain the amount of stress we put on it, causing the layers to separate.

Layer separation.

Since it takes about 2½ hours to print one arm, I was not very keen on just reinforcing the bars, so this called for a completely new design, the fourth iteration of the arm.

Arm v4

It is printed in two parts, then rotated around the x and y axis creating a completely symmetric piece. It is also screwed together keeping the layers together, so layer separation should not be an issue with this iteration. Screwed together it forms an I-beam (http://en.wikipedia.org/wiki/I-beam) which is extremely tolerant when it comes to shear and bending loads. On the downside it does not handle torsion very well, but we havn't seen much of that to be honest. One major upside of the new design is that it takes a lot less time to print, one of the reasons being that you can print 4 parts (2 arms) at a time.. These 4 were printed after lunch yesterday:

Four of the new arms!

Since it is very long (18cm) it tends to warp while printing, but another benefit of the design is that since we bolt it together, the individual pieces align and become straight as an arrow!

It took some redesigning of the centerpiece aswell (not something we really wished for since the old one took 5½ hours to print, but since the socket has changed it is a necessity). I decided to make it modular (so that if it breaks, you can just change the parts needing changing) according to the same concept as the arms with two pieces per direction, as follows:

New modular centerpiece arms v3.

And it all comes together as below:

Centerpiece v3 assembled.

That is all from construction for now!

Dummy copter on a stick

The work on determining which speed we should fly at has begun. 

A number of factors must be considered; camera frame-rate, image blurriness. The more images of the same area the better the 3d reconstruction but at the cost of memory and time to compute 3d point cloud. 

Since the copter is waiting replacement parts and some code for the camera we conducted a simple test with the new dummy copter. (Its a smartphone on a stick...)

Plenty of duct tape was used.

By shooting a low res film and walking with the stick raised high to simulate copter flight at approx 3 m over the ground and then checking how the number of feature matches in the images decreased as distance between images increased. 

Since walking with a cameraphone on a stick 3 meters up did not produce as properly oriented and equally spaced pictures as as one would have hoped we should not focus so much attention on the result.

//Alexander.O

Good morning!

I'm glad to report that we are almost back in business, we have now printed all of the parts damaged in the fall, apart from the centerpiece. This has however gone through some changes that hopefully will not impact performance, but has reduced printing time from 8 to 5 hours. We have installed Teamviewer (A remote monitoring software) and a webcam on the computer connected to the 3D-printer, so now we can monitor it from our office. Or lab. Or whatever this should be called.

Screenshot showing the 3D-printing software along with the webcam stream from the computer. Here we recently started printing the centerpiece.

Today we have quite rainy weather here in the north of Sweden, but hopefully it will clear up after lunch when the centerpiece is ready, so that we can get it in the air again.


Emma also tested the reflashed GPS yesterday (We have started using the russian equivalent of GPS, the GLONASS) and is happy to report a mean error of 6m in urban setting. This is to be compared with the 15m that GPS gave. This is of course depending on how many satellites you are able to lock on.

She has also designed and printed a water-resistant case for the GPS module. I must say it is looking rather dashing with its plexi glass roofing!

GPS casing.

Nothing lasts forever

And some things last for a very short time indeed.
Yesterday we had the maiden voyage of the ArchCopter v2 and we had a very good first flight, as illustrated below.

First stable flight. First flight ever actually.

It is very sensitive, the smallest amount of throttle will send it towards the heavens like from out of a cannon, making the landings a bit hard, but the new and improved landing gears (as seen below) seemed to handle it very well!

New, jointed landing gears.

But, all things eventually come to an end, and during the last flight, we lost one of the motors in mid-air (one of the ESC plugs vibrated loose), causing it to spin out of control. This caused the hexa to start spinning around it's own axis, which in itself is not a huge problem, but before we were able to bring it down safely a strong gust of wind caused it to go belly up 10m above the ground. After that, needless to say, all we could do was pray for the electronics to survive. Which it did. Phuh!

We also caught it on tape for your amusement, enjoy:

And then there was silence.

Today has been spent salvaging the parts that survived, which turned out to be surprisingly many! Erik has also mounted the magnetometers on a couple of PCB-boards and soldered on plugs, as such:

Very fancy electronics.

Albin has not been idle either, as we can see below:

Screen dump of the main menu of the ArchCopter app. In swedish. Translated it says:

Connect

Trace flight

Scan area

Settings

About ArchCopter

The glorious return

Hello everybody, sorry to have kept you waiting for further updates but the lot of us (apart from Anton) has been on vacation. Now, however, the lot of us are back and production is in full swing!

So here's our updates, category by category:

Construction:

Chassi version 2 is assembled, including motors and APM!

Jens holding the assembled ArchQuad 2.0. Note that this picture is taken with the Raspberry Pi Cam!

We have had some issues with the APM (I think it's due to the new firmware released), but after clearing the EEPROM and wiping the APM and setting it up from scratch everything worked again.

We've also installed a custom battery in the 9XR (the controller used) and are now running it on a 7.4V battery from DFrobot (namely: http://www.dfrobot.com/index.php?route=product/product&filter_name=battery&product_id=437#.UgJDgpL0Eb0) and it seems to like it! Just remember to set the voltage warning according to the battery, otherwise it will beep like crazy.

Other than that, I (Jens) have kept busy with updating the document governing the project and helping the other member while Anton has been working on the cameras.

Plan is that we finish the landing gears today and go out flying tomorrow! If everything goes as planned, we will post a video here tomorrow!

Camera:

Anton has been struggling against the RaspPi cam requiring a bit larger current than the wall-socket->USB converter could provide, but once the issue was identified it was solved fairly easy. The RaspPi cam is now up and running, now it is just an issue of what framerate to use and how to save it to either USB memory or SD-card.

Demonstration image taken with the RaspPi cam. This image has not been Photoshop'ed. Promise.

Anton has also received an IR camera CMOS module as seen in the picture below:

IR cam module.

However it does not seem trivial at all to get it to work, so that's something Anton (probably in collaboration with Alex) will be working on in the near future.

Interface:

Fancy splash screen of our app!

Albin is working hard on the android app aswell and he's vaguely optimistic which is a good sign. Since a program is never really done, it's hard to define "done", but hopefully the program will do everything needed of it.

Sonar/GPS:

Most of this week has been spent dealing with the sonars and trying to get a feel for them. A case for them has also been printed, as you can see.

Sonar casing which attaches directly below the battery pack.

Emma has done some research regarding the accuracy of the sonars, and they are actually pretty good and can detect even narrow objects at a fair distance. Her next project is wallowing through the APM code and finding a good way of implementing five sonars.

Magnetometers:

Since Erik (see picture under Camera) has basically everything set up regarding the magnetometers, he has spent the week researching and defining the interfaces that we will use, i.e how everything will communicate and be supplied with power. Not an easy task, but has to be done nevertheless.

"Vacation"

So, there hasn't been alot of updates lately, I (Anton) took some vacation  from the project. There is alot of fun stuff to do with 3D-printers and I wanted to take some time for a small project on the side. This is the start of a rover-like vehicle. There aren't any tracks yet, as I haven't really figured out the best way to do them. But the idea is to take two of these, connect them with a center module with a battery and a arduino nano with a bluetooth dongle.

And it can drive!

Stay tuned for some updates on our Hexacopter!

Camera!

Hurray! Today we recieved our new camera for the Raspberry Pi (Many thanks to them!). 

Out of the box and connected it gave us this image. There seems to be some issue where the raspberry pi hangs when taking the picture but there has been alot of tinkering with files and drivers in the raspberry pi so a clean install should probably fix it.

The new chassis for the hexacopter is soon done. We decided to make it 2 color, orange and white so that we get a front and a rear on it. I must say orange looks really neat.

We are now sitting on a big pile of plastic that just needs assembly.

Batteries

The holder for the batteries are finished! This just screws into place under the hexacopter.

Another breakdown, our oldest 3D-printer just suffered from a PSU (Power Supply Unit) that broke. It was a old one, and a replacement shouldn't be much of a problem to find. Luckily the newest 3D-printer is going strong today.

=========== ADDITION BY JENS ===========

I must say that Anton did not disappoint in actualizing my vision for the battery bracket. Below is an image of the CAD sketch, I sense a certain resemblance!

Good vibrations!

So yesterday pretty much everyone went on vacation. So until Alexander shows up later this week, I'm all alone printing the remaining parts for revision two of the hexacopter. The printer felt it was ok to go on vacation to, it jammed it's nozzle pretty bad. Luckily we have spares so it was just 15 minutes to get it up and running again. In the quest of saving the old nozzle, Viktor that shares lab/office with us came up with a brilliant idea. A bath of acetone and some vibrations should get the old nozzle all cleaned out.

Fun things aside, this is a part of our new landing gear, and some of the plastics needed to attach them. Progress in the making!

Testing, testing

We are making steady progress with the new chassis, as you can see below. About halfway there to be able to mount the electronics and motors.

New parts! Woho!

The full status report of the chassis is as follows:

[CAD percentage/Printed/Total]

[100/4/6] Arms
[100/1/1] Centerpiece, lower
[100/0/6] Motor mounts
[100/0/6] Slanted arms
[100/0/1] Centerpiece, upper
[80/3] Landing gear
[0/0/1] Raspberry pi box
[90/1/1] Camera gimbal
[80/0/1] Battery bracket
[80/0/1] Sonar casing

So, as you can see, we have quite a bit of printing to do. Good thing is that since most of the parts have been designed already, we can simply start the printer and while it carries about it's business we can engorge ourselves in other tasks, with the occasional eye thrown towards the printer (Called Hilda btw) to see that she's not up to any mischief.

We've also set up a testing rig for balancing the propellers and the motors, so hopefully this will reduce the vibrations in the chassi and limit the unscrewing of bolts, blur in pictures and breakage of parts. Hopefully.

Test rig. All calculations point towards the vice being an accurate representation of the finished hexa. 

Really, I promise.

We've been looking in to the sonars for a while now and after a lot of googling, everything seemed to point towards MaxBotix. So, yesterday we placed an order at http://www.maxbotix.org. We've had a bit of correspondance with them prior to this order and I must say that they are really helpful! Also turns out that they have a educational discount which we could use. This was very fortunate, because still within the borders of our budget we were able to order 5 pieces of the MB1240 XL-MaxSonar®-EZ4™ and one of the MB1200 XL-MaxSonar®-EZ0™. We figure we will probably use the EZ4 in all directions since they have the most tolerance against prop noise and have the furthest reach. However this comes with a cost, since they have quite a narrow field of view which could possibly cause problems. We felt obliged to test more than one solution so we also ordered one of the EZ0 which has the widest field of view but in return the lowest noise tolerance. So, we'll test these and see if the EZ0 can function properly, and in that case we will probably order three more.

So, if you're in the mood for ultrasonic sensors or would simply like to keep track of what MaxBotix is up to, they've recently started a facebook page that you can like. 

MaxBotix Facebook page

The new centerpiece

A good 8 hours of printing was done yesterday, fingers crossed the entire time. We needed a new centerpiece for revision 2 of the hexacopter and it's a big print! It's the by far the biggest print on the entire hexacopter. It was also the longest print we've done on our new Mendel, a 3D-printer from RepRapPro. It came out really nice, no warping or anything bad related to the long print time.

The new centerpiece, this is where all the electronics goes.

The Gimbal

The recipe:

1 x 3D-printer (A reprappro mendel in our case)

2 x standard 9g servos or similar (we used servos with metal gears)

1 x Raspberry pi camera module

Part of the task of making a system for acquiring photos and video from a flying vehicle is the need to compensate for the vehicle's motion. A great way of compensating for this is to make a device that if our vehicle rolls right, this rolls the camera to the left to compensate and keep the camera steady and horizontal in reference to the ground. For different applications you want to compensate for different maneuvers, roll, tilt and yaw. What we want on our hexacopter is only to compensate for roll and tilt. This keeps our camera level with the horizon (parallel to the ground) and this is just what we need. The rest we can compensate for in software post-processing. The idea is simple, 1 servo per axis of rotation, using the inverted gyro signals from the APM (the chip that controlls the hexacopter) and feeding these to the appropriate servo.

We got a raspberry camera module which is lightweight and really small, we want to shockproof our gimbal a bit so we went for some beefier servos with metal gears. You could probably do this with a standard 9g blue servo, they are almost the same dimensions, depending on manufacturer.

The whole system consists of 2-4 parts. One arm from the first servo to the second, making them perpendicular in the z-axis, something to attach the first servo to our frame and something to attach the camera to the second servo. With the little CAD-experience i have I came up with the following design.

This is the main part, all you need more then this is a box for your camera and something that attaches your gimbal to the frame. It turned out really small and simple, takes about 1.5h total to print without the bit that attaches to the frame and the camera mount. The camera mount will be made when we get the camera so we see that it fits. The almost finished product looks like this, where you attach your camera to the bottom servo (pointing down towards the ground in our case) and the top servo attaches to the frame.

Aaaaand, she's gone

So, yesterday was eventful. Took the copter out for a stroll in the morning breeze and before you knew it she slammed headfirst in to a brick wall. Literally. One of the motor mounts cracked, five out of six arms snapped and we lost four propellers. The top junction was torn to pieces as you can see below. After picking up the pieces and heading inside we quickly stated that all of the electronics survived. And there was much rejoicing, yaay yaay.

Sad copter.

After spending most of the day supergluing the chassi back into a state that looked not quite as mangled (I actually think that we should be able to fly again) we quickly started printing version 2 of the chassi.

This collision gave us a few valuable insights:

1. The sockets used in rev1 cannot withstand the kind of strain we are putting upon them (This we already knew, rev2 has had this flaw fixed since long)

2. Layer orientation when printing is of the UTMOST importance regarding durability of joints and how/if it breaks.

3. It is important to be able to rotate around your own axis so that you know which end of the copter is forward. 

4. Nothing gets you working on a new design as efficiently as when the old one breaks.

We have started printing the arms for the new revision, the new sockets are looking really promising! They fit very snugly and the sockets passed the inoffial ArchQuad durability test. This test consists of two people, each equipped with a pair of pliers, grabbing one end of the piece each and bending it downward (or upward, according to preference) and seeing if it breaks. It did not.

Printing away. It's slightly cross-eyed but nevertheless happy to see you!

The new arm with improved sockets. Also a wee bit slimmer.

New arm with socket ends attached. One could hardly guess that this isn't one single piece.

We have liftoff!

So, this morning we installed all of the parts that arrived late last week. Flashed the ESC:s, charged the batteries and mounted everything on the copter and out we went!

A pretty windy day in the north of Sweden, sorry for the rather lacking sound quality.
Test run 1:

First time ever the hexa left the ground. However briefly.

Dubious results, as one can see. As the pilots choose to see it, the hexa did a backflip out of shear joy. It could also be slightly related to the fact that one of the motor controls made the motor spin the wrong way so it constantly tried to compensate and compensating only made things worse. The navigation system was also configured slightly wrong. So, back into the workshop and adjust these minor flaws, and back out again. This time, in addition we tried to find a place with slightly less wind.

A slightly more stable flight.

This time things went better. In this video, Erik is the pilot. He swung by to watch the ascent and just like that got to be in charge of it. The watchful observer will probably note that some (most) of the landing gear is missing. By this time we had had a couple of hard landings (Due to the wind, of course!) but slowly getting the hang of it! This also showed a couple of weaknesses in the design, which we choose to see as a very good thing at the prototype stage.

Delivery!

Here we go! The batteries and the new ESC's have arrived, so on monday we will hopefully mount everything on the hexa and around the middle of the week, all fingers crossed, we will have liftoff!

New batteries and ESC's!

We will keep you posted!

Raspberry Pi Camera Module

Wow, great news.

Earlier today i emailed Liz at http://www.raspberrypi.org/ and told her about our project and that the camera that they have developed would suit us perfectly and she thought it sounded very interesting. She has agreed to send one of their office cameras to us for the hardware cost. I just got an email from her colleague Emma saying that they will post it tomorrow.

I'm at a loss for words, this is really amazing!

An enormous thank you to raspberrypi.org, we will be sure to update the blog frequently and we assure you that the camera will be put to good use!

//Jens

Up to speed

So, since we have been working on this project for about three weeks already, we quite a few things to share. Brace yourselves, it will be a very long post indeed.
It will probably be simplest to take them as they are divided within the project:

I want to add: When we move from early test stage to something actually useful in this project, everything will be publicly available.
So all the CAD files, all the code and all the conclusions will be free for everyone to use, contribute to and study.

- Project management (Jens)
Time spent mostly keeping in touch with external resources and making sure everything goes according to plan. A lot of the time has been supporting the other members and making sure that they have what they need in order to be able to continue in their work with as few speedbumps as possible. With that comes the task of ordering supplies and making sure that the budget is kept.

- Interface (Albin)
Using DroidPlanner (OpenSource Android app for UAV managing) and changing it to fit our every need he aims to make the planning of the mission as simple as possible without losing any crucial options. Not an easy task. The software communicates through a telemetry module at 433Mhz, connected to the phone's USB port. However, not all phones are able to provide power for the telemetry module, so a custom OTG-cable (USB->micro USB) with external power had to be constructed.

OTG cable with external power supply.

- 3D reconstruction (Alexander)

Our first idea was to try and use a Kinect or equivalent in order to get a reading of the terrain. It was however noted pretty quickly that this is not an option outdoors. This since the the Kinect uses an IR-cloud of points in order to recieve a matrix containing depth data, but IR-spectra is fully saturated already. In order words, it's like shining a flashlight during a really sunny day, nothing much happens.

It was then decided that we use fotogrammetry (a lot of input and help with this (and not only this) has come from Jonas Bohlin and Mattias Nyström at SLU) and hence cooperate closely with Anton in the camera part of the project.

On hold until Alexander returns from Skåne.

- GPS and proximity detection (Emma)

The first tests with the GPS (We are using a u-blox lea-6h) were very discouraging since the error was around or above 5m. The GPS coordinate is used in order to help the 3D-reconstruction so that the software knows where the picture was taken. Here we got some help from the russians, though. They have during the last few years launched satellite after satellite in order to construct their own version of GPS, named GLONASS (Globalnaja navigatsionnaja sputnikovaja sistema), which we swedes can freeride on. So, said and done; the GPS module was reflashed into a GLONASS module, and after taking a stroll it was confirmed that the coordinates were more or less spot on.
We are thinking of using the MB1240 XL-MaxSonar®-EZ4™ for proximity detection in +x, -x, +y, -y direction, but some further research has to be done in this area.

- Magnetometer (Erik)
In order to find out if the motors affected the magnetometers an oscilloscope was brought (courtesy of the University) in and an analog magnetometer used. After building an amplifier circuit and still seeing no output on the oscilloscope the test was rendered inconclusive and we decided not to trust the analog version. We took a leap of faith and ordered digital magnetometers. We hence ordered 2 units MicroMag 3-Axis Magnetometer (together with an Arduino mini) from SparkFun.

- Camera (Anton)
A lot of research has gone into this part of the project, since it is the base for a lot of the collected data. It was pretty obvious that we would need a Raspberry Pi that would act brain and to which the magnetometer and GPS would send their data to be recorded. This gave a lot of options as far as interfaces goes. We have USB, I2C and also the option to buy a CMOS camera module and connect it to an Arduino with a processing shield. A small program was constructed for the USB webcam we had borrowed (Logitech C910), but the Pi could not power two of them. A USB hub with external power supply was brought in as temporary solution while we ordered USB extension cables which could be modded for external power. This was simply done as such: Cut the cable in two, solder the data cables (white and green) back together. Solder the ground back together with an external ground lead that goes to minus pole of external battery. Cut the +5v (red wire) of the male end and insulate it. Solder an external lead that goes to plus pole of external battery onto the red wire coming from the female end of the USB. Done!

USB cable with external power.

The FPS however was not great, we got around 4fps with one camera. According to the Pi community this camera has some compatibility issues, which was apparent since errors appeared on each initialization of the camera (even if it then proceeded to take pictures). Apparently this camera hogs ALL the USB bandwidth, so two cameras is not an option, and even with one, the USB of the Pi is not enough to allow for 1080p streaming. There is also a Raspberry Pi Camera Module that would suit us perfectly, but it is on backorder in every shop imaginable and estimated time of delivery is around 10 weeks, which is not an option.

Recently got the servos ordered though, so now a draft for a pan-tilt mount (So that the camera is always looking straight down) is being done in CAD.

- Construction (Jens and Anton)

Since Krister (one of the administrators of the master program in engineering physics) is very involved and keen that the students have access to relevant technology and want us to be cutting edge, he has through different channels acquired a few 3D-printers that we are free to use in this project. 

3D-printing one of the motor mounts.

This has been a tremendous help for the construction. Since we are used to running simulations of things, there was no reason why this would be an exception. All the simulations made are done in COMSOL multiphysics in order to try strain during rotation and flexing.

Example of a simulation with rotational stress in order to determine weak points.

So, we started printing. This is slow business, so we spent the better part of two weeks printing the prototype. Anton serviced the 3D-printers and Jens made most of the CAD sketches for the upcoming parts. 

One of the arms between motor mount and centerpiece.

Two complete arms including motors.

Centerpiece (this took about 7½ hours to print!)

Landing gears.

So, the final prototype now looks like this:

ArchCopter v1.0

We have a slight problem in order to get liftoff however. Full of optimism, we ordered 6 ESC:s (motor controllers, Turnigy AE-30A btw), but according to various forums we were strongly recommended to flash them in order to improve stability and battery time. This did not look easy at first look, and seemed to require a lot of extra equipment, until we stumbled across OlliW's guide, where all you need is an Arduino (which everyone has lying around, right?) Strongly recommend it:

http://www.olliw.eu/2012/owsilprog-tutorials/#programmer

BUT! Make sure you have the right firmware selected. Something we did not double check and hence we fried one of the ESC:s. So, we are now waiting for delivery of another (And yes, we learned from our mistakes and order two so we now have one spare)

We have also built a box where all the electronics (APM2.5 used for navigation, Orange RX for radio control and the corresponding telemetry module that matches Albins) sit snugly that will be mounted within the temple-like body of the copter (for protection).

Electronics box

We have, in spite of our troubles with the ESC:s been able to run a simple motor test:

Motor test 1.

I've tried covering everything in an appropriate amount of detail, but if you feel that there is anything missing, feel free to post here or email at ArchCopter@gmail.com