Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
March 19, 2024, 08:40:14 08:40


Login with username, password and session length


Pages: [1]
Print
Author Topic: Dead reckoning using accellerometers  (Read 3821 times)
0 Members and 1 Guest are viewing this topic.
kev
Newbie
*
Offline Offline

Posts: 8

Thank You
-Given: 12
-Receive: 0


« on: December 23, 2007, 11:56:37 11:56 »

Has anyone played with Dead reckoning using accellerometers. I want to try and control a remote control helicopter with a 3 axis sensor. Just a hover would be good but first I need to know how to work out where I was and where I am now. ( the helicopter that is ) 
Logged
FriskyFerret
Hero Member
*****
Offline Offline

Posts: 560

Thank You
-Given: 513
-Receive: 360


Put it in, take it out.


WWW
« Reply #1 on: December 23, 2007, 04:49:11 16:49 »

Just some friendly advice so you know what you are getting in to: This is a postgraduate level project usually attempted by a student team.
Logged

Dancing pants and leotards, that's what I'm talkin' about!
frasenci
Translator
Active Member
***
Offline Offline

Posts: 171

Thank You
-Given: 142
-Receive: 84


« Reply #2 on: December 23, 2007, 06:42:49 18:42 »

Hi Kev.
Yes I have been playing around with this concept.
I fly r/c helicopters since 1985.
I never finished the proyect but I did a very simple aproach based on a 18F2550 @ 20 mhz.
I Let the On board PIC read 5 channels ( in series with the Rx ) , i.e. Auto ON/Off Channel ( 8 ) , and the 4 Axis channels ( 1,2,4,6).
The Sensor used is ADXL330.

On Chanel 8 Off , the PIC simply repeats the read signal and sends to servos. ( Each channels pulse length )

On Channel 8 On , the PIC enters a calulations routine that corrects as needed.

Secret is managing to update EVERY servo , at least every 20 ms ( 50 hz ) , or they will jitter.

I did tested with an Hirobo Shuttle with OS32 motor , starting with only Collective channel on Automatic.
My results where not perfect but I almost could forget about mantaining level on a hover.

Maybe I will dig out the proyect again this summer.

Do not fear , all info is written in books ( or the net ) .

You certainly CAN do something like this. You will have to study a little of course , depending on your background.

Greetings






Logged
kev
Newbie
*
Offline Offline

Posts: 8

Thank You
-Given: 12
-Receive: 0


« Reply #3 on: December 24, 2007, 01:52:56 01:52 »

Hi Frasenci,
  Sounds good, I have a few choppers but I wasn't going to try the Raptor just yet (bit expensive to fix and when it crashes it does big time), I thought I might try experimenting with the T-Rex or maybe even the little E-Sky although this may not be responsive enough. I have a freescale 7260 that I was going to couple to a PIC16f877 or maybe a DSPIC for  a bit more grunt. Any help you can give would be a great kick start.
Cheers, Kev
Logged
frasenci
Translator
Active Member
***
Offline Offline

Posts: 171

Thank You
-Given: 142
-Receive: 84


« Reply #4 on: December 24, 2007, 02:58:47 02:58 »

I would say , go for the T-Rex.
Important : from the very beginning , consider a sepparate battery for the On Board Processor , just make grounds common. Rx an servos tend to induce strange things to a PIC as was my case when using a shared battery pack.
I see a very first task you should embrace : timing.
There are 4 main loops that will run on an auto-pilot
1.- Reading the acelerometer(s)
2.- Reading the pilots input at the Rx
3.- Feeding the servos that control the Heli
4.- Doing the proper calculations for the autopilot to work as needed.

I left 4 for the end although it is the most important and tricky part , but nothing will work until you get 1,2,3 done.
The actual logic will be 1 , 2 , 4 , 3 .

Make yourself an test bench and put your hardware/firmware to work , until you manage to do 1,2 and task 3.- that is update signals on controlling servos EVERY 20 ms as a maximum , AND leaving time for task 4.-.

Remember that standard ppm servo signals go from 1.000 ms ( left ) to 1.500 ms ( center ) to 2.000 ms (right ) in pulse length.
So , in the worst case , you will have 4 x 2.000 = 8 ms just to update the 4 servos. Same thing for the reading.
Must be a very tight code.

Greetings

Logged
robban
Senior Member
****
Offline Offline

Posts: 265

Thank You
-Given: 34
-Receive: 38


Warrior


WWW
« Reply #5 on: December 25, 2007, 08:10:09 20:10 »

Just some friendly advice so you know what you are getting in to: This is a postgraduate level project usually attempted by a student team.
I agree with Frisky Ferret, but not even Student team can fix it. A hint: Use the onboard EEPROM to store the initial level of the acc.meters. I use MEMSIC coz they are digital, small, cheap and can run up to 400 Hz report rate.
Logged

Code Warrior
mrwinch
Guest
« Reply #6 on: March 02, 2008, 12:28:08 12:28 »

Hi Kev,
I'm working on a similar project: I suggest you to use dspic30f4013 because it gaves you a lot of resource to manage servos (for reading receiver input and for drive servos). This pic has a limit of 4 servos (with interrupt managment): if you need more, you have to use other dspic family dsp, like dspic30f6014.
The most complex task is the managment of accelerometer information: you have to filter and manage them. You have also to implement an algorithm for converting accelerometer input, in speed and position information... this means you have to know very well phisics and programming
Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC