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:
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
No comments:
Post a Comment