## Re: [SeattleRobotics] inverted pendulum

Expand Messages
• What kind of encoder hardware are you using? It s probably a software glitch in the encoder counter routine. What CPU are you using? You might want to
Message 1 of 17 , Oct 4, 2005
What kind of encoder hardware are you using? It's probably a software
glitch in the encoder counter routine. What CPU are you using? You
might want to either up the CPU speed, put the encoder in a hardware
interrupt routine, or do something else to give it more CPU time.

The problem with the accelerometer is that its reading is dependent
not only on the angle, but also on linear acceleration. If you have
an accurate read of the linear velocity/acceleration of the base, you
might be able to calculate the angle with the accelerometer, although
it might be easier with a gyroscope. Probably the easiest solution is
just to fix the encoder.

--Tom Capon

On 10/4/05, Bryan <BNHrobotics@...> wrote:
> I have been working a lot on my inverted pendulum and I have come to
> a point where I am stuck. My encoder that measures angle works
> reasonably well but sometimes it misses a few counts and sometimes
> the angle turns out completely wrong. I also tried added a dual axis
> accelerometer to the mix. This can only measure the angle while the
> system is static.
>
> Can anyone give me advice on how to get an accurate angle reading?
>
> I tried finding the angle with the acclerometer using this equation:
>
> ycos(angle)+xsin(angle)=g where x and y are the acceleration
> readings from the sensor and the angle is the angle of the pendulum.
> This worked while everything was static but when there is any other
> acceleration involved, the angle reading goes crazy.
>
> To solve for angle, I had arcsin(1/(sqrt(x^2+y^2))-arccos(x/(sqrt
> (x^2+y^2)).
>
> Any suggestions on what to do? Thanks. Any help is greatly needed
> and appreciated.
>
> Bryan Hood
>
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
>
>
>
>
>
>
>
• My encoder is from US Digital. It has 4000 counts per revolution. It is connected to a binary counted which is connected to the microcontroller. This way, the
Message 2 of 17 , Oct 4, 2005
My encoder is from US Digital. It has 4000 counts per revolution. It
is connected to a binary counted which is connected to the
microcontroller. This way, the micro just reads the output from the
counter to get the angle so it doesn't ever miss a count. I am pretty
sure that the software isn't the problem but I will check over it
again.

I have played around with it some more and I have found that the
error is only introduced sometime after the motor has been powered
up. Does that give any clues? Maybe I should add a capacitor to the
motor. Are there any other possibilites?

Thanks

Bryan Hood

--- In SeattleRobotics@yahoogroups.com, Tom Capon <robot256@g...>
wrote:
> What kind of encoder hardware are you using? It's probably a
software
> glitch in the encoder counter routine. What CPU are you using? You
> might want to either up the CPU speed, put the encoder in a hardware
> interrupt routine, or do something else to give it more CPU time.
>
> The problem with the accelerometer is that its reading is dependent
> not only on the angle, but also on linear acceleration. If you have
> an accurate read of the linear velocity/acceleration of the base,
you
> might be able to calculate the angle with the accelerometer,
although
> it might be easier with a gyroscope. Probably the easiest solution
is
> just to fix the encoder.
>
> --Tom Capon
>
> On 10/4/05, Bryan <BNHrobotics@g...> wrote:
> > I have been working a lot on my inverted pendulum and I have come
to
> > a point where I am stuck. My encoder that measures angle works
> > reasonably well but sometimes it misses a few counts and sometimes
> > the angle turns out completely wrong. I also tried added a dual
axis
> > accelerometer to the mix. This can only measure the angle while
the
> > system is static.
> >
> > Can anyone give me advice on how to get an accurate angle reading?
> >
> > I tried finding the angle with the acclerometer using this
equation:
> >
> > ycos(angle)+xsin(angle)=g where x and y are the acceleration
> > readings from the sensor and the angle is the angle of the
pendulum.
> > This worked while everything was static but when there is any
other
> > acceleration involved, the angle reading goes crazy.
> >
> > To solve for angle, I had arcsin(1/(sqrt(x^2+y^2))-arccos(x/(sqrt
> > (x^2+y^2)).
> >
> > Any suggestions on what to do? Thanks. Any help is greatly needed
> > and appreciated.
> >
> > Bryan Hood
> >
> >
> >
> >
> > Visit the SRS Website at http://www.seattlerobotics.org
> >
> >
> >
> >
> >
> >
> >
• I do not know if you are doing quadrature correctly. Some systems see jitter on one edge and declare it movement (counting up or down). You need to make sure
Message 3 of 17 , Oct 4, 2005
I do not know if you are doing quadrature correctly. Some systems see
jitter on one edge and declare it movement (counting up or down). You
need to make sure that is not a problem. You need a state system for a

The other option is that the motor is puts a voltage spike (or ground
bounce) in your HW and it causes the count to increment or decrement.
The capacitor could help that.

People get it to balance using a simple pot also. The value is absolute
not relative like an encoder.

Kip

On Tue, 2005-10-04 at 22:13 +0000, Bryan wrote:
> My encoder is from US Digital. It has 4000 counts per revolution. It
> is connected to a binary counted which is connected to the
> microcontroller. This way, the micro just reads the output from the
> counter to get the angle so it doesn't ever miss a count. I am pretty
> sure that the software isn't the problem but I will check over it
> again.
>
> I have played around with it some more and I have found that the
> error is only introduced sometime after the motor has been powered
> up. Does that give any clues? Maybe I should add a capacitor to the
> motor. Are there any other possibilites?
>
> Thanks
>
> Bryan Hood
>
>
> --- In SeattleRobotics@yahoogroups.com, Tom Capon <robot256@g...>
> wrote:
> > What kind of encoder hardware are you using? It's probably a
> software
> > glitch in the encoder counter routine. What CPU are you using? You
> > might want to either up the CPU speed, put the encoder in a hardware
> > interrupt routine, or do something else to give it more CPU time.
> >
> > The problem with the accelerometer is that its reading is dependent
> > not only on the angle, but also on linear acceleration. If you have
> > an accurate read of the linear velocity/acceleration of the base,
> you
> > might be able to calculate the angle with the accelerometer,
> although
> > it might be easier with a gyroscope. Probably the easiest solution
> is
> > just to fix the encoder.
> >
> > --Tom Capon
> >
> > On 10/4/05, Bryan <BNHrobotics@g...> wrote:
> > > I have been working a lot on my inverted pendulum and I have come
> to
> > > a point where I am stuck. My encoder that measures angle works
> > > reasonably well but sometimes it misses a few counts and sometimes
> > > the angle turns out completely wrong. I also tried added a dual
> axis
> > > accelerometer to the mix. This can only measure the angle while
> the
> > > system is static.
> > >
> > > Can anyone give me advice on how to get an accurate angle reading?
> > >
> > > I tried finding the angle with the acclerometer using this
> equation:
> > >
> > > ycos(angle)+xsin(angle)=g where x and y are the acceleration
> > > readings from the sensor and the angle is the angle of the
> pendulum.
> > > This worked while everything was static but when there is any
> other
> > > acceleration involved, the angle reading goes crazy.
> > >
> > > To solve for angle, I had arcsin(1/(sqrt(x^2+y^2))-arccos(x/(sqrt
> > > (x^2+y^2)).
> > >
> > > Any suggestions on what to do? Thanks. Any help is greatly needed
> > > and appreciated.
> > >
> > > Bryan Hood
> > >
> > >
> > >
> > >
> > > Visit the SRS Website at http://www.seattlerobotics.org
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
>
>
>
>
>
>
--
Kipton Moravec <kip@...>
• Bryan, From your hardware description, and problem description of missing pulses, a timing issue is where I would be looking for the problem. Do you ever
Message 4 of 17 , Oct 5, 2005
Bryan,

From your hardware description, and problem description of missing pulses, a
timing issue is where I would be looking for the problem. Do you ever clear
your counter? Or are you just incrementally grabbing the count each time
and adding? If you are clearing...then this is definitely the problem. No
matter how fast your microcontroller is, you could miss counts between the
time you clear, and the time you look for the next count. Make sure if you
are using an external counter like you describe, you are never clearing it,
and handle the overflow in software.

Next...how are you handling direction? Is the counter up/down? Do you have
a flip-flop in there? What does your solution look like? Unless you are
using some kind of counter chip designed for dealing with a quadrature
encoder, I'll bet beers that there is a timing problem there too.

All it takes is a few missed pulses in a balancing problem to throw
everything off. Most people miss pulses in their home-brew quadrature
interfaces due to timing issues, but they never notice it because they are
doing velocity control on a motor or something.

Here is a chip that costs \$5, that will solve the whole counting problem for
you flawlessly.
http://www.lsicsi.com/pdfs/LS7366.pdf

Hope this helps,

-Ted

-----Original Message-----
From: SeattleRobotics@yahoogroups.com
[mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Bryan
Sent: Tuesday, October 04, 2005 3:14 PM
To: SeattleRobotics@yahoogroups.com
Subject: [SeattleRobotics] Re: inverted pendulum

My encoder is from US Digital. It has 4000 counts per revolution. It
is connected to a binary counted which is connected to the
microcontroller. This way, the micro just reads the output from the
counter to get the angle so it doesn't ever miss a count. I am pretty
sure that the software isn't the problem but I will check over it
again.

I have played around with it some more and I have found that the
error is only introduced sometime after the motor has been powered
up. Does that give any clues? Maybe I should add a capacitor to the
motor. Are there any other possibilites?

Thanks

Bryan Hood

--- In SeattleRobotics@yahoogroups.com, Tom Capon <robot256@g...>
wrote:
> What kind of encoder hardware are you using? It's probably a
software
> glitch in the encoder counter routine. What CPU are you using? You
> might want to either up the CPU speed, put the encoder in a hardware
> interrupt routine, or do something else to give it more CPU time.
>
> The problem with the accelerometer is that its reading is dependent
> not only on the angle, but also on linear acceleration. If you have
> an accurate read of the linear velocity/acceleration of the base,
you
> might be able to calculate the angle with the accelerometer,
although
> it might be easier with a gyroscope. Probably the easiest solution
is
> just to fix the encoder.
>
> --Tom Capon
>
> On 10/4/05, Bryan <BNHrobotics@g...> wrote:
> > I have been working a lot on my inverted pendulum and I have come
to
> > a point where I am stuck. My encoder that measures angle works
> > reasonably well but sometimes it misses a few counts and sometimes
> > the angle turns out completely wrong. I also tried added a dual
axis
> > accelerometer to the mix. This can only measure the angle while
the
> > system is static.
> >
> > Can anyone give me advice on how to get an accurate angle reading?
> >
> > I tried finding the angle with the acclerometer using this
equation:
> >
> > ycos(angle)+xsin(angle)=g where x and y are the acceleration
> > readings from the sensor and the angle is the angle of the
pendulum.
> > This worked while everything was static but when there is any
other
> > acceleration involved, the angle reading goes crazy.
> >
> > To solve for angle, I had arcsin(1/(sqrt(x^2+y^2))-arccos(x/(sqrt
> > (x^2+y^2)).
> >
> > Any suggestions on what to do? Thanks. Any help is greatly needed
> > and appreciated.
> >
> > Bryan Hood
> >
> >
> >
> >
> > Visit the SRS Website at http://www.seattlerobotics.org
> >
> >
> >
> >
> >
> >
> >

Visit the SRS Website at http://www.seattlerobotics.org
• At one point I had been clearing and I fixed that. There was a noticeable change but I still had some slight problems. As soon as I turned the motor on the
Message 5 of 17 , Oct 5, 2005
At one point I had been clearing and I fixed that. There was a
noticeable change but I still had some slight problems. As soon as I
turned the motor on the error would become very large. I finally
determined that it was because there is enough play in the shaft
that when the cart bounced around on its track, the encoder would be
fooled.

I am pretty confidant that the counting mechanism including the
program and electronics I used were not the problem. I think that I
had cleared up all of those bugs. The errors turned out to only be
coming from the play in the shaft that the encoder was connected to.

By a stroke of luck, a potentiometer I had laying around fit
perfectly into my set-up. It was almost as though it was meant to
be. I hooked everything up and everything zeroed out perfectly and
there was no error in the angle. It is a bit noisy but that is not
nearly as bad as having errors in the angle. After a few minutes I
had the pendulum successfully balancing. The gains still needed
slight adjustments but at least it worked! I shot a video and
watched it for a few minutes. Then I left the room....big mistake.
The extra mass I had added to the top caused the whole thing to flip
off of its stool when it reached the end of the track. I have to do
some repairs before I can do anything further with that, but hey, at
least it worked! I guess it really is true that the simplest
solution is usually the best. That is when you have poor machining
skills like I do =P.

Thanks for all of the advice and help everyone. I really appreciate
it.

Bryan Hood

--- In SeattleRobotics@yahoogroups.com, "Ted Larson" <ted@l...>
wrote:
> Bryan,
>
> From your hardware description, and problem description of missing
pulses, a
> timing issue is where I would be looking for the problem. Do you
ever clear
> your counter? Or are you just incrementally grabbing the count
each time
> and adding? If you are clearing...then this is definitely the
problem. No
> matter how fast your microcontroller is, you could miss counts
between the
> time you clear, and the time you look for the next count. Make
sure if you
> are using an external counter like you describe, you are never
clearing it,
> and handle the overflow in software.
>
> Next...how are you handling direction? Is the counter up/down?
Do you have
> a flip-flop in there? What does your solution look like? Unless
you are
> using some kind of counter chip designed for dealing with a
> encoder, I'll bet beers that there is a timing problem there too.
>
> All it takes is a few missed pulses in a balancing problem to throw
> everything off. Most people miss pulses in their home-brew
> interfaces due to timing issues, but they never notice it because
they are
> doing velocity control on a motor or something.
>
> Here is a chip that costs \$5, that will solve the whole counting
problem for
> you flawlessly.
> http://www.lsicsi.com/pdfs/LS7366.pdf
>
> Hope this helps,
>
> -Ted
>
>
> -----Original Message-----
> From: SeattleRobotics@yahoogroups.com
> [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Bryan
> Sent: Tuesday, October 04, 2005 3:14 PM
> To: SeattleRobotics@yahoogroups.com
> Subject: [SeattleRobotics] Re: inverted pendulum
>
> My encoder is from US Digital. It has 4000 counts per revolution.
It
> is connected to a binary counted which is connected to the
> microcontroller. This way, the micro just reads the output from
the
> counter to get the angle so it doesn't ever miss a count. I am
pretty
> sure that the software isn't the problem but I will check over it
> again.
>
> I have played around with it some more and I have found that the
> error is only introduced sometime after the motor has been powered
> up. Does that give any clues? Maybe I should add a capacitor to
the
> motor. Are there any other possibilites?
>
> Thanks
>
> Bryan Hood
>
>
> --- In SeattleRobotics@yahoogroups.com, Tom Capon <robot256@g...>
> wrote:
> > What kind of encoder hardware are you using? It's probably a
> software
> > glitch in the encoder counter routine. What CPU are you using?
You
> > might want to either up the CPU speed, put the encoder in a
hardware
> > interrupt routine, or do something else to give it more CPU time.
> >
> > The problem with the accelerometer is that its reading is
dependent
> > not only on the angle, but also on linear acceleration. If you
have
> > an accurate read of the linear velocity/acceleration of the
base,
> you
> > might be able to calculate the angle with the accelerometer,
> although
> > it might be easier with a gyroscope. Probably the easiest
solution
> is
> > just to fix the encoder.
> >
> > --Tom Capon
> >
> > On 10/4/05, Bryan <BNHrobotics@g...> wrote:
> > > I have been working a lot on my inverted pendulum and I have
come
> to
> > > a point where I am stuck. My encoder that measures angle works
> > > reasonably well but sometimes it misses a few counts and
sometimes
> > > the angle turns out completely wrong. I also tried added a
dual
> axis
> > > accelerometer to the mix. This can only measure the angle
while
> the
> > > system is static.
> > >
> > > Can anyone give me advice on how to get an accurate angle
> > >
> > > I tried finding the angle with the acclerometer using this
> equation:
> > >
> > > ycos(angle)+xsin(angle)=g where x and y are the acceleration
> > > readings from the sensor and the angle is the angle of the
> pendulum.
> > > This worked while everything was static but when there is any
> other
> > > acceleration involved, the angle reading goes crazy.
> > >
> > > To solve for angle, I had arcsin(1/(sqrt(x^2+y^2))-arccos(x/
(sqrt
> > > (x^2+y^2)).
> > >
> > > Any suggestions on what to do? Thanks. Any help is greatly
needed
> > > and appreciated.
> > >
> > > Bryan Hood
> > >
> > >
> > >
> > >
> > > Visit the SRS Website at http://www.seattlerobotics.org
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
• Bryan, It s alive! It s ALIVE! Seriously, it does seem kind of alive, doesn t it? The way it reacts? Congratulations! best regards, dpa ... wrote:
Message 6 of 17 , Oct 5, 2005
Bryan,

It's alive! It's ALIVE!

Seriously, it does seem kind of alive, doesn't it? The way it
reacts?

Congratulations!

best regards,
dpa

--- In SeattleRobotics@yahoogroups.com, "Bryan" <BNHrobotics@g...>
wrote:
<snip>
> After a few minutes I
> had the pendulum successfully balancing. The gains still needed
> slight adjustments but at least it worked! I shot a video and
> watched it for a few minutes.
• Yeah, it defitinately did seem alive! It was a great few minutes while they lasted. After having all of that trouble its nice to see the work pay off. I just
Message 7 of 17 , Oct 5, 2005
Yeah, it defitinately did seem alive! It was a great few minutes
while they lasted. After having all of that trouble its nice to see
the work pay off. I just hope I can get it going again. =D

Thanks

Bryan

--- In SeattleRobotics@yahoogroups.com, "dpa_io" <dpa@i...> wrote:
> Bryan,
>
> It's alive! It's ALIVE!
>
> Seriously, it does seem kind of alive, doesn't it? The way it
> reacts?
>
> Congratulations!
>
> best regards,
> dpa
>
> --- In SeattleRobotics@yahoogroups.com, "Bryan" <BNHrobotics@g...>
> wrote:
> <snip>
> > After a few minutes I
> > had the pendulum successfully balancing. The gains still needed
> > slight adjustments but at least it worked! I shot a video and
> > watched it for a few minutes.
• Hi Guys, So, I m looking for a replacement IMU for my biped at hobby prices. When I graduated from Caltech I had to leave the nice Cloudap Crista IMU
Message 8 of 17 , Oct 17, 2005
Hi Guys,

So, I'm looking for a replacement IMU for my biped at hobby prices. When
I graduated from Caltech I had to leave the "nice" Cloudap Crista IMU
behind. I've been looking at the Sparkfun IMU.
http://www.sparkfun.com/shop/index.php?shop=1&cat=71
It comes assembled for \$350, but I still have to do the calibration. I'm
about to buy, but before I do, are there any other IMUs I should look at?

-Lyle
• FYI the sparkfun IMU is just a carrier for the inertial chips. You still need to do the math. I believe the Rotomotion IMU comes with the s/w to do the
Message 9 of 17 , Oct 17, 2005
FYI the sparkfun IMU is just a carrier for the inertial chips. You still
need to do the math. I believe the Rotomotion IMU comes with the s/w to do
the filtering & math and just outputs your position.

-----------
Larry Barello
www.barello.net

| -----Original Message-----
| From: SeattleRobotics@yahoogroups.com
| [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Lyle Joseph
| Chamberlain
| Sent: Monday, October 17, 2005 12:21 PM
| To: SeattleRobotics@yahoogroups.com
| Subject: [SeattleRobotics] Hobby IMU
|
| Hi Guys,
|
| So, I'm looking for a replacement IMU for my biped at hobby prices. When
| I graduated from Caltech I had to leave the "nice" Cloudap Crista IMU
| behind. I've been looking at the Sparkfun IMU.
| http://www.sparkfun.com/shop/index.php?shop=1&cat=71
| It comes assembled for \$350, but I still have to do the calibration. I'm
| about to buy, but before I do, are there any other IMUs I should look at?
| (I've already tried the Rotomotion).
|
• FWIW, I have the 1st generation sparkfun IMU, it s not in my biped yet but bench testing was easy, the data looks totally reasonable, and I m looking forward
Message 10 of 17 , Oct 17, 2005
FWIW, I have the 1st generation sparkfun IMU, it's not in my biped yet
but bench testing was easy, the data looks totally reasonable, and I'm
looking forward to really using it. They're good people and they make
good stuff. Far as I can tell from the web site, v2 is basically the
same thing only smaller and with a few extra features in the software.

On 10/17/05, Lyle Joseph Chamberlain <lyle@...> wrote:
> Hi Guys,
>
> So, I'm looking for a replacement IMU for my biped at hobby prices. When
> I graduated from Caltech I had to leave the "nice" Cloudap Crista IMU
> behind. I've been looking at the Sparkfun IMU.
> http://www.sparkfun.com/shop/index.php?shop=1&cat=71
> It comes assembled for \$350, but I still have to do the calibration. I'm
> about to buy, but before I do, are there any other IMUs I should look at?
> (I've already tried the Rotomotion).
>
> -Lyle
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
>
>
>
>
>
>
>
>
>

--
Redmond WA USA
http://www.natew.com/ <== for nerds
http://www.featherforum.com/ <== for birds
• I thought doing your own math is the fun part of owning a low-cost IMU ;-) -Ted ... From: SeattleRobotics@yahoogroups.com
Message 11 of 17 , Oct 18, 2005
I thought doing your own math is the fun part of owning a low-cost IMU ;-)

-Ted

-----Original Message-----
From: SeattleRobotics@yahoogroups.com
[mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Larry Barello
Sent: Monday, October 17, 2005 5:26 PM
To: SeattleRobotics@yahoogroups.com
Subject: RE: [SeattleRobotics] Hobby IMU

FYI the sparkfun IMU is just a carrier for the inertial chips. You still
need to do the math. I believe the Rotomotion IMU comes with the s/w to do
the filtering & math and just outputs your position.

-----------
Larry Barello
www.barello.net

| -----Original Message-----
| From: SeattleRobotics@yahoogroups.com
| [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Lyle Joseph
| Chamberlain
| Sent: Monday, October 17, 2005 12:21 PM
| To: SeattleRobotics@yahoogroups.com
| Subject: [SeattleRobotics] Hobby IMU
|
| Hi Guys,
|
| So, I'm looking for a replacement IMU for my biped at hobby prices. When
| I graduated from Caltech I had to leave the "nice" Cloudap Crista IMU
| behind. I've been looking at the Sparkfun IMU.
| http://www.sparkfun.com/shop/index.php?shop=1&cat=71
| It comes assembled for \$350, but I still have to do the calibration. I'm
| about to buy, but before I do, are there any other IMUs I should look at?
| (I've already tried the Rotomotion).
|

Visit the SRS Website at http://www.seattlerobotics.org
• Heh, yeah. You re right. But even with a commercial IMU, you have to do your own state estimation unless you have another position estimator such as GPS.
Message 12 of 17 , Oct 18, 2005
Heh, yeah. You're right. But even with a commercial IMU, you have to do
your own state estimation unless you have another position estimator such
as GPS. Rotomotion has a complete package, but the IMU itself cannot give
you stable position information.

I think my problem in writing a Kalman filter is guessing what inputs I'm
sending to the plant. I have these long springy legs applying unknown
forces measurable only with the load cells in the feet. I think that at
first I'll only measure orientation and model the ignore the plant inputs.
Later on I'll see if I can't get to velocity and acceleration.

Now that I can do whatever I want, I'm going to try and get some more
fluid hollywood-like motions by modeling each joint as a limited-bandwidth
spring-mass pair. I have force feedback from the feet, and hopefully
acceleration information from the body attached to the legs. My first
real goal is to get the robot to stand and exhibit fluid life-like motion
to disturbances. No real "control loop" other than just simulating
springs in all the joints. I'll add constrints to get the most life-like
cool looking motions I can. Not much science here. Just doing it for
fun. After that I may move to walking.

Sounds like I'll go for that IMU. Thanks guys!

-Lyle

On Tue, 18 Oct 2005, Ted Larson wrote:

>
> I thought doing your own math is the fun part of owning a low-cost IMU ;-)
>
> -Ted
>
>
> -----Original Message-----
> From: SeattleRobotics@yahoogroups.com
> [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Larry Barello
> Sent: Monday, October 17, 2005 5:26 PM
> To: SeattleRobotics@yahoogroups.com
> Subject: RE: [SeattleRobotics] Hobby IMU
>
> FYI the sparkfun IMU is just a carrier for the inertial chips. You still
> need to do the math. I believe the Rotomotion IMU comes with the s/w to do
> the filtering & math and just outputs your position.
>
> -----------
> Larry Barello
> www.barello.net
>
>
> | -----Original Message-----
> | From: SeattleRobotics@yahoogroups.com
> | [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Lyle Joseph
> | Chamberlain
> | Sent: Monday, October 17, 2005 12:21 PM
> | To: SeattleRobotics@yahoogroups.com
> | Subject: [SeattleRobotics] Hobby IMU
> |
> | Hi Guys,
> |
> | So, I'm looking for a replacement IMU for my biped at hobby prices. When
> | I graduated from Caltech I had to leave the "nice" Cloudap Crista IMU
> | behind. I've been looking at the Sparkfun IMU.
> | http://www.sparkfun.com/shop/index.php?shop=1&cat=71
> | It comes assembled for \$350, but I still have to do the calibration. I'm
> | about to buy, but before I do, are there any other IMUs I should look at?
> | (I've already tried the Rotomotion).
> |
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
>
>
>
>
>
>
>
>
>
>
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
>
>
>
>
>
>
>
>
>
>
• Lyle, I have been working on building a 9DOF IMU unit, that I can use on my RoboMagellan robot....once you throw GPS, odometery, and compass bearing in there,
Message 13 of 17 , Oct 19, 2005
Lyle,

I have been working on building a 9DOF IMU unit, that I can use on my
RoboMagellan robot....once you throw GPS, odometery, and compass bearing in
there, you suddenly have a 12x12 matrix. Agghhhh! Doing the Matrix
calculations on all of those angles at any reasonable rate is a nightmare.

As a result, I have been doing some google searches lately to try to find if
there is something I can use to simplify things, and I started stumbling
across all kinds of papers on using IMU's for tracking human motion in VR
environments, or for tracking human body motion for animation in films. The
basic idea is, to strap IMU's all over your body, move around, and be able
to have a numerical record of what you did to animate a figure, or move you
through a VR. Really high-tech stuff.

Anyway, when you start looking at all the axis, of all of these IMU's, the
math becomes really computationally intensive, primarily because of the
trig, and the Euler angle math you have to do. Plus, the human body doesn't
move perfectly around our joint angles, so measurement/estimation is more
difficult. As a result, most people are using Quaternions, instead of Euler
angles. Here is a brief rundown on what Quaternions are:
http://mathworld.wolfram.com/Quaternion.html

Lots of people in the animation field are already using them for
representing attitude, and rotation. It is considerably, mathematically,
cheaper and it is easy to represent an object rotated around an arbitrary
axis. So...I started doing some google searches on "quaternion motion", and
came up with way to many links to post here. Here is a sampling:
http://www.cs.brown.edu/people/jjl/pubs/laviola_acc2003.pdf
http://imaging.utk.edu/publications/papers/dissertation/goddard.pdf
http://www.ingentaconnect.com/content/maik/cosm/2001/00000039/00000005/00363
517

As I was reading your post, it occurred to me that this might be a way to
stabilize your biped, and where you can bring more measurements of where you
think the leg joints are, into the equation, without much additional
computation required.

I dunno if this is stuff you have looked at already, but it seemed like an
interesting way to go. It definitely has me thinking about how I can
simplify all those Euler angle calculations in that nasty 12x12 Kalman
matrix.

Thanks,

-Ted

-----Original Message-----
From: SeattleRobotics@yahoogroups.com
[mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Lyle Joseph
Chamberlain
Sent: Tuesday, October 18, 2005 1:37 PM
To: SeattleRobotics@yahoogroups.com
Subject: RE: [SeattleRobotics] Hobby IMU

Heh, yeah. You're right. But even with a commercial IMU, you have to do
your own state estimation unless you have another position estimator such
as GPS. Rotomotion has a complete package, but the IMU itself cannot give
you stable position information.

I think my problem in writing a Kalman filter is guessing what inputs I'm
sending to the plant. I have these long springy legs applying unknown
forces measurable only with the load cells in the feet. I think that at
first I'll only measure orientation and model the ignore the plant inputs.
Later on I'll see if I can't get to velocity and acceleration.

Now that I can do whatever I want, I'm going to try and get some more
fluid hollywood-like motions by modeling each joint as a limited-bandwidth
spring-mass pair. I have force feedback from the feet, and hopefully
acceleration information from the body attached to the legs. My first
real goal is to get the robot to stand and exhibit fluid life-like motion
to disturbances. No real "control loop" other than just simulating
springs in all the joints. I'll add constrints to get the most life-like
cool looking motions I can. Not much science here. Just doing it for
fun. After that I may move to walking.

Sounds like I'll go for that IMU. Thanks guys!

-Lyle

On Tue, 18 Oct 2005, Ted Larson wrote:

>
> I thought doing your own math is the fun part of owning a low-cost IMU
;-)
>
> -Ted
>
>
> -----Original Message-----
> From: SeattleRobotics@yahoogroups.com
> [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Larry Barello
> Sent: Monday, October 17, 2005 5:26 PM
> To: SeattleRobotics@yahoogroups.com
> Subject: RE: [SeattleRobotics] Hobby IMU
>
> FYI the sparkfun IMU is just a carrier for the inertial chips. You still
> need to do the math. I believe the Rotomotion IMU comes with the s/w to
do
> the filtering & math and just outputs your position.
>
> -----------
> Larry Barello
> www.barello.net
>
>
> | -----Original Message-----
> | From: SeattleRobotics@yahoogroups.com
> | [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Lyle Joseph
> | Chamberlain
> | Sent: Monday, October 17, 2005 12:21 PM
> | To: SeattleRobotics@yahoogroups.com
> | Subject: [SeattleRobotics] Hobby IMU
> |
> | Hi Guys,
> |
> | So, I'm looking for a replacement IMU for my biped at hobby prices.
When
> | I graduated from Caltech I had to leave the "nice" Cloudap Crista IMU
> | behind. I've been looking at the Sparkfun IMU.
> | http://www.sparkfun.com/shop/index.php?shop=1&cat=71
> | It comes assembled for \$350, but I still have to do the calibration.
I'm
> | about to buy, but before I do, are there any other IMUs I should look
at?
> | (I've already tried the Rotomotion).
> |
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
>
>
>
>
>
>
>
>
>
>
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
>
>
>
>
>
>
>
>
>
>

Visit the SRS Website at http://www.seattlerobotics.org
• Ted, Thanks for the info. Let me know if you find a faster way to implement your Kalman filter using quaternions. Unfortunately, i don t think a different
Message 14 of 17 , Oct 19, 2005
Ted,

Thanks for the info. Let me know if you find a faster way to implement

Unfortunately, i don't think a different basis set for state
representation will help much with my problem. As you know, the state
estimator predicts what it thinks the current state will be with a model
of the system dynamics and the known inputs (including actuation), and
then modifies this estimate based on what it actually observes and what it
expects to observe. In my case, the input to the state is from two legs
with moments and 6-DOF with unknown contact with the floor. Adding to the
problem, I don't know the torque being exerted at each joint because I'm
using just hobby servos. Finally, the legs can bend and have a little
play at each joint. So accurate measurement of the force the legs are
exerting on the body is nearly impossible, regardless of the internal
representation of state I choose.

I think this is one of the reasons the passive dynamics that people are
starting to build into walkers is what will ultimately make bipeds
practical. You don't rely on super-accurate state estimation and perfect
calibration. You let the computation occur at the joints themselves and
just do things like change spring impedance and driving frequency.

Anyway, sorry for rambling on. Thanks for bringing the whole quaternion
thing up again. I learned about them a couple years ago in a class, but I
wasn't planning on using them. Now I might use them for force propogation
calculations. let me know what you find if you use them for your state
estimator.

-Lyle

On Wed, 19 Oct 2005, Ted Larson wrote:

> Lyle,
>
> I have been working on building a 9DOF IMU unit, that I can use on my
> RoboMagellan robot....once you throw GPS, odometery, and compass bearing in
> there, you suddenly have a 12x12 matrix. Agghhhh! Doing the Matrix
> calculations on all of those angles at any reasonable rate is a nightmare.
>
> As a result, I have been doing some google searches lately to try to find if
> there is something I can use to simplify things, and I started stumbling
> across all kinds of papers on using IMU's for tracking human motion in VR
> environments, or for tracking human body motion for animation in films. The
> basic idea is, to strap IMU's all over your body, move around, and be able
> to have a numerical record of what you did to animate a figure, or move you
> through a VR. Really high-tech stuff.
>
> Anyway, when you start looking at all the axis, of all of these IMU's, the
> math becomes really computationally intensive, primarily because of the
> trig, and the Euler angle math you have to do. Plus, the human body doesn't
> move perfectly around our joint angles, so measurement/estimation is more
> difficult. As a result, most people are using Quaternions, instead of Euler
> angles. Here is a brief rundown on what Quaternions are:
> http://mathworld.wolfram.com/Quaternion.html
>
> Lots of people in the animation field are already using them for
> representing attitude, and rotation. It is considerably, mathematically,
> cheaper and it is easy to represent an object rotated around an arbitrary
> axis. So...I started doing some google searches on "quaternion motion", and
> came up with way to many links to post here. Here is a sampling:
> http://www.cs.brown.edu/people/jjl/pubs/laviola_acc2003.pdf
> http://imaging.utk.edu/publications/papers/dissertation/goddard.pdf
> http://www.ingentaconnect.com/content/maik/cosm/2001/00000039/00000005/00363
> 517
>
> As I was reading your post, it occurred to me that this might be a way to
> stabilize your biped, and where you can bring more measurements of where you
> think the leg joints are, into the equation, without much additional
> computation required.
>
> I dunno if this is stuff you have looked at already, but it seemed like an
> interesting way to go. It definitely has me thinking about how I can
> simplify all those Euler angle calculations in that nasty 12x12 Kalman
> matrix.
>
> Thanks,
>
> -Ted
>
>
> -----Original Message-----
> From: SeattleRobotics@yahoogroups.com
> [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Lyle Joseph
> Chamberlain
> Sent: Tuesday, October 18, 2005 1:37 PM
> To: SeattleRobotics@yahoogroups.com
> Subject: RE: [SeattleRobotics] Hobby IMU
>
> Heh, yeah. You're right. But even with a commercial IMU, you have to do
> your own state estimation unless you have another position estimator such
> as GPS. Rotomotion has a complete package, but the IMU itself cannot give
> you stable position information.
>
> I think my problem in writing a Kalman filter is guessing what inputs I'm
> sending to the plant. I have these long springy legs applying unknown
> forces measurable only with the load cells in the feet. I think that at
> first I'll only measure orientation and model the ignore the plant inputs.
> Later on I'll see if I can't get to velocity and acceleration.
>
> Now that I can do whatever I want, I'm going to try and get some more
> fluid hollywood-like motions by modeling each joint as a limited-bandwidth
> spring-mass pair. I have force feedback from the feet, and hopefully
> acceleration information from the body attached to the legs. My first
> real goal is to get the robot to stand and exhibit fluid life-like motion
> to disturbances. No real "control loop" other than just simulating
> springs in all the joints. I'll add constrints to get the most life-like
> cool looking motions I can. Not much science here. Just doing it for
> fun. After that I may move to walking.
>
> Sounds like I'll go for that IMU. Thanks guys!
>
> -Lyle
>
> On Tue, 18 Oct 2005, Ted Larson wrote:
>
> >
> > I thought doing your own math is the fun part of owning a low-cost IMU
> ;-)
> >
> > -Ted
> >
> >
> > -----Original Message-----
> > From: SeattleRobotics@yahoogroups.com
> > [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Larry Barello
> > Sent: Monday, October 17, 2005 5:26 PM
> > To: SeattleRobotics@yahoogroups.com
> > Subject: RE: [SeattleRobotics] Hobby IMU
> >
> > FYI the sparkfun IMU is just a carrier for the inertial chips. You still
> > need to do the math. I believe the Rotomotion IMU comes with the s/w to
> do
> > the filtering & math and just outputs your position.
> >
> > -----------
> > Larry Barello
> > www.barello.net
> >
> >
> > | -----Original Message-----
> > | From: SeattleRobotics@yahoogroups.com
> > | [mailto:SeattleRobotics@yahoogroups.com] On Behalf Of Lyle Joseph
> > | Chamberlain
> > | Sent: Monday, October 17, 2005 12:21 PM
> > | To: SeattleRobotics@yahoogroups.com
> > | Subject: [SeattleRobotics] Hobby IMU
> > |
> > | Hi Guys,
> > |
> > | So, I'm looking for a replacement IMU for my biped at hobby prices.
> When
> > | I graduated from Caltech I had to leave the "nice" Cloudap Crista IMU
> > | behind. I've been looking at the Sparkfun IMU.
> > | http://www.sparkfun.com/shop/index.php?shop=1&cat=71
> > | It comes assembled for \$350, but I still have to do the calibration.
> I'm
> > | about to buy, but before I do, are there any other IMUs I should look
> at?
> > | (I've already tried the Rotomotion).
> > |
> >
> >
> >
> > Visit the SRS Website at http://www.seattlerobotics.org
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Visit the SRS Website at http://www.seattlerobotics.org
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
>
>
>
>
>
>
>
>
>
>
>
>
>
> Visit the SRS Website at http://www.seattlerobotics.org
>
>
>
>
>
>
>
>
>
>
• the Quaternion references are great, thanks for the info. I ld be curious to see how you are using them. Keith Rowell http://knewt.blogspot.com/ ... my ...
Message 15 of 17 , Oct 20, 2005
the Quaternion references are great,
thanks for the info. I'ld be curious to see how you are using them.

Keith Rowell

http://knewt.blogspot.com/

--- In SeattleRobotics@yahoogroups.com, "Ted Larson" <ted@l...>
wrote:
>
> Lyle,
>
> I have been working on building a 9DOF IMU unit, that I can use on
my
> RoboMagellan robot....once you throw GPS, odometery, and compass
bearing in
> there, you suddenly have a 12x12 matrix. Agghhhh! Doing the
Matrix
> calculations on all of those angles at any reasonable rate is a
nightmare.
>
> As a result, I have been doing some google searches lately to try
to find if
> there is something I can use to simplify things, and I started
stumbling
> across all kinds of papers on using IMU's for tracking human
motion in VR
> environments, or for tracking human body motion for animation in
films. The
> basic idea is, to strap IMU's all over your body, move around, and
be able
> to have a numerical record of what you did to animate a figure, or
move you
> through a VR. Really high-tech stuff.
>
> Anyway, when you start looking at all the axis, of all of these
IMU's, the
> math becomes really computationally intensive, primarily because
of the
> trig, and the Euler angle math you have to do. Plus, the human
body doesn't
> move perfectly around our joint angles, so measurement/estimation
is more
> difficult. As a result, most people are using Quaternions,