Robots

MIT Acrobatic Robot Helicopter

Posted 11 Feb 2002 at 16:03 UTC by steve Share This

MIT News has an article on the progress of the MIT Autonomous Acrobatic Helicopter Project. Their robot helicopter has successfully completed acrobatic maneuvers which could previously be attempted only by a skilled human pilot such as a 360-degree aileron roll. Their web site includes video of the robot helicopter in action as well as a collection of research papers on the project.


If you'd like to hack on helicopters..., posted 11 Feb 2002 at 17:15 UTC by hudson » (Master)

If you're interested in hacking on a similar project, check out autopilot.sourceforge.net. We're building an autonomous helicopter with Free Software for all the components, from the low-level sensor reading, rate integration and tactical responses (running on a custom PCB), all the way up to the high-level strategic task planning (running on an embedded Linux board).

The helicopters are not flying on their own yet, but the sensor data is proving to be useful for calibrating the control loops. And the AHRS / INS board is almost ready for other robotics projects.

Helicopters and clinometers, posted 11 Feb 2002 at 17:47 UTC by steve » (Master)

I noticed your diary note about the clinometer article - I can see how a clinometer with a slow response time would not really be very useful on something like this helicoper which has to make fast course corrections. How fast can the sensor/software system you're developing respond? Wheeled robots that I've worked on were generally doing a lot of work if they could evaluate all their sensor data once or twice a second (this was with 8051 or HC11 processors too, so there wasn't a lot of CPU power to spare). I would think in a flying robot you'd have to do an order of magnitude better if you wanted to stay in the air!

Sensor sampling rates, posted 11 Feb 2002 at 18:53 UTC by hudson » (Master)

Steve wrote:
I noticed your diary note about the clinometer article - I can see how a clinometer with a slow response time would not really be very useful on something like this helicoper which has to make fast course corrections. How fast can the sensor/software system you're developing respond?

The accelerometer data are available ever 20 ms for pitch and roll, and every 30 ms for "down". The angular rate data are available 3 ms. The limiting factor is the servo response time -- each servo receives a command every 32 ms right now and the mechanical motor in the servo takes some time to adjust to the new position.

The ADXL series of accelerometers can react more slowly by changing the bandwidth capacitor. We're also performing software averaging to smooth out any noise or jumps in the signal.

Wheeled robots that I've worked on were generally doing a lot of work if they could evaluate all their sensor data once or twice a second (this was with 8051 or HC11 processors too, so there wasn't a lot of CPU power to spare). I would think in a flying robot you'd have to do an order of magnitude better if you wanted to stay in the air!

The system has a realtime control board with a 4 Mhz AVR ATMega163 that spends 60% of its time reading sensors and commanding servos. The rate integration and PID loops are done on the Linux box for now, but we might upgrade the clock and move those responsibilities (and maybe Kalman filtering) onto to realtime board. With an 8 Mhz clock we should have enough time to do all of those things and maintain a 30 Hz update rate for the control surfaces.

Additionally, a well-trimmed and balanced helicopter will actually hover "hands off" for brief periods of time. I've seen electric ones hovering in zero-airspeed conditions for several seconds. Many of the problems with instability are actually pilot induced oscillation and overcontrolling of the aircraft.

Servo pulse timing and speed control, posted 13 Feb 2002 at 04:10 UTC by The Swirling Brain » (Master)

Previously written:

each servo receives a command every 32 ms right now and the mechanical motor in the servo takes some time to adjust to the new position
Although your statement is correct, many servos can receive a pulse more often than every 32ms. You might want to test different command time for your pulse width like 20ms window or 15ms or 10ms, etc. Of course this doesn't necessarily change the mechanical speed of the motor, but it might help the reaction time at least. Of course you must have a CPU powerful enough that can handle doing updates that often especially if you have several servos you are servicing.

Also, depending on the servo, if your command changes a large distance say from 1ms pulse to a 2ms pulse (full sweep from left to right), the motor controller will attempt a faster sweep than if you did a little correction of 1ms to 1.001 ms. This can be seen when you hack a servo for full rotoation and seeing speed control based on how far from center your pulse gets (1.5ms=stop, 1.4ms=slow, 1.2ms=med, 1ms=fast). So, you might want to try to send two commands to the motor to do an overshoot and then the position you really wanted, and perhaps it might increase the motors mechanical rotation speed too. So say you're position is at 1.2ms and you want to get to 1.3. Try going 2ms then 1.3ms and see if you get there faster than if you just did 1.3ms by itself. There again you'd have to do some testing to see what combination works the best or if it's even worth going through all that trouble.

See more of the latest robot news!

Recent blogs

19 Apr 2014 mwaibel (Master)
17 Apr 2014 shimniok (Journeyer)
8 Apr 2014 Petar.Kormushev (Master)
6 Apr 2014 steve (Master)
10 Mar 2014 Flanneltron (Journeyer)
2 Mar 2014 wedesoft (Master)
1 Dec 2013 AI4U (Observer)
13 Nov 2013 jlin (Master)
23 Jun 2013 Mubot (Master)
13 May 2013 JLaplace (Observer)
X
Share this page