All Posts (14036)

Sort by

first blimp concept

I'm trying to create a blimp with ~50" envelope that can follow a moving target (a person) in a large open area with presumedly standing air conditions.going to plan this around the arduino boardInitial worries are:-the velocity of the target (this can be controlled to some degree, ie: area has distractions)-lag time of blimp will play a big part. Am thinking of integrating a buffer zone around target.-tracking system. I'd like to use active RFID (who knows) or could resort to ultrasonic. The ultrasonic/infrared combo looks real nice. Would like to stay away from just infrared for main tracking (this is still very rough). Probably use infrared or ultrasonic detectors for structural coordination.this blimp is supposed to be in a gallery or some other area with the intent of following one random viewer. A more complex model would pick the target using some form of video analysis. This is out of my scope right now.Ideally I would have the canopy resemble a cctv camera box. This piece is designed to play up the invasion of privacy of technology.still needs lot of work
Read more…
3D Robotics
Most autopilots have the ability to read signals from a RC receiver and drive servos. For instance, in the case of ArduPilot, we read the current throttle setting when the autopilot is engaged (so we can maintain that setting, although we'll later nudge it up and down to maintain altitude) and we drive the rudder servo and ESC. In the case of BlimpDuino in RC mode, we read the throttle and left/right commands from the RC receiver and translate them into commands to the motor drivers (the vectoring thruster servo is connected straight to the receiver and doesn't have to go through the autopilot at all). In Arduino, you read RC signals by using the PulseIn command, and you drive servos with the servo.write function added by the servo library. The problem is that PulseIn waits for the next pulse, and the more channels you're reading the more time your CPU is spent waiting. A good rule of thumb is that each PulseIn, without modification, takes about 30% of your CPU time, so you can see that about two channels is the max. However, the form of the function is pulseIn(pin, HIGH, timeout) and you can adjust "timeout" to minimize the waiting time and improve that effeciency. I've been playing around with 50000 (it's in microseconds), but your mileage may vary. Anybody having better luck with a different value? Anyway, if you want to see how this works, here is a simple demo that just reads two RC channels and mirrors the commands with two servos. It's just like regular RC, but it's all going through the Arduino (so it can take over and go into autonomous mode anytime you want). Just read the comments in the code and plug the RC channels and servos into the right pins in your dev board (a Decimila and ProtoShield--don't forget the breadboard--work great). Here's a picture of my setup:

Read more…
Developer
Intercept the PPM signal is the best way to obtain all the channels from any receiver, for a lot of reasons. The first one is performance, and the second is the simplicity (in code =P). This hack is based on this tutorial from Paparazzi Autopilot.For more information about the PPM frames click here.For this hack i'm using a Futaba receiver FP-R127DF. Almost all the Futaba receivers came with the BU4015BF Shift Register chip, if your are able to locate this chip, you just need to solder a single wire in the pin 1 or 9 (clock), and you are done!Here is the Data Sheet of the IC:BU4015.pdfAnother good way to find the PPM signal pin is using this code with arduino:void setup(){Serial.begin(57600);pinMode(3, INPUT);}void loop(){Serial.println(pulseIn(3, LOW));}Then upload the code to arduino, and with a wire connected to the pin 3, start touching all the pins and spots you can of you receiver (don't forget to also connect ground to ground), until you see random values between 300 to 9000 on arduino terminal (that means you found it).After that, just solder a wire on it and use this code to decode all the channels:#define channumber 4 //How many channels have your radio?int value[channumber];void setup(){Serial.begin(57600); //Serial BeginpinMode(3, INPUT); //Pin 3 as input}void loop(){while(pulseIn(3, LOW) < 5000){} //Wait for the beginning of the framefor(int x=0; x<=channumber-1; x++)//Loop to store all the channel position{value[x]=pulseIn(3, LOW);}for(int x=0; x<=channumber-1; x++)//Loop to print and clear all the channel readings{Serial.print(value[x]); //Print the valueSerial.print(" ");value[x]=0; //Clear the value afeter is printed}Serial.println(""); //Start a new line}This a video where you can see everything i explained in action:
Read more…
what i was trying to do was to put some sort of transmitter inside my plane, and while in flight, it would transmitt my UAV's position to some sort of monitor which would show its position on the map. this way i would know exactly where i am while flying by a FPV( First Person Viewing sys.) or something similar. hope this clarifies my system description. if you know how to set this up, please help, thanks
Read more…
3D Robotics

New ArduPilot boards

We're making good progress on ArduPilot, the Arduino-based open source autopilot, and Jordi's just finished an improved version of the board, along with a new surface-mount version for those who care about size and are extra handy with a fine-point soldering iron. The new version of the through-hole board corrects one error on the previous version--a diode was in the wrong way around--and adds a better layout, better connectors for the receiver and servo cables (Samtec right-angle connectors) and the GPS, and clearer labeling throughout. You can see the PCB layout above, and buy the board here. Eagle 5 files are here: ardupilotBETA.sch and ardupilotBETA.brd The components you'll need are these:

I'm working on the Autopilot code now, and should have a beta in a few weeks once I've had a chance to test it. I'm starting with a port of the Basic Stamp autopilot, but this board is designed to do much more, so we'll be coding in new functionality like the ability to read a barometric sensor for altitude control and read the FMA Co-Pilot (or custom IR sensors) directly, to integrate stabilization directly into the autopilot.

The surface-mount (SMD) version is functionally identical (except it has two extra analog inputs for sensors, thanks to the SMD version of the ATMega168 chip having more I/O pins), but smaller. We designed this one mostly for ease of automated manufacture--we will be offering a pre-made board with components already mounted in a few months--but if you're not too afraid of hand soldering intzy-wintzy leads, you may prefer this one, which you can buy here.

Here's the overview of the SMD board:

Here's the component list for the SMD board (Digikey parts): Capacitors:

Diodes:

Connector:

ICs:

Crystal:

Resistors:

Switch:

You may notice that the image of the board above appears to be missing some chips that the through-hole version has. That's because they're on the bottom of the board.

Top:

Bottom:

Read more…
im here trying to make my own autopilot using an AVR atmega16..shhh its slow cuz many ppl out there r using least 32mhz... but as a beginner i really cant afford anythin else...i hav am collecting the stuff but i was wondering....the IMU i hav spills out all readings including temperatures....what r these temp. for?...do i need them to make the autopilot....and if any1 has any suggestions regarding a KALMAN FILTER...cuz i am going to apply a kalmafilter to each and evry reading 1 by 1...suggestions r requested....
Read more…
Moderator

Twin motor setup

I've been contemplating about different platforms that could be used that, to me, seem a little more UAV'ish, but I've noticed that I have not ran across any twin motor setups within this site. I've poked around quite a bit, but certainly have not read every page posted.Is there a reason for not utilizing twin setups? Is it simply a matter of scale and payload to flight-time payoff?It seems to me that a few very good possible setups include:OV-10 Broncohttp://www.nitroplanes.com/yetwenovbr15.htmlCessna SkyMaster 337 Twinhttp://www.nitroplanes.com/newdecesk337.htmlC-119 Flying Boxcarhttp://www.newcreations-rc.com/ProductDetails.aspx?itemnumber=DHD513ELThe Bronco and Boxcar both have a ton of space for electronics and good flyers...Any thoughts?
Read more…
3D Robotics

After I added vectoring thrusters to the toy RC blimp, I realized that I needed a better test platform to find the best combination of motors, control loops and mechanical elements to give the blimp maximum control. I also realized that we hardly needed any of the toy blimp parts anymore. So I built a blimp controller/power platform from scratch, using the usual Lego pieces and thin plywood.

It has the same Lego gear and axle assembly as the previous vectoring thrusters, although I changed the gear ratio to 2:1. I used Lego rods at the motor mount beams, extending out 50% more than the toy blimp to get better turning leverage.

But the really cool thing is that I added RC control to the Blimpduino's autonomous control. That way I can fly the blimp manually to test different motor and vectoring strategies and otherwise understand the blimp's aerodynamics.

The way it works is that under RC control, I connect the RC receiver's channel 1 (steer right/left) to the ultrasonic sensor port, and the channel two (steer up/down) directly to the vectoring servo. I'm writing some Arduino code to read the channel 1 PWM on the ultrasonic port pin and convert that into signals to the Blimpduino's two motor driver chips. Basically that ultrasonic sensor port now has dual functions, depending on which program I'm running.

When I want to fly autonomously, I just take off the RC receiver and have Blimpduino control both the vectoring servo and the motors itself, connecting the ultrasonic sensor back to its regular port.

The Li-Po battery (the red thing underneath the receiver at the back of the board) powers Blimpduino and also the RC receiver, via the channel 1 port.

Other parts needed:

Here's a close up from the side:

Read more…
3D Robotics

ArduPilot: first board built

We've got the physical ArduPilot boards now, and the above is one with the components mounted. As you can see, it's pretty small! We've got channels 3 and 4 (throttle and rudder--that's the ESC and servo in the pic) from the RC receiver (at left) going through the autopilot. It can handle two more channels, but we're not using them right now. When the autopilot is in control, it will steer with the rudder and maintain altitude with the throttle. Elevator and ailerons are under the control of the FMA CoPilot for stabilization. Channel 5 is used to turn the autopilot on and off and goes into the on-board hardware multiplexer/failsafe that Jordi designed and we've incorporated into this board. Finally, that's the GPS (EM406) in the top left corner. This board is just for testing, and I can already see a few small tweaks to make in the next board (we'll switch to a different GPS connector, for instance). I'm still working on the code, meanwhile, but I can already tell you that it will be much simpler (and better) than the Basic Stamp code, thanks the superior hardware of the Arduino. Speaking of which, this project got a nice call-out from the official Arduino blog!
Read more…

uBlox5 the enabling technology

uBlox 5 is an enabling technology as far as navigation is concerned. We're going to see amazing things in cheap autonomous rotorcraft because of it. Optical flow may actually be knocked out by uBlox5 & the former complexity required to damp velocities is gone.Have 2 videos of the uBlox 5 controlling position in the wind. This is of course, totally electronic stabilization without flybar.

Read more…

PID Controller In Layman's Terms

Don't let that image intimidate you. It's not that bad! I was surfing on the Parallax Propeller forums and I noticed a post on PID controllers for UAVs that might be useful to some of you:PID Stuff for you UAV Nuts out there!PID controllers are commonly used in UAVs to keep the airplane on a specified path. Sniper King discusses each of the three parts of a PID controller in easy to understand language. He also gives advice for flight testing your software and tuning your gains.I haven't looked at the PID code in the Parallax OBEX, but I believe there is an alternate PID form that uses only one gain. For a more thorough explanation on PID controllers, you may want to check out the wikipedia article.
Read more…
3D Robotics

How to add vectoring thrusters to a blimp

As those who have been following along with our "minimum blimp" project to create the cheapest possible autonomous aerial robot (by adding an open source autopilot to a toy RC blimp), maintaining altitude in the face of air currents and temperature gradients has been a continuing challenge. The main problem with the toy RC blimps we start with is that they have a single tiny vertical motor and prop to control altitude, and unless you've trimmed the blimp exactly right and conditions don't change, that's not enough to reliably keep the blimp off the floor and away from the ceiling.

The best way to increase the vertical "authority" or control power is to get the two differential thrust props on each side to also do some vertical work, by tilting up or down along with their usual job of driving the blimp forward, back and right and left. Such tilting props are called "vectoring thrusters" and they're what the expensive blimps use. But on the cheap toy blimps that we start off with, the shaft that holds the two horizontal thrusters is glued and screwed into place.

No fear. Converting this shaft into one that can rotate is a simple matter of five pieces of Lego and a small RC servo. You can see it work in the video above, but here are some shots to show how to make it.

Before (typical toy blimp gondola, with RC equipment stripped out):

Parts needed (Lego Technic parts and one servo):

Cut the blimp motor shaft in half and insert the Lego rod, with the gear and two Lego beams on it. Cut out a bit more room in the gondola and glue the two beams in. The shaft can now rotate:

Now drill out the Lego gear to fit the servo shaft, screw it on, and then glue the servo on top of the Lego beams (depending on the size of your servo you might need a little plastic wedge to get the right spacing):

That's it! Needless to say in the autonomous version the onboard autopilot will drive that servo, not a RC transmitter. But you get the idea. If the two vectoring thruster do the trick of altitude hold, I may remove the vertical thuster entirely to save weight (and two I/O pins). If I need even more vertical control, I'll keep all three going.

Read more…
3D Robotics
Judging from this thread, Paparazzi is a complete nightmare to implement, despite the new availability of pre-built boards. The insistence that it has to run under Linux doesn't help. I have huge respect for the technical accomplishments of the Paparazzi team, but it sounds like some all-important hand-holding for regular folks has been lost along the way. [UPDATE: Speaking of Paparazzi, this Hong Kong company has fabbed thousands of Paparazzi PCBs (is the market for difficult-to-use open source autopilots really that big???) and has some very good deals on Tiny 2.11s ($185 for the kit including 4Hz GPS)]
Read more…
3D Robotics
Dave Perry from UNAV writes in with some news: "UNAV has been working with the US Commerce Dept. for the past six months to re-classify our PICOPILOT-RTL (Return To Launch) product. We claimed that since the -RTL could not be programmed with user waypoints, it should be classified separately. Friday, we finally received the classification; 7A994. This classification requires the -RTL to have an export license only for AT ( terrorism sponsoring ) countries. This ruling is significant because it means the US government recognizes the difference between "programmable" and "return to launch" autopilots.Now we can export the PICOPILOT-RTL to almost any country without an export license. Of course, any autopilot that can be programmed with user waypoints remains classified as 9A012, requiring an export license to all countries except CANADA. I might point out that the regulations make no distinction between hobby and commercial autopilots, so the export of amateur (DIY) autopilots must comply with the US export regulations and have an export license. " [Chris here: I think it's going to be interesting to see how the regulators consider open source hardware, autopilot kits and autopilot components. I note that the Autopilot/IMU "development board" that SparkFun sells, which is fully programmable and much more capable than the RTL, is not export controlled. Neither is the impressive pre-made Paparazzi autopilot. An oversight? Or are such "development boards" not considered autopilots? And since each of these are just the combination of an IMU, a embedded processor and GPS, all of which aren't export controlled, what if you just buy the three bits and put them together yourself, downloading open source code from a site like ours to make it all work together? Obviously there's little the regulators can do about that, and the point of sites like DIY Drones is to make that very process of doing-it-yourself as simple as possible. In a world where many of the components of an autopilot, from accelerometers to GPS, can be found in any cell phone, is it really possible to regulate the sale of autopilots like weapons anymore? No one's come after us for selling an autopilot PCB (nor should they). When we sell it with the components pre-soldered, like the SparkFun or Paparazzi boards, can we just call it a "development board" and similarly escape regulation? Does it matter if the software is pre-loaded or not? Does the fact that none of us--the creators of the Sparkfun, Paparazzi or ArduPilot autopilots--are companies (we're just amateurs, mostly working in the open source realm) make a difference? Even if it did, what about the companies that are actually making and selling the boards for us, such as SparkFun or BatchPCB? Are they responsible for knowing what these boards do and all the regulations concerned? Lots of question....]
Read more…
3D Robotics
The AUVSI organizers have offered to get us a flying field in San Diego for an amateur UAV fly-in on Sunday, June 8th, the day before their big annual UAV conference and expo starts. Before I take them up on this, I want to gauge interest: are you in the San Diego area or going there for AUVSI and might want to fly on that Sunday? (BTW, I'm giving a keynote at AUVSI, talking about the rise of open source and amatuer UAV development)
Read more…

NEW UAV FOR PENTAGON

This looks interesting! As seen in the Polular Mechanics South African versionLooks promising in regard to my thoughts on the "Drug issue"Does anybody have any info on specs and such like.
Read more…