as all know that in a quadrotor u need to vary the relative speed of motors.........can anyone tell me how to vary the speed of motors wirelessly??
which microcontroller can be used??
which remote control to use??

dude first stick with a single thread! it will easier for people to respond to you!

u already started this today!
http://www.rcindia.org/self-designed-diy-and-college-projects/final-year-project-quadrotor/msg9358/?topicseen#msg9358

The motor speed is varied by PWM. For a brushless motor, it is more complicated especially for a sensorless design. You are much better off buying. Else building a brushless controller should be a project by itself.

Using a standard remote controller and receiver will be easier. If you want to build a controller yourself or want to control from a PC then I'd suggest using a maxstream module for RF link. It is available in India easily.

Which microcontroller to use depends entirely on what you want to achieve. You could also look at splitting the job across multiple microcontrollers. First thing I look for to select a  uC are the peripherals that are most suitable for the jobs at hand.if you can offload most of your work especially jobs that require specific timing like i2c, UART etc to peripherals that makes your job much easier. Also look at using counter and timers that could offload the pulse width measurement and timing tasks. This type of approach will leave the most processing power free for your use. Look at  the ATMEL and PIC range to find one suitable to you. I like ATMEL better not just because of the architecture but also  because of gcc support. You could also look to MSP430 series from TI. Since it is a college project, you should get good support from them. There is a huge amount of information on all these on the internet, start digging

What abt PIC18F4431........We are planning to use that microcontroller......do u have any views abt that.........

Looks promising, but without knowing much about what exactly you are going to do it is not possible to say if it is suitable or not.

Before buying it, you need to do finalize your requirements. Decide what all functions you need the uC to perform and what parts you'll buy first. I'd recommend to start with using a proper RC set and BL ESCs. Later you can change to your own controller and RF link or split your team and have one group develop the control software and RF link in parallel.

Once you decide on your requirements you need to start on firmware. Start with listing out all the parallel tasks you need to perform. For example, measuring PWM stream from the rx could be one thread. Another could be driving the servo pulses to the ESCs. Yet another for communicating with your accelerometer/gyro. And another for mixing inputs from rx and gyro and update PWM duty cycle for servo. See how you can use peripherals for these. This PIC has 4 PWM outputs you could use. Also you could use PWM capture for rx pulse stream.

Once you have identified the functions see how you can perform these tasks in parallel. Some functions could be interrupt driven, while others might need a continuous loop in software. You could also interleave multiple tasks in a loop. Try to avoid timing critical tasks in interleaved code. It cannot be avoided sometimes, use it as last resort. Implementation of all this is very specific to the uC you choose, so read the datasheet very carefully before starting.

PIC uCs often multiplex I/O pins/counters/timers for multiple functions. Watch out for conflicts when you are planning the firmware.

Also don't forget to use watchdog timer. Plan the code initially itself such that a watch dog reset would regain control of your aircraft seamlessly. ie try not to have too much pervious state information for proper functioning. Remember the Spektrum reset issue.

Which compiler are you planning to use ? I suggest using a C compiler than coding in assembly directly. Quite often these compilers do a better job than you do at optimizing. However do keep checking the assembly code it generates and see if it is giving you the most optimal code. If you can think of a better way than the assembly code generated, do not jump and insert assembly code. Often a subtle change in the way you write the C code will give you the assembly code you want. Keeping the code in C will make your life a lot easier later in the project when you need to tweak here and there.

The QEI module looks interesting, I haven't seen this before in a uC. Work has kept me away from these hobby stuff for some years now and looks like I have missed some progress in uCs. Are you planning to use this module ?

BTW, which college are you from ?

I am frm TKM COLLEGE OF ENGINEERING,KOLLAM,KERALA.

Can v  vary the speed of motors without using ESC??

If you are using brushed motors, you could use the PWM outputs. For brushless motors, you are better off using an ESC.

Brushed motors are heavier than brushless motors for the thrust they can generate. Also the efficiency is less in most cases.

Can you provide me with any link or some resources which can help me in programming the PIC18F4431??

Haven't touched a PIC in many many years   but a Google search for "PIC18F4431 sample programs" seems to bring up tons of useful links.

http://www.pic18f.com/

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en020394

http://home.earthlink.net/~davesullins/software/pic18f.html

and many more.  Hopefully some of these will be useful to you 

And these are more relevant to your cause.  Probably a little too relevant to put you in the league of plagiarism ?

http://www.st.ewi.tudelft.nl/~gemund/Courses/In4073/Resources/RA.pdf

http://me.columbia.edu/seniordesigns/2007/QUAVe/FinalReport.pdf

Thank you very much..........

Actually i have taken the columbia universities project as my references but since they have carried out the project in 2007 the components they have used is no more available.......thats y i palnning to use new components  but there is one problem ....... i have got free samples of accelerometers as well as gyrosopes from analog devices but the thing is that they have send me SMD devices so in order to use them in my project i need the evaluation-board for the gyroscope which are still under production .the accelerometer is ADXL213 and the gyroscope is ADXRS613..........
Do you know from where can get the evaluation board of the gyroscope in india??

Does anyboby know how to transmit video signals??
I am planning to incorporate a video camera on to my quadrotor..........

To transmit video signals, are you planning to build or buy ?

i am planning to buy ..........how can i implement it..........what will b the hardware requirements??

If you are planning to buy, just search for "FPV" in this forum, and you will find many threads that discuss equipment and setup for the same.

Does anybody have any idea of gyroscopes in depth??
if in a gyro it is said that itz output is +-150degrees/sec  then what does it imply??

Does a gyro having +- 150degree/sec and another gyro +-300degree/sec made equivalent or something like that??

Quote from: RVRENJITH on December 11, 2009, 07:46:24 AM
Does anybody have any idea of gyroscopes in depth??
if in a gyro it is said that itz output is +-150degrees/sec  then what does it imply??

The number expressed in "degrees per second" is the ability of the gyro to detect how fast its is turning.  So a gyro with a 150 degree per second can detect a turn of 150 degrees in a second.  In other words, if you want to detect a full 360 turn reliably, the turn has be done in over 2 seconds (360 / 150 = 2.4).  If you did a full 360 degree turn in say 1 second, the gyro will NOT be able to detect that correctly.

Now a low "degrees per second" is not necessarily a bad thing, especially for what you are trying to do.  Some gyros have two modes, one with a higher degrees per second, and one with a lower degrees per second.  The lower one is also known as a "high sensitivity" mode, where small changes in directions/turns are detected with better accuracy.  Remember that the more distance you travel, even small differences in direction gets amplified, so accuracy is more important in most applications as compared to detecting more "revolutions" in a shorter time.

See the link in the last post on this thread : http://www.rcindia.org/servos-gyros-and-all-electronics/gyro-modes-normal-and-heading-hold/

So for my quadrotor can i use a gyro havng +-50 degree/sec over a +-150 degree/sec gyro??

There has to be a trade off between turn detection rate (degrees per second) and sensitivity, right ?  I am not sure what that is for your application.  Why not 10 degrees per second instead of 50 degrees per second ? 

It boils down to how much/fast of a turn happens in real life that needs to be reliably detected, for your application. 150degrees per second looks like a happy medium (for an RC type of application).  Just a guess though at this point, without adequate data points !

The important thing is to experiment with what you have, and then think about changing.

I suppose you are using gyro for stabilization, don't think your application needing insane piro speeds like used by some rc heli fliers. 50deg/sec should be plenty for this.

I was looking at it from the view point of "what are the chances of the aircraft tilting 50 degrees in a second".  That sounds possible, while 150degrees sounds less possible.  So wouldn't 150 be a better choice than 50 ?

Of course there is counteraction as soon as the shift begins, but how long before everything reacts to put the stabilization motion in place ?

Don't disagree with higher the better logic. I was thinking that even 50deg/sec is a drastic change for a quad rotor platform. Consider that for this application you will be starting with a platform that is inherently as stable as possible even before you add stabilization. It sounded like he already has a gyro with 50deg/sec and wanted to know if that would be sufficient.