 |
Subject:
|
Balancing robots
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 20 Jan 2004 21:19:20 GMT
|
Original-From:
|
PeterBalch <peterbalch@#StopSpam#compuserve.com>
|
Viewed:
|
1567 times
|
| |
|
|
How does a balancing robot like Legway balance on a patterned floor? Or can
it?
I've got some of the way there.
My understanding from reading the web descriptions of various projects is
that you _ought_ to measure
- angle of tilt
- rate of change of tilt
- position of wheel
- rate of change of wheel
If you have only IR sensors then you can measure the rate of change of tilt
on a plain floor. If you assume that when the robot is turned on, the IR
measurement is "upright" then you can estimate absolute tilt. If you
integrate the motor commands over a few seconds and you're mostly heading
"forwards" then you adjust the "upright" estimate.
But the Legway (for instance) can't measure the position of wheel or the
wheel velocity. You can pretend that the motor commands correspond to the
wheel velocity and smooth or integrate those numbers. That helps with
balance but the results (in my simulation) are never as good as a robot
that has wheel encoders. Is it possible to measure wheel velocity by
measuring the motor back-emf?
On a patterened floor, maybe you can have several IR sensors and discard
the measurements with the bigest changes on the assumption that they
represent a change in the pattern.
Has anyone tried it?
Peter
|
|
| |
Hello PeterBalch,
Tuesday, January 20, 2004, 9:19:20 PM, you wrote:
P> How does a balancing robot like Legway balance on a patterned floor? Or can
P> it?
P> I've got some of the way there.
P> My understanding from reading the web descriptions of various projects is
P> that you _ought_ to measure
P> - angle of tilt
P> - rate of change of tilt
P> - position of wheel
P> - rate of change of wheel
P> If you have only IR sensors then you can measure the rate of change of tilt
P> on a plain floor. If you assume that when the robot is turned on, the IR
P> measurement is "upright" then you can estimate absolute tilt. If you
P> integrate the motor commands over a few seconds and you're mostly heading
P> "forwards" then you adjust the "upright" estimate.
P> But the Legway (for instance) can't measure the position of wheel or the
P> wheel velocity. You can pretend that the motor commands correspond to the
P> wheel velocity and smooth or integrate those numbers. That helps with
P> balance but the results (in my simulation) are never as good as a robot
P> that has wheel encoders. Is it possible to measure wheel velocity by
P> measuring the motor back-emf?
P> On a patterened floor, maybe you can have several IR sensors and discard
P> the measurements with the bigest changes on the assumption that they
P> represent a change in the pattern.
P> Has anyone tried it?
P> Peter
|P> How does a balancing robot like Legway balance on a patterned floor? Or can
|P> it?
|
|P> I've got some of the way there.
|
|P> My understanding from reading the web descriptions of various projects is
|P> that you _ought_ to measure
|P> - angle of tilt
|P> - rate of change of tilt
|P> - position of wheel
|P> - rate of change of wheel
|
|P> If you have only IR sensors then you can measure the rate of change of tilt
|P> on a plain floor. If you assume that when the robot is turned on, the IR
|P> measurement is "upright" then you can estimate absolute tilt. If you
|P> integrate the motor commands over a few seconds and you're mostly heading
|P> "forwards" then you adjust the "upright" estimate.
|
|P> But the Legway (for instance) can't measure the position of wheel or the
|P> wheel velocity. You can pretend that the motor commands correspond to the
|P> wheel velocity and smooth or integrate those numbers. That helps with
|P> balance but the results (in my simulation) are never as good as a robot
|P> that has wheel encoders. Is it possible to measure wheel velocity by
|P> measuring the motor back-emf?
|
|P> On a patterened floor, maybe you can have several IR sensors and discard
|P> the measurements with the bigest changes on the assumption that they
|P> represent a change in the pattern.
|
|P> Has anyone tried it?
P> Peter
I built a Legway clone using two standard lego light sensors, both pointing
down, one on the front one on the back. Control was via a PID type
algorithm. The actual
control wasn't that robust and only worked well in a darkened room but
it did balance and I could get it to spin on the spot. I don't have the
code to hand at the moment but this is a basic pseudo listing.
offset = light_sensor_front - light sensor back;
/*light sensors don't produce an equall reading so need to be matched using an offset.
This is achieved by holding the bot vertically while it takes a
reading*/
while(1)
{
error = light_sensor_front - light sensor back + offset;
error_rate = (error - error_old)/2;
error_int = (error + error_old)/2 + error_int;
error_old = error;
/*PID*/
error_total = (KP * error) + (KI * error_int) + (KD *
error_rate);
if (error_total >= 1)
{
motor direction = forward;
}
else
{
motor direction = reverse;
error_total = -error_total;
}
motor_PWM = error_total
wait 20ms;
}
Think that's it, probably mistakes. That code will just do basic
balance, if you want to move forward alter offset. If you want to
spin use one of the above code blocks for each wheel.
Probably not the best code and no where near as god as Steve's but it
does the job, sort of.
I'm currently messing with a homemade accelerometer circuit. (ADXL105)
and a fe gyroscopes. I've sucessfully interfaced these to the RCX. The
fun is just starting!
Good luck
Allen
--
Best regards,
Allen mailto:Kaptain.korolev@ntlworld.com
|
|
| |
>
> I built a Legway clone using two standard lego light sensors, both pointing
> down, one on the front one on the back. Control was via a PID type
> algorithm. The actual
> control wasn't that robust and only worked well in a darkened room but
> it did balance and I could get it to spin on the spot. I don't have the
> code to hand at the moment but this is a basic pseudo listing.
Hi Allen,
Could you post the actual code and perhaps a photograph of your robot, I want to
try that for a while and it would eliminate some fiddling!
TIA,
Philo
|
|
| |
Hello Philippe,
Wednesday, January 21, 2004, 1:18:03 PM, you wrote:
> >
> > I built a Legway clone using two standard lego light sensors, both pointing
> > down, one on the front one on the back. Control was via a PID type
> > algorithm. The actual
> > control wasn't that robust and only worked well in a darkened room but
> > it did balance and I could get it to spin on the spot. I don't have the
> > code to hand at the moment but this is a basic pseudo listing.
PH> Hi Allen,
PH> Could you post the actual code and perhaps a photograph of your robot, I want to
PH> try that for a while and it would eliminate some fiddling!
PH> TIA,
PH> Philo
Hi,
I'll try and find the code and grab a picture of the bot at the
weekend. I'm snowed under at the minute with a progress report on my
university project. I don't have the code to hand at the minute
as it's on an old computer that I use for Mindstorms stuff. The code
itself is not more complicated that the pseudo listing I gave you,
nothing like what Steve wrote for the Legway. I'll also try and take a
few small mpegs to stik on the web of it doing it's stuff.
--
Best regards,
Allen mailto:Kaptain.korolev@ntlworld.com
|
|
| |
> I'll try and find the code and grab a picture of the bot at the
> weekend. I'm snowed under at the minute with a progress report on my
> university project.
Thanks a lot ! I'm not in a hurry ;o)
Philo
|
|
| |
In lugnet.robotics, PeterBalch <PeterBalch@compuserve.com> wrote:
>
> How does a balancing robot like Legway balance on a patterned floor? Or can
> it?
>
> But the Legway (for instance) can't measure the position of wheel or the
> wheel velocity. You can pretend that the motor commands correspond to the
> wheel velocity and smooth or integrate those numbers. That helps with
> balance but the results (in my simulation) are never as good as a robot
> that has wheel encoders. Is it possible to measure wheel velocity by
> measuring the motor back-emf?
I don't think there's a good source for this data (motor back-emf) using an RCX.
Yes, Legway just used the motor commands to simulate the wheel velocity. It
would have greatly increased the complexity of the wheel assembly to add
rotation sensors, including adding 'slop' into the drivetrain.
> On a patterened floor, maybe you can have several IR sensors and discard
> the measurements with the bigest changes on the assumption that they
> represent a change in the pattern.
>
> Has anyone tried it?
Legway uses two sensors to follow a line. So when one of the sensor readings
drop, it assumes the sensor is over the line, it ignores that sensor, and turns
the robot in that direction.
It also seems to work pretty well on wood grain (like a table top).
But it must have one of it's (two) sensors over a white (or light) area, or it
doesn't get usable readings from the EOPDs.
I think you could make the same scheme work on a patterned floor, if you can
mount the sensors so at least one of them is on a light area. Or, you may be
able to find sensors that are not affected by the surface color. For example,
an ultrasonic sensor may work well for that.
Steve
Steve
|
|
|
Subject:
|
Re: Balancing robots
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 22 Jan 2004 15:41:13 GMT
|
Original-From:
|
Jim Choate <ravage@einstein.ssz.*NoMoreSpam*com>
|
Viewed:
|
1845 times
|
| |
|
|
On Thu, 22 Jan 2004, Steve Hassenplug wrote:
> In lugnet.robotics, PeterBalch <PeterBalch@compuserve.com> wrote:
> >
> > How does a balancing robot like Legway balance on a patterned floor? Or can
> > it?
> >
> > But the Legway (for instance) can't measure the position of wheel or the
> > wheel velocity. You can pretend that the motor commands correspond to the
> > wheel velocity and smooth or integrate those numbers. That helps with
> > balance but the results (in my simulation) are never as good as a robot
> > that has wheel encoders. Is it possible to measure wheel velocity by
> > measuring the motor back-emf?
>
> I don't think there's a good source for this data (motor back-emf) using an
> RCX.
Um, the back-EMF of the motore isn't related to the motor load per se but
rather the relaxation of the current in the coil when it moves off the
stators. It's also very fast (ie E=Bc) so the RCX isn't likely to get good
readings for this. It's very hard to measure back-EMF accurately without
some sort of delay line on the measurement channel (ie what is being
measured), with regard to the trigger channel (ie when to measure). On a
scope one uses a delay line between the trigger input and the actual
vertical amp input.
Actually it's pretty easy, measure the current on the motor. As the
velocity goes up the current goes up, the catch is if the motor stalls.
You're solution must include a 'step function' test to look for this.
It's reasonably easy to equate the F=ma for the robot to the F put out by
the motor, derived from F=BILsin(theta).
The difference between resistance and the motor force gets converted into
motion.
The simplest way to measure the current is to put a small resistor in
series with the motor and measure it's voltage drop (ie E=IR).
Another way to measure wheel velocity is to have a switch on the axle and
measure how often it gets closed. Working issues of geometry from circular
to linear acceleration is reasonably simple so I won't bore you with
details. I like the wheels that have good tread, they give you a lot
better place to put such a switch. More data points (ie ridges in the
tread) mean more precise measurements, integration functions related
to dx. The distance between sample points on the axle is the minimum dx
that you can use and get non-GIGO numbers out the other side. More points
per circumfrence means more accurate dx measures.
Good luck with it.
-- --
Open Forge, LLC 24/365 Onsite Support for PCs, Networks, & Game Consoles
512-695-4126 (Austin, Tx.) help@open-forge.com irc.open-forge.com
Hangar 18 Open Source Distributed Computing Using Plan 9 & Linux
512-451-7087 http://open-forge.org/hangar18 irc.open-forge.org
James Choate 512-451-7087 ravage@ssz.com jchoate@open-forge.com
|
|
| |
Hi all
We've just returned from holiday and our Lego is locked up for the summer but
For what its worth I have added a version of my code to
http://zandeg.spectacle.co.nz/robot
You can see what I did to mod Steve's program to work with two standard Lego
light sensors. The output of one of the sensors is scaled so they both return
similar values.
My kitchen floor is vinyl with a brown/blue mottled tiled pattern and I'd say
it balances in a "more tolerant" fashon than on the white table. It probably
oscillates more often but more gently so falls are less dramatic.
cheers H
|
|
| |
>
> I'll try and find the code and grab a picture of the bot at the
> weekend. I'm snowed under at the minute with a progress report on my
> university project. I don't have the code to hand at the minute
> as it's on an old computer that I use for Mindstorms stuff. The code
> itself is not more complicated that the pseudo listing I gave you,
> nothing like what Steve wrote for the Legway. I'll also try and take a
> few small mpegs to stik on the web of it doing it's stuff.
As I was stuck home yesterday by a sore throat, I had plenty of time to build a
legway clone that works quite well using an adapted version of your generic
code. I choose to ease the problem by lowering center of gravity (I put the
bottom of RCX between the motors, not above) so it balances well even with
non-optimal light conditions.
I'll try to post some videos and code in the near future...
Philo
|
|
|
