If you were Registered and logged in, you could reply and use other advanced thread options
|
Posted by Patrick Themessl on April 7, 2008, 5:18 pm
Hello,
we are participating in a competition held by a local university where
each of the participants got a circular hexapod robot that has to be
trained to run as fast and as smooth as possible. The smoothness of the
motion is measured by a little cup located in a larger cup that is fixed
to the hexapod, where the inner cup is filled with water and has a scale
on it. So far so good... However, we are facing a problem here that has
already cost us quite a lot of time:
Whenever one of the three-leg pairs of the tripod gait we implemented
hits the floor, the whole body of the hexapod suffers quite a bump that
spills a lot of water, which we want to avoid. We have done the servo
linearization and the hexapod calibration very, very exactly and are
able to set the footpoint to almost any point with an accuracy of less
than a millimeter, but there are still those annoying bumps when
walking. We have tried to just make the part of the movement where the
legs are set down to the floor slower, but then the deceleration and
acceleration in horizontal direction causes another impulse on the water
cup and spills almost the same amount of water than the bump we are
avoiding with it.
And to be honest, I have spent so much time in front of this f****** AVR
IDE in the last few days that I think I'm going to go crazy right now,
so I would really, really appreciate any suggestion we can get. This
concern is also quite urgent, as the competition takes place this
thursday! Please help!
Thanks in advance for your replies!
Yours sincerely,
Patrick Themessl.
P.S.: Sorry if my English isn't perfect, I'm Austrian. Smile
|
|
Posted by cadcoke4 on April 7, 2008, 7:18 pm
>We have tried to just make the part of the movement where the
> legs are set down to the floor slower, but then the deceleration and
> acceleration in horizontal direction causes another impulse on the water
In robotics, it is generally good to have an acceleration/
deacceleration curve for all movements. If you had some success
making a more gentle curve for the up/down motion, then perhaps you
also need to add this for the front/back movement.
By the way, servos often have their own internal acceleration/
deacceleration curves. The best servos allow you to adjust this curve
(by some sort of digital interface). There is also some "dead space"
where the servo won't attempt to move. I've also played with cheap R/
C servos and been able to adjust some of its "tightness" by changing
the rate at which I send pulses to them. Normally, a pluse lasting 1
to 2 ms is sent every 20 ms. But, by increasing or decreasing the
20ms value, you can adjust how quickly the servo acts to correct its
position.
Joe Dunfee
|
|
Posted by Patrick Themessl on April 8, 2008, 3:40 pm
Hi Joe,
thanks for your reply.
I will try varying the frequency of servo pulsing and see if this has an
effect.
The robot is actually not one produced by Lynxmotion, I was just looking
up "robotics forum" in Google and this is where I was led and because of
the fact that their hardware seems to be very similar to the hexapod we
have, I thought I'll take a chance asking. An image of the hexapod we
have can be found here:
http://forum.hexapod.at/forum/galerie/bilder/bild-99.jpg
Hardware modifications are unfortunately not allowed, so we have to live
without any feedback.
At the moment, I am thinking that one of the main problems we are having
is that the CPU speed of the µC located at the board is just too slow.
When working with an incrementation of 1 for each cycle of the gait
sequencer loop, the hexapod seems to stay relatively stable, but much
too slow. The only way to make it go faster is incrementing by 2 for
each loop cycle, as there is no artificial delay in our code anywhere
and the µC is operating at its limit, but then (especially in the leg-up
and leg-down sections) the movement gets too unexact. To solve this, we
tried to pre-calculate the servo angles for steps in each direction we
want, but then the program gets too large to fit on the µC.
Another question: Does anyone know a web site where a tripod gait that
does not stop the body of the hexapod for changing the stance legs is
explained in detail? I think I am having some conceptual errors in my
code, too.
Thank you very much for your help!
Patrick.
cadcoke4 schrieb:
>> We have tried to just make the part of the movement where the
>> legs are set down to the floor slower, but then the deceleration and
>> acceleration in horizontal direction causes another impulse on the water
>
> In robotics, it is generally good to have an acceleration/
> deacceleration curve for all movements. If you had some success
> making a more gentle curve for the up/down motion, then perhaps you
> also need to add this for the front/back movement.
>
> By the way, servos often have their own internal acceleration/
> deacceleration curves. The best servos allow you to adjust this curve
> (by some sort of digital interface). There is also some "dead space"
> where the servo won't attempt to move. I've also played with cheap R/
> C servos and been able to adjust some of its "tightness" by changing
> the rate at which I send pulses to them. Normally, a pluse lasting 1
> to 2 ms is sent every 20 ms. But, by increasing or decreasing the
> 20ms value, you can adjust how quickly the servo acts to correct its
> position.
>
> Joe Dunfee
|
|
Posted by Rich Webb on April 7, 2008, 7:39 pm
On Mon, 07 Apr 2008 23:18:43 +0200, Patrick Themessl
>Hello,
>we are participating in a competition held by a local university where
>each of the participants got a circular hexapod robot that has to be
>trained to run as fast and as smooth as possible. The smoothness of the
>motion is measured by a little cup located in a larger cup that is fixed
>to the hexapod, where the inner cup is filled with water and has a scale
>on it. So far so good... However, we are facing a problem here that has
>already cost us quite a lot of time:
>Whenever one of the three-leg pairs of the tripod gait we implemented
>hits the floor, the whole body of the hexapod suffers quite a bump that
>spills a lot of water, which we want to avoid.
Try one leg at a time, in the sequence (using DIP numbering, 1 = left
front) 1 - 5 - 3 - 6 - 2 - 4 ... You still have your triplets (1, 5, 3
and 6, 2, 4) but now you have six small taps instead of two kalumps.
>P.S.: Sorry if my English isn't perfect, I'm Austrian. Smile
8-)
--
Rich Webb Norfolk, VA
|
|
Posted by John Nagle on April 7, 2008, 9:39 pm
Patrick Themessl wrote:
> Hello,
>
> we are participating in a competition held by a local university where
> each of the participants got a circular hexapod robot that has to be
> trained to run as fast and as smooth as possible.
This person also asked the same question on a Lynxmotion support
forum, at
http://www.lynxmotion.net/viewtopic.php?p9015&sid 6fc52e8197b373af7d723a668215c3
The discussion there is more informative. He's apparently using a Lynxmotion
CH3-R robot:
http://www.lynxmotion.com/Category.aspx?CategoryID 1
This is a nice piece of machinery, but has no useful feedback.
For over $700, there should be more sensors on the thing, enough to
do what Rod Brooks was doing twenty years ago with his insect
robots. But no. There's no force feedback signal for the
servos. There don't even seem to be foot/ground contact
switches. It's a dumbbot.
The typical programming approach is to put a table of leg position values
into an Excel spreadsheet and load those onto the robot's CPU.
Given that you have no useful info about what the legs are doing,
that's probably as good as it gets.
John Nagle
|
Page 1 of 5 1 2 3 > last >>
Related Posts
Latest Posts
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map
> legs are set down to the floor slower, but then the deceleration and
> acceleration in horizontal direction causes another impulse on the water