Let's Make Robots!

Triffid (Three-wheeled Lego Mindstorms robot with omniwheels)

Trigonometry mostly, so that it can decide where to go next. Also avoids obstacles …

<p>I'm not sure if you allow Lego robots on this site, but here she is anyway.<p>

<p>Since getting into Lego Mindstorms I've made and subsequently dismantled several Lego bots with wheels and tracks (can't afford to keep them all), but this one's interesting enough to keep and develop further.</p>

<p>I started off making her with my old NXT brick, but discovered when it came to programming her that a) NXT bricks can't do trigonometry, and b) they can't do much else in the way of interesting maths either. I'll continue programming it in LABview when NI finally get around to supporting the new(ish) EV3 brick.</p>

<p>Doing anything even slightly advanced in the simple graphical IDE that Lego provides free for kids to programme Mindstorms robots with is frustrating in the extreme. The programme ends up literally metres long and keeping control of the whole thing becomes impractical (at least if your memory is as bad as mine is post-encephalitis, and I hope for your sake it isn't).</p>

<p>So she bounces off the walls on her touch sensors atm where I don't have enough ultrasound or IR sensors to go round, and otherwise manages to scoot around the house all right, tormenting the dogs and amusing the husband (he's a tolerant man … so far).</p>

<p>I have an idea of making a sort of treasure hunt with coloured paper, hence the colour sensor on the underside. Not sure how practical that is … </p>

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I've had a similar problem on a little microcontroller before. I'm not sure it will help in your case but its not too hard to use taylor series expansion (http://en.wikipedia.org/wiki/Taylor_series#List_of_Maclaurin_series_of_some_common_functions) using simple math expressions. For example here is a sin function in python using taylor series (sorry not sure how to post pretty code):

from numpy import sin

x = 5.0

 

def factorial(j):

"""there is a built in factorial function but I'm showing how its done"""

output = 1.0

for k in range(1, j+1):

output = output * k

return output

 

 

def sin_Taylor_Series(x, n):

"""return the sin of x using taylor series expansion with n iterations"""

y = 0.0

for i in range(n+1):

y = y + x**(2*i + 1) * (-1)**i/factorial(2*i + 1)

return y

 

print sin(x)

print sin_Taylor_Series(x, 9)

 

This outputs

-0.958924274663

-0.958933165197

 

Its accurate enough. 

… but my head swims just looking at it. I have a chronic neurological illness which prevents me from mentally tackling anything too new and difficult. Also, I'm using LabVIEW, which is a graphical programming environment.

if you are gettign frustrated with the lego software you could always try lejos http://www.lejos.org its a java implamentation for the mindstorms system, might let you try some more complicacted stuff.

…which is limiting me. My software is LabVIEW which is very good, but the NXT brick can't do trigonometry. Thanks for the suggestion though.

I agree with birdmun, Lego bots are welcome on LMR. I think the only caveat is the robot should be customized by the builder and not based on the standard kit instructions.

I'm a fan of omni directional wheels myself. I have a three wheeled omni bot and after arguing with OddBot about the mathematics involved with omni wheel speeds, I made a tip/walkthrough on the subject of omni wheel math.

There are several other omni wheeled robots on LMR. Some are four wheel versions and some are three wheeled bots. There's something about the three wheeled omni bots that I find very appealing.

I hope we get to see a video of your robot in action sometime soon.

… has left me unable to deal with mental challenges such as bending my brain around your equations, but the equation which seemed right and proper to me when I came to programme the Triffid was based on the idea that each wheel should contribute to the direction and speed of the robot in proportion to the angle by which its drive angle differs from the angle of direction of travel of the robot, if that makes sense … sorry, it's a bit convoluted.

I used the cosine function on each wheel to control the robot’s direction of travel, as it can be conceptualised as being the ratio of the lengths of the two rays leading out from the centre of a circle (i.e. the centre of the robot), separated by the angle which is fed into the cos function in degrees. One of the rays represents the desired direction of robot travel, and the other represents, for each wheel, the direction of drive of the wheel itself, so the cosine of this angle gives, for each wheel, the extent to which its direction of drive can contribute usefully to the desired direction of robot travel (I hope :-). The product of 'cos(angle)' is then multiplied by 100 to turn the decimal value into a percentage, as each Lego motor is controlled by a number from +100 (forward) to -100 (reverse).

If the wheel is pointing in the direction of robot travel the angle is 0º, and cos(0) = 1, i.e. 100% power to the wheel.

If the wheel is pointing 90º from the direction of robot travel, cos(90) = 0, i.e. 0% power to the wheel.

If the wheel is pointing 45º from the direction of robot travel, cos(45) = 0.71, i.e. 71% power to the wheel.

I'm not sure if this is another way of saying what you're saying or not; my head starts to throb and my brain freezes when I even think about it.

I'm not saying this is necessarily the best, or even the right way to programme a three-wheel omnibot, but my brain simply gives up at this point. Triffid goes in the direction expected when this code is run, which is a start.

But the main flaw I can see, for starters, is if two of the wheels are pointing 45º from the direction of robot travel and the third is at 90º. The third wheel is of course given zero power, but the other two are still only getting 71% power each themselves, and I see no reason why greater speed should not be achieved by having them both at 100% power in this situation. Triffid won't be entered in any sort of competition, so slightly reduced performance doesn't matter to me.

I did consider (and am still considering) a three-wheeled omnibot with the wheels facing outwards, so to speak, i.e. 90º from the angle that they're usually fixed. It would be faster, in theory at least, because if you have two wheels facing 45º from direction of robot travel, then the third will be at 0º to robot travel, and run on 100% power, rather than the more conventional 90º and zero power. Possibilities, possibilities … 

My research before building Triffid led me to the discovery that three-wheeled omnibots are inevitably slower than their four-wheeled cousins, as a four-wheeled omnibot can have up to two wheels at full power and angled at the direction of robot travel, which the three-wheeled omnibot can never have.

But people still like to build three-wheeled omnibots, nevertheless, I think mainly because they are intriguing and pose interesting challenges, such as the more complex maths and the question of where the 'front' is, if they even have one, et cetera. A book could usefully be written on the subject, I expect.

You are very close to having this figured out. Your initial calculation about how fast the wheel should turn based on the angle is dead on. Your guess that what you were saying was just another way of expressing the equation I posted is correct.

But then you let the counter intuitive stuff and the bad research confuse the issue (by "bad research" I mean your finding bad information, not that you're not good a researching this). An omni bot with four wheels does not travel fastest with two wheels aligned with the direction of travel. Rather it will be at its fastest when all the wheels are 45 degrees from the direction of travel.

Think back to what you said about having one wheel 90 degrees from the direction of travel. This 90 degree wheel should have the speed of cos(90) = 0. This makes sense. It's just being dragged by its rollers. The other two wheels will be angled 30 degrees to the direction of travel (not 45). So the power given to these wheels is cos(30) or 87% of what a wheel aligned with the direction of travel would require. The 90 degree wheel is rotating at 0% speed but it's still moving with the robot at 100% speed. The 30 degree wheels are rotating at 87% speed but the robot is still traveling at 100% speed.

As you suggest, there's no reason why the 87% speed wheels shouldn't be sped up to 100%. But if the wheels are rotating at 100% speed how fast will the robot be traveling? If the robot was at 100% with 87% wheel speed it will now travel at 115% speed if the wheels are rotating at 100%! Free speed (sort of).

The robot doesn't really travel at a full 115% speed since there's additional friction with all the wheels pointed away from the direction of travel. Even if the speed is 115% it will still be significantly faster than 100%.

Another way to look at it is to have one wheel aligned with the direction of travel. The wheel at zero degrees has to travel at 100% speed to give the robot 100% speed. The other two wheels will be 60 degrees out of alignment. cos(60) = .5 so the math gets easier. How fast do these 60 degree wheels need to turn? .5 * 100% = 50%. The two out of alignment wheels just need to turn half as fast as the aligned wheel. So which wheel is limiting the speed? The one turning at a full 100%. The other wheels could turn faster if asked. It's the aligned wheel that's slowing the bot down!. Your robot will be able to travel faster if you don't have any wheels aligned with the direction of travel than when a wheel is aligned.

I think it would be cool to have wheels that could have their direction of travel changed on the fly. This would allow one to control the speed of the robot by changing the angle of wheel alignment. Want to go faster? Angle the wheels away from the direction of travel and it will increase in speed. This will only work up to a point of course. Your robot isn't going to go infinitely fast by pointing your wheels 90 degrees to the direction of travel. You should be able to have the robot go nearly twice as fast by angling them at 60 degrees.

BTW, this means your robot won't travel any faster if you rotate your wheels 90 degrees from their current alignment. If you left one wheel as is and rotated the other two, then you would have a faster robot.

Edit(April 25, 2014): Added comment about "bad research". There's a lot of bad information concerning omni wheels on the internet.

… since I did the programming. Seems I can't even edit my own post to correct the mistake.

Sorry, but I still can't see it, quite, though I think I got an inkling, just a glimmering of what you mean in this paragraph (though I'd be wary of the inevitable differences between theory and practice here):

"Another way to look at it is to have one wheel aligned with the direction of travel. The wheel at zero degrees has to travel at 100% speed to give the robot 100% speed. The other two wheels will be 60 degrees out of alignment. cos(60) = .5 so the math gets easier. How fast do these 60 degree wheels need to turn? .5 * 100% = 50%. The two out of alignment wheels just need to turn half as fast as the aligned wheel. So which wheel is limiting the speed? The one turning at a full 100%. The other wheels could turn faster if asked. It's the aligned wheel that's slowing the bot down!. Your robot will be able to travel faster if you don't have any wheels aligned with the direction of travel than when a wheel is aligned."

I wouldn't assume that because the 0º wheel is powered to its maximum, that it's necessarily spinning at its maximum; it may be obstructed by the two 60º wheels. it strikes me that perhaps it's the cosine function which is not absolutely ideal for the actual practice of robot propulsion, and that it might be the two wheels at 60º which are slowing the robot down, just as the 87% power/30º wheels were in your earlier paragraph. I've had my reservations about the practical aptness of the cosine function since starting this project, so I'm still not sure about this last sentence.

"Your robot will be able to travel faster if you don't have any wheels aligned with the direction of travel than when a wheel is aligned."

There does also seem to me to be a need for greater clarity around the use of percentages here, and a clearer distinction between robot speeds and wheel speeds. Off the top of my head, there is robot potential speed within its own harware limits, which would have a maximum of 100% and to which all the wheels contribute in varying degrees, not necessarily optimally; robot actual speed which, with improved programming, can be >100% compared to a previous programmed state, as you mention yourself; rotational wheel speed as conventionally measured in RPM in the direction perpendicular to the wheel axis as travelled by a conventional (non omni) wheel; omniwheel speed as actually experienced by an omniwheel travelling at a variable angle from the perpendicular to its axis as a sort of distance/time quotient with respect to its rotational wheel speed (I think) which, it seems to me, would have no theoretical limit and perhaps no useful, easily quantifiable, definition, and is limited in practice by friction on the rollers. This last seems to me a somewhat nebulous concept, not easily predictable.

Phew! My head is throbbing … got to stop.

Thanks for drawing my attention to all this; it's interesting, if bad for the brain.

Our web dev is on sick leave at the moment, and, he has been in the midst of tearing down/rebuilding the site. One thing I have noticed is the text formatting bar appears when I preview my post. That seems to allow for proper formatting. Re: color sensor. "Our fearless leader", frits, put together a color sensor some years back http://letsmakerobots.com/node/1833 . It seems to be a different design from what you have, so, I can't comment on how well one works vs the other.

If you run out of things to teach your bots to do, check out the challenges link at the top of the page. Obviously there will be some design specific challenges your robot can't perform, but, at last recollection many should be possible.

… like a pretty nuts and bolts design compared to my proprietary Lego sensor. Looks interesting though.

That challenges page looks good. Thanks for pointing me towards it.