I almost lost my Skywalker today after making adding dual rates to my radio. Originally I had 60% rates on both manual and stabilised flight modes, but I found on stabilised flight it was very sluggish, but perfect on manual. So I set 100% throws on stabilised flight which as I found out is way too much.
A few minutes into the flight, on turning crosswind it went into a spin. Probably induced by too much elevator and aileron.
I recently picked up a dragonlink Tx and two Rx. One for the EasyStar and one for the ACM.
Had a great maiden a couple of days ago with the DragonLink on the ACM, so I decided to hurry up and get the other Rx in the ez*. I also knew that I always faired better with 2.4Ghz reception on the ez* than the ACM, so I decided to go ahead and mount the GoPro up, and put it on the line. The ez* is the old style AP with thermopiles. It was *really nice* to have failsafe on the 9x now. The RTL works as expected.
Even caught some lightning.
The DragonLink is a big confidence booster for me for the regular old close in flying, and was an easy install into the Turnigy 9x. I used these pictures.
Here's what the Tx and 12 channel PPM Rx looks like. I'm obviously a big fan so far.
Just missing the FPV goggle part of the equation. Going to be a while!
JC
http://labs.autodesk.com/utilities/photo_scene_editor/
Very interesting technology with lots of possibilities. The demonstration subject should also be well known for most of us. My own limited testing show that quality of results vary greatly. Has anyone tried using photos taken with a UAV yet?
Technology with entertainment factor – this is the principal object of project Paraswift. During one year we develop a wall climbing robot, which doesn’t just climb down again after it reached the top! Instead, it opens a paraglider, drops off the wall and lands safely in front of the surprised audience.
http://www.suasnews.com/2011/09/8027/base-jumping-robot-paraswift/
I've got broken rc hummer2 from a friend as a gift, when he learned that I do drones. After some time I fixed it and tested =) Hehe, drink and drive - legally! (do not try to repeat! LOL)
But without ardurover for now - APM is in my plane =) Just FPV car. Also it uses plane ESC, so car can move only forward.
In case my plane get lost in the wild :-D I've made some stickers with contact info, so if found - it can be returned.
As far as I know not all of us have color laserjet printer. And inkjet prints usually get blurred when soaked in water. In my case, my inkjet have black ink as pigment type of ink, which is waterproof. But if you like - feel free to change it.
Here is jpg demo and psd template.
Here is my memo: How I make camera launcher from old servo electronics, usb-cable and diode.
Here are quite many steps, so I write this memo if I need to make system again... Programming took only few minutes, to build circuit took more time.
My camera is Canon PowerShot S90
More details http://chdk.wikia.com/wiki/CHDK
This same page in Finnish
After a long arduous process of getting my copter up in the air, it finally flies. I was happy with it for a week or so but am now unhappy with the CD Case body/frame that I'm currently sporting. So I decided to design a frame that was perfect for my needs.
I did all the work in AutoCAD(sorry about the colors). It's a mashup of my own design and the official Arducopter design, among others.
First up I have a Quad & Hexa version. These main plates (as I call them) are the foundation of the frame.
Next up I have the carrier plate...this gets stacked on top of the main plates and the APM gets mounted to it.You'll notice the similarity of the slots to the official Arducopter design...
On the bottom of the main plate I have my battery tray.
Stacked up, it looks like this.
I use all #6-32 screws with varying lengths. I also use vibration isolators for the APM & Camera mount(more on this in another post). To finish it off I'm going to cover it with a 6" Diameter acrylic dome on top.
The arm grips.
I have all this mocked up in laser cut acrylic and am trying to find someone to cut out the final pieces in G10. I don't have a CNC router and am trying to cut them freehand, but it's proving to be very difficult. I am planning on building a CNC router at some point, just not yet... More posts to follow with more pictures of the mocked up frame and my freehand attempt of the final version.
Hi Diy'ers
Thought I would share my latest Project with you, and keep a running log of our progress. Your comments and suggestions are most welcome!
The Team :
Wessie van der Westhuizen a.k.a Clowns Hobbies
Gustav Kuhn a.k.a Groundpounder
Dave Thomas a.k.a Darth Vader
The Mission :
To build a UAV capable of a payload of 5Kg, to stay in the air for 1 hour.
The Equipment :
Airframe : Lanyu Primary 100, wingspan 2.54m (100")
Engine : E-Flight Power160 engine (will eventually be a 50cc Gasser)
Batteries : 4 x 4400mah 5s Lipo wired to 10s 8800mah pack
Prop : 22 x 8 wood
ESC : Hobbywing 100A HV
Servos : 6 x 9kg Digital Savox servos
Radio : Spektrum DX8 2.4GHz
APM 1280
Xbee Pro 900Mhz
GoPro Camera
5.8GHz Video TX/RX
15" Video Monitor
Toshiba netbook
17" Monitor
250A Deep cycle battery
1500W Power inverter
4 Port Quad charger
lots and lots of wires ;-)
We fitted Rubber anti-vibration mounts for the Gas engine, when we changed to Electric it made mounting the motor easy, so we left them on.
Not show on this picture, is that the APM is mounted on 2 Layers of Align Gyro Gel.
The Batteries go into the front hatch compartment, the other battery you can see is a 3 Cell 3000mah pack that powers the Avionics via a 8A Hobbywing Regulator, and the Video TX directly.
You can also see th 6" Dubro inflatable wheels we fitted so we can land on just about any terrain.
Our Ground Zero is a nifty foldable table and seats, Easilly transported.
Our second test Patform is the ST Models discovery. This plane has proven to be a Brilliant choice for UAV work. It flies the waypoints REALLY well with the stock PID setup.
Both Planes are fitted with downlinks. At some point we will get some SkyWalkers for comparison.
We Fly at Two Sites in SA. For safety reasons we ALWAYS fly at registered flying clubs.
This is the discovery mission in 20km/h wind. Hope to get Big Bertha to follw tracks like that as well soon.
This is the mission we are running at the moment with Bertha. All waypoints are 100m AGL
2011-09-04%2009-36-37.tlog is the Results for last weekends flying. It contains TWO missions, but enough data. You will see that I need to do some PID tuning here, as well as move the Pitot-Tube away from the leading edge of the wing, where it is getting weird readings in the turbulent air as it seperates.
Below is the RESULT of the last mission. The aircraft successfully hit every waypoint - eventually, sometimes after some considerable waypoint hunting.
Well, thats a start, let us know what you think, We will add more info as time goes on.
regards
Wessie
Lots of housekeeping notes:
1) ArduCopter 2.0.40 is now live in the Mission Planner and for download. This is by far the best ArduCopter yet. You should see much better Altitude Hold, Loiter should stay in a 1m box, RTL should be an awesome line right back home, Waypoints should be on rails, Camera stabilization works better, etc. Upgrade now! (Remember that you must go though the reset/setup process again in the Mission Planner. A full post on the changes coming soon...
2) There's also a new version of APM in the Mission Planner (It's still showing as 2.23, but we'll increment that display to 2.24 shortly) as well as for download. This fixes all sorts of subtle bugs, including EEPROM corruption, memory overflows, Xbee bricking, etc. You really want these--trust me. Remember that you must go through a board reset/setup again after loading the new code.
3) We've migrated our code repository from Subversion to Git. It's still on Google Code, but if you've been pulling code from the repository, you must now switch to a Git client. All the code is now in the APM repository as explained below. You can see the directory structure here. A guide to using Git is here.
4) As part of the repository reorganization we're doing some cleanup of our branding. From now on, here is the way the project is organized:
The hardware platform and overall project is called ArduPilot Mega.
The Git repository reflects this organization.
Phew. There's more but I'll save that for tomorrow. We've been busy!
This is a special version for aerial photography. On the plane there is a stabilized camera.
Here is the camera stand. Guess what is the weight of it? ;-)
I have also made additional code to APM, so I don't need a computer to make flight plan. The procedure is following:
I go near the target I want to photo. I press "Locate" button and switch power on. The Ardupilot now waits until it has good gps fix, and then makes automatically flight plan around this place. Then I can switch off the plane and walk to a good starting and landing place. There I again switch plane on, wait gps fix and throw plane to flight. Plane makes three rounds around the target.
First round radius is 250 meters, next 200 and innermost 150 meters. Altitudes are 80, 70 and 60 meters. There are two checkpoints, 1 and 2. Plane should first go to northeast then turn to left, and after that turn to north west. If plane does not do these curves, there may be something wrong with the flight plan, and it is probably best to call plane back.
I have made Canon CHDK system to camera, and I can launch it with remote control channel 5 switch. Normally I take photos all the time. After flight I have 150 - 250 pictures, and probably at least one of them is good :-)
The Locate button is simple circuit. Normally AN6 is connected to GND with resistor, so the voltage is 0V. If I press button in the start, the voltage is 5V, and program goes to special subroutine that calculates this flight plan.
I have not tested this, but it would be easy to add more predefined flight plans to plane. In this draw there is Locate button and knob selector. If user does not press button, the AN6 is zero. If user press button, then those resistors are voltage dividers, and AN6 is something between 0V and 5V depending on knob position, and program can branch to desired subroutine according to the voltage. For example one of them may be subroutine to take orthophotos from square field.
The code for flight plan? This program writes coordinates to Eeprom, and I am not familiar with those details. If someone who knows code can check it and then share it?
Code for camera stabilizer is here
Here is an example of photos.
The third installment from GE's adorable Air Show ad campaign.
http://search.digikey.com/scripts/DkSearch/dksus.dll?pname?site=us;lang=en;name=ATAVRSBIN1-ND
This is an interesting board - perhaps most interesting is the approach to driver-based sensors in the datasheets.
On August 12, electrical/aerospace engineer and helicopter pilot Pascal Chretien took to the air in the world's first untethered, fully electric manned helicopter flight in a prototype machine that he designed and built almost entirely by himself within a 12 month development period. In his 2 minute, 10 second test flight, Chretien beat aviation giant Sikorsky into the record books - but it was not without significant risk. As the man himself puts it: "in case of crash I stand good chances to end up in kebab form."
This week's Meet the Developers series starts out with Roberto Navoni, who leads the Foxteam group in Italy that have been doing amazing things with multicopters. He's one of those guys who can do it all: hardware design, software, sensor analysis and business leadership. He is also one of the DIY Drones team members who appears to be able live without sleeping (or at least I have no other explanation how he can be so productive with a big day job and three small children).
You know him best here for the APM-compatible Multipilot32 autopilot board, which combines the APM IMU shield and ArduCopter code with a 32-bit ARM processor. It's a great port and a bridge to the 32-bit world for those who want that now.
Name: Roberto Navoni
Home: I live in Italy in Calcio in the province of Bergamo, 60 km from Milan, with my wife Elisa and my 3 children: Federico, who is 4 years old, Francesco is 2 and a half and little Sofia is just 1.
DIY Drones role: In the project I worked on the development of 32-bit cpu board, in particular on Multipilot32, a board with same shape and pinout of APM but with STM32 micro controller instead of AVR
I have been personally involved multipilot32 of the electronic design of the card, porting and integration of APM librarys on STM32 and porting the ArducopterNG and now Arducopter 2 firmware.
In the most recent versions of the software, I implemented the management protocol that allows PPMSUM on a single strand of up to 12 channels and a Arducopter mixertable for that.
Day Job: CEO of Laser Navigation, which develops 3D GIS applications for command and control center for operational safety and emergency fleets of ambulances and police. The company was started by my father, but due to his untimely death in a plane crash in 2004, I became CEO.
Prior to that, I served as head research and development and over time I got to deal with several projects in electronics and computing. I worked on the development of electronic satellite tracking, remote control and metering systems, video compression H.264 format. I developed a cartographic system in 2D and 3D long before Google developed Google Earth. Between 2000 and 2004 I also worked on systems for automated trading systems creating a platform called Zeus.
Background: My experience in electronics and software start in 1982, my first computer course I did at the age 'of 8 years. was my first computer the VIC 20, then the Commodore 64, Amiga 1000 before moving to the PC and just recently in the last 5 years I bought my first Mac which made me very happy.
When I was 10 years old I programmed in Basic and at 12 developing the first computer course for my classmates. I learned English by reading the manuals of the Amiga and C64, which were available only in English.
At 13, I developed my first program on behalf of the company my father used to manage safety system for security of mountain roads . The program was entirely written in Amiga Basic:) At age 14 I learned to program in C and bought the famous Bible of the 'C', by Kernig and Ritchie:)
Since then, it was love forever ... ..my first software development was a GIS for the control of trucks fleet by GPS systems. The GPS was in its early stage Garmin receivers were used the first single-channel scanning and society 'my father realized the first satellite alarm system with GPS Garmin, a Motorola 68HC11 CPU and Hacked Mitsubishi Etacs cellular phone.
My role was to develop software for the operations center, the first version of the software ran in DOS on a graphics card TSENG4000, I studied the register of the board, and developed a system capable of loading maps in PCX format and display the position of the vehicles carrying the first tracker made by my company.
At 16 I developed my first micro-processor board. My first microprocessor was the Siemens 80c166, a beautiful 16-bit micro C program development systems Keil. The code was loaded on a epprom and every time I had to delete the program and reload a new one had to put under UV EPROM ereaser and then proceed to reload. Flash memory did not yet exist :) All this I did during summer vacation and even during the school if the company needed my help.
After high school, I went to university to study Electronics Engineering, but unfortunately the things I was going to study already knew. So then switched to of philosophy, something I had fallen in love with during high school and which helped me a lot in certain moments of my life. My favorite philosophers are Nietzche and Hegel.
Interests: I learned to fly sailplanes at 16 years old and flew them for about 10 years. Then I switched to sailboats and now I have a boat licence and like a lot going in to sea with my friends with sailboat :)
Other interests:
--Electric cars (I have a Toyota Prius)
--Green energy: we are working on a stirling motor in our lab.
--Opensource project and community: I support with the openstreet map community and some other linux projects.
Above: Concept for an "abstract layout" workflow that could reconcile open source circuit designs with "closed" process design rules and libraries. First the designer would generate an abstract layout by instancing cells for various components. The above example shows a 2-input AND gate, with one input pulled to ground with a 10k resistor, and a tri-state buffer as an output. The designer would instance these cells, and then route connections between them. The designer would also place cells corresponding to "pads" at the periphery of the chip. The designer would not need to know the exact layout of the cell interiors- this may be kept "closed" even while the abstract layer itself is "open". This abstract layout may then be converted to a full detailed layout that may be used by a foundry to fabricate the chip.
Introduction
This is the second part of a three-part blog posting on chip design and how to reconcile it with the open source and DIY movements. Previously in Part 1, I gave a top level summary of “indie chip design” as I experience it. In this part I will discuss the real issues I would face if trying to “open” up a chip design. There are three areas to consider: the CAD design tools themselves, the design rules for a particular chip fab process, and design libraries.
First a few definitions: The term “foundry” refers to a company that performs the actual chip fabrication. The term “process” refers to a particular fabrication line of a foundry. A foundry may have several processes including ones optimized for digital circuity and others designed for analog. Typically a foundry will have several grades of processes, with more expensive ones having more capabilities or a smaller feature size. The term “design tools” refers to the CAD tools that one may use to design a chip (analogous to Eagle for PCBs). The term “design rules” refers to specifications such as minimum width, spacing, and other requirements for the different layers.
Chip Design Tools: Open source versions do exist!
First I present some good news- Open source chip design tools do exist. One of the most prominent versions is Magic, which was created in the mid 1980’s and has gone through multiple revisions as late as 2008. I personally used versions 6.4 and 6.5 for all of Centeye’s chip designs from 2001 through 2004, including designs with up to 400,000 transistors. Magic is somewhat derided by many chip designers because it automates the generation of some layers and restricts you to purely Manhattan geometries e.g. no diagonal features. However in practice these restrictions affect only a minority of overall chip designs and do not cost much in terms of layout space. Magic has a real-time design rule verifier- you will know pretty much right away if your layout has violated a design rule. I found this useful when first learning chip design. Magic is also able to create CIF and GDSII files, the chip design equivalent of Gerbers used for PCBs.
Magic was originally designed to run on Unix and Linux operating systems, but it has more recently been ported to Windows (using Cygwin) and is maintained here at Open Circuit Design. Unfortunately it appears that recent development efforts have slowed, so I am not sure if Magic is as actively used as in the past.
Other open source layout tools exist as well, for example Electric. There is also a free, but not open source, tool called Lasi (pronounced “lazy”).
For circuit verification there are also free circuit simulators, most notably the venerable SPICE.
Commercial chip design tools exist as well (if you have the money...)
There are a number of commercial design tools available as well. I now use Tanner Tools, while others (with more resources) may use Cadence or Synopsys. The cost of Tanner Tools is within reach for a small company (on the order of the price of a new car- depreciation is my friend!) but is out of reach for most hobbyists. The other latter tools can cost, as far as I know, a upwards to a million dollars per seat, but allow wide-scale cooperation between large teams of designers.
As for why I switched from Magic to Tanner- Around 2005 we were migrating to a new foundry and process and were anticipating designing more complicated chips, so I felt the need for something “professional”. Tanner Tools has worked very well for us. However- and this would be a good story for another post- we succumbed to “complexity creep”, thus producing complicated (and headache inducing) designs, but later reversed course, so that now are designs are more minimalist again. I could go back to Magic, however since I now have the Tanner and have built up my own libraries within it, it is easier stay with Tanner. There are also other issues, which will be discussed next.
The bad news: Design rules, setup files, and design kits are generally not open.
As I see it, the biggest issue preventing bringing open source to the chip design rule is not the design tools themselves, but the design rules! The design rules on a PCB are relatively easy to set up and for programs like Eagle are freely available. They are also easy to understand. For chips, however, the design rules are generally treated as proprietary by the foundry. This is because the design rules contain information that describes the capabilities of a process, and the foundries don’t want that information freely disclosed without restrictions. Yes- I had to sign NDAs to get the design rules for all of the processes we use now! Similarly, the “setup files” that design tools use to configure a design program for designing chips for a particular process are also generally treated as proprietary by the company that sells the tools.
The same applies to the “design kits” themselves- these are basically library files that contain cells for different subcircuits you may want to use in a chip design. This includes cells such as gates, flip flops, or basic analog components. This also includes essential cells such as the “pads” that allow a chip to be interfaced with the outside world.
And this, folks, is why we cannot open source our chip designs- I would be violating all the NDAs I had signed with these companies! The most I could do (which I have already done in one case) is to release a schematic of the chip, in PDF form, that contains details on the circuits I had designed, and then “black boxes” for anything that came from a design kit.
Overall the trend seems to be for new advances to be made in the “closed” world, with open design tools and design kits being increasingly obscure and obsolete.
Is there a workaround?
I can see two possible workarounds. One method is, in fact, a workaround that has been used in the past and (I believe) is still available to an extent. The other is one that comes to my mind. Both would require some level of cooperation from the chip foundry.
Workaround #1: Use simplified, genericized design rules
During 2000 through 2004 when I was using Magic, I also used the MOSIS service for chip fabrications. MOSIS is effectively a brokerage service that places different designs from different people onto the same wafer, thus allowing everyone to share the tooling costs. (I’ll talk more about that in Part 3 of these posts.) When using MOSIS, you had the option of using either the design rules from the foundry (requiring an NDA), or you could use more generic design rules that MOSIS set up and made freely available.
The MOSIS rules had the advantage of being a bit more transparent and easy to understand. Also a design made for one process could be fabricated on any process that supports the same design rules. However they had several weaknesses- First, designs made using these rules are not a compact as they would be using the native foundry rules. In practice this penalty would be small, on the order of a few percent at most. Second, the MOSIS rules may not allow you to use all the features that a particular foundry or process supports. Third, the MOSIS rules are compatible with only a few processes- A look at the MOSIS website reveals that these rules are usable with two foundries. If you are willing to be constrained to just these two foundries (and both are good!), and if you don’t need some exotic unsupported feature, for most designs this approach will work.
The same concept used to make these MOSIS design rules can be applied to other foundries. The only barrier is obtaining the cooperation of the foundry, who may not want details of their process revealed openly or simply may not want to spend resources supporting an additional set of design rules.
Workaround #2: Use an intermediate abstract layout
The second workaround would be to set up an abstract design layer that is more detailed than “schematic” but less than that of “layout”. I envision something like what is depicted on the top of this post- A designer would create an abstract “layout” that instances cells such as gates, pads, or individual discrete components. Each of these cells would have a number of known “ports”, including power/ground lines, inputs, and outputs. For example an “AND2” gate may have two power ports (ground and power), two digital inputs, and one digital output, while a capacitor or resistor may have just two ports. Some cells, of course, would be the pads that allow the chip to be connected to the rest of the world.
The designer would not need to know the specific layout of these cells or even their exact circuit diagram, but would need to know enough to use them in a design. The designer would instead have several page (or more) datasheet describing everything needed to use that cell. For example, it might be known that the AND2 gate requires 5ns to settle and can source up to 10uA of current, or that a specific capacitor cell holds 1pF but has 0.1pF of parasitic capacitance at one node. The designer could then create an abstract layout by dropping these cells at various locations on the chip, much like a PCB designer places “parts” on a circuit board layout. The designer could then draw the wires to connect the components together. Such a design tool could have autorouting features. The design tool would then perform basic design rule checks.
Once the design is complete, this abstract level design file would be exported and sent to either the foundry or a “middle man”. The foundry or middle man would then be responsible for generating the final layout files from the abstract layout. Finally, the foundry could fabricate the chip.
The disadvantage of this approach is that the design is still only “partially open”. However at least the abstract layout could be made “open” and freely shared or released with appropriate open source licenses as desired.
There would be another benefit to this approach- The workflow would be more similar to that of making a PCB, in both the steps taken and the complexity. This approach would make chip design more accessible to a “casual” chip designer.
In my next post, I will discuss economic issues associated with chip fabrication.
Project date 2002-2006 Completed
Wing Span 12ft
Weight 60-80kg
Engines tested were : 342cc boxer, 500cc boxer, 298cc Wankel Rotary
Max speed achieved was 400kph level flight with 298cc Wankel rotary engine
Launcher also took lot of time to develop
Landing bally or parachute
Autopilot did with electro-mechanical gyro with gps and pressure sensor.
Above photo is of final version and videos are from early testing / developing versions.
Technically this is 3 frame with camera but the first one was hard to control, weight of GoPro with skeleton cover was too much for weak motors. 2nd one was stock ACM but ended in a crash with v39. Finally this was the only frame/setup can last long enough for me to take a video.
A lot of vibration issues as expected since I removed the dampers. Video was wobbly with the high density foams I used. Another thing is the servo most of the time it over corrects causing the bobbing of the video. Of course a few more tweaking on PIDs but all in all its getting there just like to share.
WARNING: Can cause dizziness
With the wind suddenly picking up I had to go back to stable mode to decent but roll/pitch can barely compensate for the wind. Nothing was damage just landed sideways :D.
ACM2.0.38
All_hold 2:20
Loiter 5:22
