Gimbaled platform without gyros or motors.

[mardlamock]

Hello, just a random question i had today, is it possible to build a gimbaled platform such as those used for Inertial measurement units without using gyroscopes to keep the platform stabilized? It would have to be lubricated pretty well, but i dont see any reason why it couldnt work, what do you think? This is what i am talking about https://www.hq.nasa.gov/alsj/lm_imu.gif

Thanks!

[Nuke]

i think modern imus have gone to solid state mems devices. though you might still see mechanical ones used in aerospace because reasons.

[mardlamock]

i think modern imus have gone to solid state mems devices. though you might still see mechanical ones used in aerospace because reasons.

Yeah, but I thought it would be easier to use a gimbaled platform and just an accelerometer if i want simple dead reckoning, that way i dont have to deal with freaking gyros (I hate them, or better said, I dont understand solid state gyros interfacing with arduino)

[Bill Phil]

What's the problem with gyros? They use their own momentum to keep stable along their axis of rotation. That's cool. And an arduino might not be enough... Probably is, though.

[mardlamock]

What's the problem with gyros? They use their own momentum to keep stable along their axis of rotation. That's cool. And an arduino might not be enough... Probably is, though.

They are cool, but I cant get them to work properly with my arduino. Not talking about the mechanical gyros, but electronic ones. I could use 3 mechanical gyros to stabilize the platform, but I was just wondering if without them, and using proper lubrication, you could get acceptable results.

[Bill Phil]

With what other mechanism are you thinking of using?

[Nuke]

What's the problem with gyros? They use their own momentum to keep stable along their axis of rotation. That's cool. And an arduino might not be enough... Probably is, though.

use one of the 32 bit arduinos. avrs are a little slow at kalman filtering. i was getting about 15 updates/sec on an avr using (software) float math. you could probibly speed it up with fixed point math though. kalman filtering is kind of tricky, but there are libraries you can use if you cant get your head around it.

With what other mechanism are you thinking of using?

i saw a counterweight and gimbal setup used for a camera autoleveler (found it). such a thing works well if you are not translating around a whole lot. it used door hinges tac welded at a 90 degree angle as the gimbal. i would probibly want to use ball bearings for a smoother result though. you would probibly want an active system if you were mounting it on something like a vehicle or air craft. it would definitely help if we knew what you wanted to build it for.

Edited January 2, 2015 by Nuke

[mardlamock]

With what other mechanism are you thinking of using?

What I posted above, a free floating platform resting ontop of properly lubricated gimbals with an arduino+accelerometer in the middle, for the time being I dont need gyros.

[Bill Phil]

You need something that stays pointed in one direction independently of the crafts orientation. Your contraption would be useful for only a specific set of directions... I don't know.

[mardlamock]

use one of the 32 bit arduinos. avrs are a little slow at kalman filtering. i was getting about 15 updates/sec on an avr using (software) float math. you could probibly speed it up with fixed point math though. kalman filtering is kind of tricky, but there are libraries you can use if you cant get your head around it.

i saw a counterweight and gimbal setup used for a camera autoleveler (found it). such a thing works well if you are not translating around a whole lot. it used door hinges tac welded at a 90 degree angle as the gimbal. i would probibly want to use ball bearings for a smoother result though. you would probibly want an active system if you were mounting it on something like a vehicle or air craft. it would definitely help if we knew what you wanted to build it for.

Yeah, thats exactly what made me think of saying bye bye to the gyros and just using gimbals. If it doesnt work with translation then I probably cant use it at all, as I am building it for a rocket. My electronics knowledge is poor to say the least, I understand what I need to do with the data from a gyro or an accelerometer, I just dont freaking know how to get it. What would be a good resource for a complete newbie wanting to learn how to decently work with an arduino for the project above? I know its probably way above my level (turning on a light with a button is already above my freaking level), but im still interested in how it could work. I ve been trying to develop a model for the rocket's flight and then experiment with that by simulating an arduino using dead reckoning to estimate position and actively stabilize the rocket. I'd get the data from the model and feed it to a "fake" program with added errors, the program would then execute commands which would reflect upon the model, testing how useful the program is or isnt. I dont know how feasible it is with my little understanding of math and electronics, I am still in high school, know a decent amount of calculus and just a little bit of differential equations. I understand the different numerical methods, but I have no idea on how to use them say on Matlab, or how to data I need from my arduino board. Anyways, thanks a lot man, tell me what you think!

- - - Updated - - -

You need something that stays pointed in one direction independently of the crafts orientation. Your contraption would be useful for only a specific set of directions... I don't know.

Not if you used 3+ gimbals inside one another, only problem would be the gimbal lock. The question is, can you get the friction between the gimbals to be so low that you dont need gyros to keep it pointed in the same direction? And I have no idea, hence the thread.

[Bill Phil]

Maybe something akin to a level would be better suited...

[pincushionman]

The only purpose for the gimbal platform is to allow the gyro to do its thing and maintain orientation. If you're going to ditch the gyro and integrate the accelerometer outputs there's no reason for it, and you're better off fixing the accelerometers as rigidly as possible. But you're more prone to error build-up because you're integrating angular accelerations into angular velocities into angular deviations, rather than directly measuring deviations. If you derive angular accelerations from linear acceleration differences, that's yet another step.

[mardlamock]

The only purpose for the gimbal platform is to allow the gyro to do its thing and maintain orientation. If you're going to ditch the gyro and integrate the accelerometer outputs there's no reason for it, and you're better off fixing the accelerometers as rigidly as possible. But you're more prone to error build-up because you're integrating angular accelerations into angular velocities into angular deviations, rather than directly measuring deviations. If you derive angular accelerations from linear acceleration differences, that's yet another step.

What I was saying was just a wild guess, I'll try to build something and see if by reducing the friction and adding more mass I could get it to work, I doubt it though. Without using multiple accelerometers it would be impossible to distinguish angular acceleration and regular translational acceleration, and even during the coast phase of the ascent, you'd still get problems if you used a constant approximation for gravity, because the rocket would also be experiencing drag. I guess that you could say that during the time the engine is active the orientation would remain pretty much the same as during the time it is in the pad, which would in turn (so long as the engine cuts off very rapidly) mean that that accelerometer data could be used for dead reckoning. You could then use the information you got during the ascent phase (integrated to get velocity and position), to estimate the drag, subtract it from the current readings, and then estimate orientation. That would be tricky though, as soon as I get the model im using working with RK I will tell you if it could be used or not. What are your thoughts on that?

[Nuke]

if you have a decent orientation reference you can integrate the acceleration detected by the accelerometer and get a rough approximation of your position. acceleration * time = change in position, add up those each iteration and chart your position in relation to your starting position. but you have to transform all the coordinates out of rocket local space and into world space, and filter out acceleration from gravity out of the accelerometer data. inertial navigation is probibly beyond the capability of a single mems device, but a rocket's flight time is sufficiently short enough to not loose a lot of precision to gyro drift.

when i tried it i ended up with something that maybe could keep an r/c heli level, but wouldn't be very good at knowing its location. you would need a quaternion based kalman filtering library to give you the best information for finding your orientation accurately enough to integrate position. the one i was using was only covering roll and pitch, but without heading my position would be hard to find. also euler angles are horrible with gimbal lock. quaternions also simplify the maths to vector operations and vector-quaternion multiplication. of course the avr was not well suited to this kind of maths and the project kinda stalled there. i got an arduino due for xmas so i may try again in the future.

hardware wise just mount the imu board on a solid surface in the rocket. most of the imu boards ive seen have an i2c interface which is kind of straightforward to use (voltage, ground, and 2 wires with pullup resistors). you can use the wire library or whatever library works with your mems chip(s). read the data sheets for information about how to talk to the imu.

Edited January 2, 2015 by Nuke

[mardlamock]

if you have a decent orientation reference you can integrate the acceleration detected by the accelerometer and get a rough approximation of your position. acceleration * time = change in position, add up those each iteration and chart your position in relation to your starting position. but you have to transform all the coordinates out of rocket local space and into world space, and filter out acceleration from gravity out of the accelerometer data. inertial navigation is probibly beyond the capability of a single mems device, but a rocket's flight time is sufficiently short enough to not loose a lot of precision to gyro drift.

when i tried it i ended up with something that maybe could keep an r/c heli level, but wouldn't be very good at knowing its location. you would need a quaternion based kalman filtering library to give you the best information for finding your orientation accurately enough to integrate position. the one i was using was only covering roll and pitch, but without heading my position would be hard to find. also euler angles are horrible with gimbal lock. quaternions also simplify the maths to vector operations and vector-quaternion multiplication. of course the avr was not well suited to this kind of maths and the project kinda stalled there. i got an arduino due for xmas so i may try again in the future.

hardware wise just mount the imu board on a solid surface in the rocket. most of the imu boards ive seen have an i2c interface which is kind of straightforward to use (voltage, ground, and 2 wires with pullup resistors). you can use the wire library or whatever library works with your mems chip(s). read the data sheets for information about how to talk to the imu.

Yeah, I believe that for my rocket's flight time it would be ok-ish, not that much drift from the gyro and the errors in the accelerometer wouldnt have that much of an effect MECO would be somewhere near the 3 second mark, apogee at 40. I will just have to test and see how it works. Im using an l3g4200d gyro with I2c interfacing and an adxl345 which can sort of make it up to the gees im going to be running into (10 gees). Any good textbooks or resources you might recommend to me when learning about this sort of stuff?

[Bill Phil]

How big is your rocket? What's its mission?

[Nuke]

i spent hours watching youtube videos on kalman filtering. much of it was over my head, a lot of math and whatnot. but thanks to c++ libraries you dont need to understand it to use it. i dont know of any books on the subject, but i do know that many a student has written a phd thesis on it. i tried using the freeimu library with not so useful results (it was slow and very gimbal lockey). the main issue was it didnt have support for the l3g4200d gyro (i have the same one on my imu board), so i had to port the code over to a new library. the results were sub satisfactory.

there was another library here that kind of looked promising, but it said that it needed at least a due to run it. again it doesnt support all my sensors but that is just a matter of finding a new library and swapping out all the function calls.

dont expect any of this code to work without hours of hair pulling out.

[mardlamock]

How big is your rocket? What's its mission?

Its 10cm in diameter, 120 cm long, propulsion section goes from the bottom up to 55cm. It uses a J/K (I have to do a few static tests to get some numbers on the propellant specifications and grain design) class PVC R-Candy engine, BATES grain, with a total propellant mass of 1kg. The first rocket will go up to around 6100 meters, (not exact because I still need to do the full static test I mentioned) and 340m/s (though Im not taking into account drag coefficient variations, so it may be less), and use a delay charge to release a parachute, though I wouldnt put much faith in it and personally believe it will spectacularly lawn dart. As the motor diameter is smaller than the airframe, in case of a CATO it will absorb the pressure. The mission is to test the airframe and propulsion, so that i dont waste an arduino in a spectacular explosion.

[Bill Phil]

That might not need a gyro. Wouldn't fins be good enough? The V-2 only needed to steer to point it in the direction of its target, for the most part. You might not need an Arduino at all, either.

Wait, 6 kilometers is a lot of altitude. Do you have permission? I think it's big enough and it can go high enough to look like a missile...

[mardlamock]

That might not need a gyro. Wouldn't fins be good enough? The V-2 only needed to steer to point it in the direction of its target, for the most part. You might not need an Arduino at all, either.

Wait, 6 kilometers is a lot of altitude. Do you have permission? I think it's big enough and it can go high enough to look like a missile...

Of course I dont need an arduino, but it would add to the fun. And imagine the possibilities, if you ve got a working dead reckoning unit, you can strap on some servos on the sides and stabilize the rocket, or even better, guide it! You can have ascent profiles that keep it within certain boundaries, return to launchsite, or you can just plat around with it. I do it mainly because I one day want to work in aerospace, and for the time being, this is the closest i ve got. Besides, it may (though im not too sure) help me get admitted i to college.

I have the permission of the owner of the field i am launchig it from, its in the middle of nowhere, and the airspace regulations are sort of greyish regarding rockets. Putting an arduino with dead reckoning and stabilization might violate some international arms regulations, but i havent found any conclusive evidence of that and i am a long way from actually doing that.

- - - Updated - - -

i spent hours watching youtube videos on kalman filtering. much of it was over my head, a lot of math and whatnot. but thanks to c++ libraries you dont need to understand it to use it. i dont know of any books on the subject, but i do know that many a student has written a phd thesis on it. i tried using the freeimu library with not so useful results (it was slow and very gimbal lockey). the main issue was it didnt have support for the l3g4200d gyro (i have the same one on my imu board), so i had to port the code over to a new library. the results were sub satisfactory.

there was another library here that kind of looked promising, but it said that it needed at least a due to run it. again it doesnt support all my sensors but that is just a matter of finding a new library and swapping out all the function calls.

dont expect any of this code to work without hours of hair pulling out.

Thanks for the links, ill be sure to check them out. I too have been watching a lot of yt videos of kalman filters and whatnot, its reallt hard, but i sort of get it. Problem is, i might have some intuition on how and why it works and the formulae, but i cant even get my l3g4200d to print raw data. Thanks a lot man!

[Bill Phil]

It just seems like an unnecessary feature of the rocket to me. It seems like it would be much easier to start off with a rocket with no computer, and work your way up. Unless you have already done that?

[Nuke]

heres is the library i was using to get data out of my gyro. it covers many i2c sensors including most of the sensors i was using (and other platforms too so be sure you use the ones for arduino). it comes with examples.

one gotcha i noticed is that sometimes an i2c device has a few extra pins for setting its address. depending on whether they are pulled up or down will change the default address of the sensor. on mine the address was set to 0x68 where the library (and device datasheet) defaulted to 0x69.

here is a snippet from my code to access the sensor:

//include stuff
#include "Wire.h"
#include "I2Cdev.h"
#include "L3G4200D.h"

void setup() {
  //start libraries
  Serial.begin(115200);
  Wire.begin();
  L3G4200D gyro = L3G4200D(0x68); //set address here. this chip has two address options, this and 0x69

  //initialize and configure gyro
  gyro.initialize();
  if (!gyro.testConnection()) Serial.println("$gyro_init_fail;");
  //set some gyro options
  gyro.setFullScale(500);
  gyro.setHighPassFilterEnabled(true);
  gyro.setBlockDataUpdateEnabled(true);
}

void loop() {
  //get data from gyro
  int x,y,z;
  gyro.getAngularVelocity(&x, &y, &z);
  Serial.print("$gyro_x=");
  Serial.print(x);
  Serial.print("_y=");
  Serial.print(y);
  Serial.print("_z=");
  Serial.print(z);
  Serial.println(";");
  delay(50);
}

should run in arduino 1.0 with the libraries from the first link.

Edited January 2, 2015 by Nuke