PDA

View Full Version : New Mech: Nostromo



webgeek
12-19-2009, 01:02 PM
Hi all; I've been lurking here for a while and posted a few things but now that my project is seriously underway I figured I'd create a build thread for it. I'll just update this thread as I go with new posts per day of progress. One request - I know I'm not doing some of this the ways others have done it. Please refrain from beating me up too much because I'm not conforming to the traditional approach. If I fail then this will serve as a good object lesson. It's my failure to make after all, not some grumpy person who doesn't like people trying things out of the norm. Basically, nay-saying would be bad though constructive criticism and feedback would be greatly appreciated.

Overview
I'm making a custom chassis'd quadruped mech with dual airsoft guns. The mech will be used in three competitions at RoboGames: Defcon, Mech Warfare (Airsoft), and Mech Warfare (Hardcore). It needs to be working in some form by March 6th as I want to take it to the "Central Illinois Robotics Bot Brawl" to get a feel for how these competitions go and see how it works against other mechs and what to improve before RoboGames. This imposes a 24" height limit otherwise I can't use their portable arena. Seems a good restriction either way.

General Design Concept
In some ways my mech is very different than the norm and in others it's quite basic and traditional. From the beginning, I've been reading about how weight is always a concern in mechs and that most of them really have trouble holding up the needed equipment so everyone has to go with ultra-light guns or super expensive servos or a combination of each. Because of that, I've decided to not use servos at all. I'll be using a couple of different types of stepper motors and totally custom mechanical linkage for them. Think linear actuators and gearing with limit switches. The overall design is such that weight won't be as much of a concern. This gives me freedom on guns and batteries I wouldn't have otherwise. Overall I'm focusing on stability of the shooting platform, accuracy of the guns, and rate of fire.

Walking
I've no way to catch up with all of you gait/IK experts and I'm not going to spend the money to buy super expensive servos so I'm not even going to try. My mech will be quite a bit slower than most of the mechs in the competition. I'm using two DOF legs; vertical and forward/backward. I'll use the creeping gait that you see sometimes so three legs are always on the ground and the COG is between them. I'd like to use IK but I don't think I'll get it working effectively in time, we'll see. The legs themselves are locked in a 90 degree angle to the floor and to the body. The feet will lift up vertically using the actuators. The current design has the legs being fairly long so the movement speed shouldn't be too bad.

Brains and Communication
I've got an Axon II that came in the mail yesterday and I'm already playing with it. This will be the on board brains of the robot. I'll be using the ubiquitous XBee system to handle communication with the mech from my laptop. The Axon II looks great with it's huge number of inputs/outputs and 4 UARTs, etc. Seems like it should work great for this project as I need two outputs per stepper motor. I plan on it really just controlling hardware based on commands sent from the computer so it won't be doing a lot of heavy lifting or logic. I'd rather use a true on board computer but I'm trying to keep the electronics (my weakest area) simple to avoid problems.

Camera and Vision
I'm going to go with what the consensus says works: the Trendnet wireless camera. This seems easy enough. The camera will be mounted dead center of the mech on the same turret mechanism that houses the guns and rockets. I'm going to be doing a bit with fiduciaries and CV if I have time so the bot can track the target panels on it's own but this is secondary and might not make the cut.

Turret
Since I'm going for slow and steady in the walking, I expect to be competing against other mechs that are faster than mine. I've watched every video of every mech I can find to understand as much as possible of the challenges in this competition. To that end, my turret has a few requirements that my design has to meet.

~400 degree horizontal rotation (azimuth?) since my mech will turn very slowly
~110 degree vertical rotation (elevation) so I can shoot at my mech's feet and hit taller mechs
Fast and repeatable rotation. I need to be able to quickly move to a specific spot consistently
Stable and recoil free. Between guns, rockets, and camera, the turret will have a bit of weight on it. Additionally, it's critical the recoil doesn't cause the camera to jitter all over the place. Rather than trying to come up with a recoil dampener, I'm just going to make the turret steady as a rock and hard mount everything. This won't eliminate recoil, but it will minimize it. It helps that I use aluminum for everything and I can custom machine 3d parts as needed with my CNC mill.


Guns and Rockets
This is where I take a radical departure from the norm. I'm not using tank guns or cheap plastic airsoft guns. I'm using two metal gearbox automatic electric pistols and running them at 12v. The guns are mounted to the sides of the turret with the rockets in the same assembly. The camera is in the center of the turret. At 12v, each of the guns is firing about 15 rounds per second, maybe a touch more, it's hard to tell. So the total rate of fire is 30 rounds per second between the pair. I've turned down the velocity of the BBs a bit so they won't be dangerous - they should be right around 200 FPS, pretty mild for airsoft. Before anyone says so, I know you can only score 1 hit per second but as best I can tell most of the hits were more luck than accuracy or consistency in last years competition. I feel that focusing on the weapons portion of a mech rather than the movement is still fully valid within the rules and a legitimate approach to the competition, both in spirit and in practice.

It's not really effective for gravity feed to push this many rounds so I'm using a motorized tube feed system invented by a guy that makes airsoft machine guns and needed to support the equivalent of a belt feed ammo drive. It's a pretty simple design and I've got it working already. This lets me haul a few thousand rounds of ammunition on the mech. The ammo can be stored anywhere on the mech as the feed system is capable of pushing it several feet up and around corners, etc. I've not quite figured out where I want it to go. Each gun is fed independently but I think I'll use a single hopper with two feeders in it.

The rockets themselves will likely have the same mechanism used for firing at last years competition by Squidword. It's a solid design that I really liked. I don't have their physical layout designed yet so I'm not sure the number of rockets on the mech. I'd like to get fins and such on em but I can't quite come up with a design I like that looks good.

Control System
The mech will be remotely controlled from my laptop. I will have custom Java or C# software on the computer to handle actual display of the video feed as well as the actual control of the bot. I expect I'll use a more "video game" control approach than I've seen others use. Something like WSAD keys for moving the mech - forward/backward, rotate left/right. Then I'll use a "drift towards target" type of targeting system you used to see in the old space fighter sim games - Privateer for instance. Basically you move the target hairs on the screen where you want to go and the system moves the guns/camera towards them - basically the system and you are always correcting towards the target. It's both intuitive and quite effective.

Since the turret has such huge range, there are a few tricks I'll need to add to the software - like reversing and rotating around the other direction once it's limit is reached and detected via limit switch. I also want the UI to show the mechs orientation in relation to the turret and have some feedback loops on things like it it's firing, taking damage (and from what side), etc. Since I'm a video game programmer by profession, I'm looking forward to making a cool control system if time permits and all the mechanics work.

Summary
Whew, long post but I'm kinda proud of the work and research I've done so I like to talk about it. Sorry about that. In short, Nostromo will be ugly, slow, ungainly, and capable of raining a hail of BBs down on it's target fast and consistently.

Have fun!

-Mike

webgeek
12-19-2009, 01:08 PM
December 19th, 2009 Status
As of today, I've recieved the vast majority of the initial set of parts and will start working in CAD in earnest. I'll have at least a couple CAD diagrams and photographs to post sometime today.

Design - the design is significantly done on paper. Most of the major components are at least partially fleshed out with the complex areas complete. Starting today I'm going to be creating CAD models for all the components like the camera and the axon so I can really get the design down with scale. At first I thought the bot would be big, but most of the components are pretty small so I think it's going to be a little bit smaller than I expected. That makes it much easier for me to mill parts for it - less fixture creation needed.

Brains - My Axon II is on my desk and I started playing with it last night. Looks pretty solid and a very nice piece of electronics kit. AVRStudio gave me a headache compiling because it's still not really Vista 64bit compatible. The problem was in WinAVR specifically but I got it sorted out in the end. Now I just need to learn the API ins and outs. Fortunately programming is programming and once you know enough languages it's pretty easy to pick up new ones.

Steppers - I've a huge pile of salvaged stepper motors from three printers and one scanner in front of me. I also have two specific motors from Jameco as well. I don't plan on mixing/matching motors for a given task (all vertical leg motors will be the same, all hip the same, etc) but I'm using the pile to come up with what will work best for each use without buying a mess of motors. I also have two very nice EasyDriver stepper boards here as well. I'll be using them to control all the motor goodness.

Ammo Drive - I have all but a single component for the ammo drives here and I've already modified the servos and magazines to do what's needed.

Guns - I have both of my airsoft guns stripped down so I can run them without any internal electronics. I've already removed all unnecessary mechanics like the trigger assembly and such. Test firing those buggers off some car batteries was fun. They are surprisingly loud when you expose the guts. Building the replacement frame is going to be one of the harder parts of the whole project as they are using tiny pins to hold everything in position and I don't know how to measure it accurately enough. I expect I'll use the DRO to jog into position, note it, jog to the next position, note it and then see how it goes in a few test pieces of wood. I prototype everything in 2x4's on the mill because it's so cheap and cuts reasonably well for rough stuff.

Anyways, back to work for me!

-Mike

Adrenalynn
12-19-2009, 01:17 PM
Sounds fantastic!

darkback2
12-19-2009, 02:40 PM
You don't know how much I love all of these scratch built bots! I can't wait to see it all come together.

I'm also really impressed with the fact that you are using salvaged stepper motors. you only need 2 outputs to control them? I can't wait to see you moving them around. I think a lot of us could benefit from what you learn. Controlling stepper motors with an axon...would be cool. Be sure to post a tutorial on how to do it once you have it all locked down.

One thing about a high firing rate...With the cheep plastic guns, they tend to swing around all over the place after the first shot which creates a wall of BBs that can be near impossible to get around. If you have a relatively mobile turret, then you may be able to gain a good position and pin down the other bots. Here is where two on two matches will be fun. :)

Again, keep us all in the loop, and post pics and videos of your progress.

DB

Adrenalynn
12-19-2009, 02:56 PM
Mount-up a couple of these bad boys: http://www.airsoftgi.com/product_info.php?products_id=4514 and the 'bot would be a guaranteed winner!

Adam
12-19-2009, 05:05 PM
This sounds like a really cool project. You're making me think of all the old printers I tossed in the garbage over the years...



It's not really effective for gravity feed to push this many rounds so I'm using a motorized tube feed system invented by a guy that makes airsoft machine guns and needed to support the equivalent of a belt feed ammo drive.


Do you have any links to this information?

Adrenalynn
12-19-2009, 05:18 PM
The steppers in an average dot matrix or ink-jet tend to be MD2s. They're good for just over 40oz-in of torque.

societyofrobots
12-19-2009, 10:41 PM
I'm going to be creating CAD models for all the components like the camera and the axon
Which CAD software are you using? Send over the final design and I'll post it up for others to download.

Adrenalynn
12-19-2009, 11:30 PM
Or he could just post it here. Over in the Datacenter section... (http://forums.trossenrobotics.com/datacenter/)

societyofrobots
12-19-2009, 11:34 PM
Well, as long as I'm aware of it so I can link it directly to the Axon II site.

webgeek
12-20-2009, 01:51 PM
Wow! Thanks for all of the kind words. Sorry I didn't get to posting anything last night because Dragon Age (superb game BTW) was calling my name and I ended up playing a long time. I'm working on this now though so I'll get a slew of things up there today. I'm posting a few photos right after this Let me see if I can address everything starting at the top...

I'm also really impressed with the fact that you are using salvaged stepper motors.Sorry I was unclear, I'm only using a few salvaged motors because I don't want to have different software settings for each piece of each leg. The turret motors will likely be from salvage. I've attached a pic of some of the stepper motors I snagged from tearing apart the three printers and scanner. Interestingly enough, older equipment had larger and more steppers. Newer equipment had cheap little motors with high end encoders and lots of gearing. I saved all that too :) I've attached a pic of my new steppers for testing too.

you only need 2 outputs to control them? I can't wait to see you moving them around. I think a lot of us could benefit from what you learn. Controlling stepper motors with an axon...would be cool. Be sure to post a tutorial on how to do it once you have it all locked down.Thanks, I think I'll do just that! Yes, using EasyDriver boards (pic attached) you can use two outputs to control a stepper motor. One controls the step pulses and the other controls the direction. Simple and easy. The boards are a steal at about 15 bucks a piece. They can't run large high-amp steppers but they can run small steppers are higher voltages (up to 30!) which works out nicely. They are chopper boards so quite capable overall. I would have bought mine from Trossen but they don't have the newest V4 boards so I snagged em at SparkFun. In the end, I'll be using 10(!!) of these boards on the bot. The creator has a page up on his site that covers the details on the board. You can see it here (http://www.schmalzhaus.com/EasyDriver/). You use two digital outs to control them. Additionally, the boards are quite small so I think you can pack them all into a tight space with a nice mount design.

Do you have any links to this information? Hmmm, I feel like I'm giving away my trade secrets now :) The link to see how he modifies a high-capacity M4 magazine for motor drive is available here (http://www.air-sharp.com/magmod.html) - he uses it on guns like this (http://www.air-sharp.com/mk93.htm) one. I've attached a picture that shows what I've done on it.

Which CAD software are you using? Send over the final design and I'll post it up for others to download. and
Or he could just post it here. Over in the Datacenter section...Ha, both of you vastly overestimate my pathetic attempt at CAD to be something anyone else would possibly want. My CAD drawings are only used for hole position and physical dimensions. I put everything in CAD to create the machine paths needed for my mill. Because of that, the electronic parts (Axon II and EasyDriver for instance) are simply blocks with accurate hole patterns and width/height/depth. I add no detail beyond that as there is no need for the sake of machining. It's in there so I can make sure all my parts and components work together nicely. Since my CNC mill is a bit small, I have to make lots of little components and CAD is the best way to get em all into one place to make sure they work. My drawings are rough to the point of embarrassing. To answer your question though, I use EdgeCam Part Modeler because it works seamlessly with EdgeCam, the software I use to create my tool paths and such.

BTW: the link on the SOR site for the Axon II CAD file is a 404 currently :)

Thanks again for the interest. I've attached a photo of the Axon II just in case people are curious as well. Thanks!

Mike

webgeek
12-20-2009, 07:28 PM
Ok, this is the first of many promised CAD drawings. I'm so bad at CAD it's pathetic. It took me forever to design this silly little part but I'm pretty happy with it now that it's done.

So the need to have 10 EasyDriver boards on the bot is trickier than it seems. They don't have mounting holes AND they are prone to getting quite hot when driving steppers heavily. They also have a multitude of holes around the edges and though I don't expect to use them I don't want to cover them up. So the requirements are...

Very securely mount multiple EasyDrivers together in one place
Provide a reasonably effective heat sink for the boards
Don't cover any of the holes on the board
Don't cover the status LED on the board
Don't cover the current adjustment pot. on the board
Take as little space as possible


So with that list of requirements, I came up with the attached design. This would be milled from 6061 aluminum bar stock. The dimensions of the stock and the final part is 5.5" x 0.75" x 0.25" - it's pretty small. I've added a pair of 1/8" wide by 1/32" deep grooves on the top over the boards to try and get what minimal heat dissipation I can. There just isn't enough material to go nuts. Once I get one manufactured and try it out I'll know if I can go deeper or not. There should be clearance for all the wires all around so I think it's a workable solution.

I've attached an isometric shot as well as a top and side view. I've also attached a shot that fakes the Easy Drivers in there via some Photoshop trickery.

Have fun!

-Mike

webgeek
12-21-2009, 01:09 AM
Alright, after taking a CAD break with some TV time wasting I figured I'd give it another go. This time I started putting into CAD the design for the legs.

This is the design of the "horizontal leg plate." It will be made out of 1/8" 6061 aluminum. Each leg will have two of these and they will both be vertical with their bottom edge parallel to the floor and perpendicular to the closest chassis edge. The "hip joint" side will overlap the chassis of the robot a bit to attach it to the custom turn table I'm making. The stepper motor that controls picking up and putting down the foot sits in between these two plates and is attached to the motor mount by screws in it's face. Each of these plates will be 1.5" apart as this will hold several designs of stepper motors nicely. This lets me use the same leg design and just swap out motor mounts.

The motor connects to a shaft that is parallel to the floor until it reaches the vertical leg plate mount where it will enter a u-joint to change the angle of rotation to 45 degrees. The shaft then continues to the labeled "u-joint mount" where it will encounter another u-joint to rotate the angle another 45 degrees. This final shaft will mate up to my linear actuator/lead screw system to move the foot up and down. The end result is that a motor whose weight is fully supported by the chassis will be controlling the vertical movement of the foot. Of course both u-joints will be supported by ball bearings to keep friction down. I think it should work out pretty well.

Anyways, I've attached two pics for anyone interested to see. Tomorrow, I'll try and get some more modeling done for the vertical leg plate - it's likely a bit trickier. Thanks!

-Mike

webgeek
12-21-2009, 04:16 PM
Minor update: I posted my EasyDriver mount design on another forum looking for feedback from EasyDriver users and the creator of EasyDriver gave me some excellent suggestions that I've incorporated into revision 2. I've also added some other things to make it easier to work with.
Added another 1/4" thick back plate to support the back of the boards under the chip and provide a good deal more cooling
Added a groove in the underside of the top board to "position" the chip correctly and line it up over the back mount
Added a larger center hole inbetween the other two holes for mounting to a surface. In the top board, this center hole is large enough to let the head of the socket screw to pass through. This lets you secure the bottom bracket to your bot while the top bracket and boards are seperately removable. This should make it a lot easier to use in general
Counter sunk the heads of the socket screws below the surface of the top bracket - this just improves the look a bit and makes for a flush mount
Adjusted tollerances a bit to make it easier to mount the boards
Added another thin channel to increase surface area - once I've made this board to validate the design, I'd like to make those channels deeper but I need to see how flimsy it is first


I've attached an isometric picture of the back plate and a zoomed in picture of the updated top plate. Have fun!

-Mike

Adam
12-21-2009, 04:52 PM
Looking good. I think it's safe to say this bot will be one-of-a-kind. :)

webgeek
12-22-2009, 12:51 AM
I'm finally starting to get a little more competent at CAD. It's really helping me see where the weaknesses in my design lie. Specifically when I try to fit it all together, I start finding areas where I've not thought things through enough and need to add more structure. I also find areas where the parts are too thick or thin, etc.

This evening, I focused on the rather tricky hip-joint assemblies. This joint is the key to the entire system as it has to require a trivial amount of force to rotate and yet still hold up the weight of the robot. Additionally, it needs to provide easy mounting points for the leg mechanism and motors.

To that end, I designed the hip joint to be completely integral to the frame. The joint is made up of a bottom bracket and a top bracket that both have a circular groove cut into their face. The groove will contain .175" diameter BBs to provide a very low friction movement. The chassis itself has matching groves on both the top and bottom as well. These BBs are the key, they will take all the weight while providing a lot of stability in the joint. The circular tracks are 1.85" in diameter so the joint has a lot of track to spread out the load.

The bottom bracket is all one piece of metal with a squared off "axle" that goes through the frame and into a squared off hole on the top bracket. The idea behind this is to prevent any possible rotation between the two parts. This means I can use less fasteners to hold the top and bottom together as they can't "spin" - they can only separate vertically which is against the strongest force a screw can exert. Ultimately, this didn't stop me from going nuts on fasteners anyways though. Overbuilding more strength than needed is a serious flaw in most everything I designs.

Sadly, now that I've got it all together, I don't like the look of the leg. It's only 4" long and 2" of it is over the robot to support the motor. I'm going to up it to 6" tomorrow and see how it looks. Fortunately, I think I have the CAD file correctly set up so changing a part fixes all versions of it used in the model. Ultimately, it seems to be working OK with the way I have it now.

Overall, the design looks bulkier than it is. For instance, the leg mount block is 1/4" x 2" x 2" - it looks huge in the drawing but basically everything is small. Once I get the leg set up longer, I think it will look better overall. Next step is figuring out how I want to mount the motor and limit switches to handle this joint. I'm thinking chain drive and I just cut the bottom bracket to include sprocket teeth for #25 chain - nice and clean. Plus it looks mean :)

Have fun!

-Mike

societyofrobots
12-25-2009, 03:00 AM
BTW: the link on the SOR site for the Axon II CAD file is a 404 currently
hmmm thanks for catching that. My host accidentally locked me out of my site, but as soon as I get that fixed I'll correct the 404. Try again in a few days.

You should be able to simply drag and drop any AutoDesk Inventor .ipt file directly into EdgeCam, assuming the versions are matching. I use EdgeCam myself, and usually open source all files for it for my bots.

webgeek
12-25-2009, 09:11 AM
You should be able to simply drag and drop any AutoDesk Inventor .ipt file directly into EdgeCam, assuming the versions are matching Yup, I'm using Part Modeler for the actual CAD work and I've pulled in a few different CAD files for things like servos and the like. They've been created with a variety of CAD programs and everything has loaded properly. Thanks!

-Mike

webgeek
12-25-2009, 10:19 PM
December 25th, 2009 Status
I've actually done quite a bit of work these last few days but not so much I can show with images.

I'll start with the design side, I re-worked the leg sides a bit to be longer and fit everything better. I've also created the motor mount which supports any NEMA 17 motor and properly interfaces with the other pieces. There are a lot of other smaller changes like recessing bolt heads and moving things around a bit but overall, it looks about the same. I've attached an updated image that shows the new sides and the motor mount.

I've also done a great deal of work on the electronics/software side of Nostromo. I've never worked with anything smarter than an Arduino and I've never really done too much even with them so I had a bit of a learning curve. Ultimately the vast majority of problems stem from using 64 bit Vista. The Axon II seems very capable and I like it thus far but there are a lot of tweaks and such needed to get it running properly with 64 bit Vista. I've had more compatibility issues with AVR/Axon stuff in the last two days than I've had in more than 2 years of using Vista daily. I believe everything is running smoothly now - I'm able to compile (first problem), upload code to the Axon II (second problem), talk it it via Putty, etc. Assuming my solution keeps working for another couple of weeks, I'll be writing up a little article/tutorial on what you need to do to get past the problems. It's only a couple of things but they are neither intuitive nor obvious based on error messages.

Today, after gift giving/opening with the wife and daughter, I played a bit with getting digital I/O and servos working with the Axon. It was pretty straightforward overall though the lack of documentation means I spent a lot of time digging through the source code of WebbotLib to see how to actually do stuff. There are a lot of examples, but no really basic ones that do things like turn on an LED when a button is pressed, etc. And since this is my first AVR, most of it was Greek to me so I had to piece it all together. Fortunately, it's all been logically designed and there just isn't that much code needed to do easy tasks so I got past it all pretty easily.

Coding in C has been interesting as well - I've got a ton of programming experience in a variety of languages but I've never really done much in C and the lack of true object orientation makes my program "feel" very sloppy to me though I've done my best to keep things organized and documented. Guess that's just going to be the nature of the beast. I'm probably going to start poring through other robot's code to see how it's handled elsewhere and learn the tricks people use. I've created a struct to handle all aspects of each of my steppers (a direction pin, step pin, limit switch pin, step counter, etc) as well as some of the supporting utility code. I figure I'll have my custom little EasyDriver code wired up tomorrow without too much trouble.

As it stands, I've got the EasyDriver board electronics working great with the Axon II. I ended up using my larger stepper to see how it goes and I was more than a little surprised at how "torque-y" it is. Almost impossible to stop by hand at middle speeds. The stepper is a bit big for the EasyDriver when using microstepping but turning that off is a fine option for me and that gives me more speed. I'm still debating the voltage of my bot but if I can get to 24v, these steppers will be monsters - both reasonably fast and very strong. Plus, the steppers cost $9 and the EasyDriver is only $14. Fine-grained control with lots of torque for $23 is a real bargain.

Anyways, lots of progress. This long weekend will give me some time to actually fire up the mill if I get a chance - I'll post pics if that's the case. Thanks!

-Mike

JonHylands
12-26-2009, 07:36 AM
Just curious - what languages are you comfortable in? I personally can sort of do C, but I'm much more comfortable in Smalltalk, which is why Roz (my bioloid quad) is getting a gumstix overo...

- Jon

webgeek
12-26-2009, 09:12 AM
Just curious - what languages are you comfortable in?I'm most comfortable in Java as I use that on a daily basis to write back-end server software for video games. I specialize in high concurrency networked systems and the like - the software my company sells runs a lot of multiplayer games where 10,000+ people are all playing a game together on a single server. Lots of kids virtual worlds and such use it like WebKinz, Neopets, Action All Stars, Meez, etc.

Sadly, this doesn't translate to robots well at all as we don't have threads, annotations, inheritance, objects or any other constructs and concepts I'd normally use. I also do a fair bit of C# (actually did some programming on Microsoft's web site years ago), ActionScript 3, JavaScript, various shell scripting, Python, and a handful other scripting languages. I'm not counting any of the pseudo-languages like SQL, XSLT, etc. in the list. Ultimately, I'm not worried about coding either the robot or the control software, just need to get some more C under my belt which I plan on doing today.

Thanks!

-Mike

Adrenalynn
12-26-2009, 12:32 PM
>> this doesn't translate to robots well at all as we don't have threads, annotations, inheritance, objects or any other constructs and concepts I'd normally use

We don't? I didn't get that memo...

webgeek
12-26-2009, 01:21 PM
We don't? I didn't get that memo... Obviously I should have been more specific - other languages and other microcontrollers/computers have different options. The Axon II and it's associated libraries don't appear to support threading, annotations, generics, inheritence, etc. I'd love to be proven wrong on this though so if anyone has some information please do send it along. As it is, I'm using hardware interrupts to handle my limit switches, structs in place of true OO, etc. It will work fine in the end, just a bit of a departure from my comfort zone. The computer side of my control software will be either Java or C# and of course I'll be back to using the constructs I listed.

-Mike

Adrenalynn
12-26-2009, 01:31 PM
You get classes, single inheritance, and virtual functions in AVR-GNU C++. They come at the cost of ~20% increase in code size, ~50% increase in data size, and 10-20% performance hit.

webgeek
12-26-2009, 01:34 PM
Classes would really help me out in cleaning up the code, I can take both the performance and file size hit to get access to those. Time to do some research to see what I can get away with - thanks!

Mike

Adrenalynn
12-26-2009, 01:43 PM
That concept is entirely alien to me in my embedded programming experience, so I can't be of much help other than to tell you that it exists. In my world, we optimize for bits and microseconds - taking 10-50% hits for the sake of _anything_ is a one-way ticket to unemployment. Embedded programming really is different than PC programming.

webgeek
12-26-2009, 01:45 PM
I can certainly understand that - fortunately, this project needs very little processing power overall so I hope I can get away with it. If not, I guess I'll re-write it to be more streamlined after I've got it working :)

Thanks for the help!

-Mike

Adrenalynn
12-26-2009, 01:47 PM
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus

That pretty well breaks it down. I should have given the standard "No 'new or delete'" disclaimer - I usually do when this comes up...

lnxfergy
12-26-2009, 02:57 PM
Most of the Arduino core is written as C, wrapped inside C++ classes. Most of the Arduino libraries are C++ classes (some are C functions wrapped inside a class).

As for "threads", in hardware, we can do you one better with hardware interrupts. Newer AVRs typically have 2-3 pins with dedicated hardware interrupt vectors and can do interrupts on every pin using the "pin change interrupts" (but 8 pins share an interrupt vector).

-Fergs

webgeek
12-26-2009, 03:08 PM
I started using interrupts to handle my limit switches initially but it proved to be unnecessary as I continued coding the system. As it stands, I think I'll just finish the system with my current code and see how it goes. The goal for today is to get a solid handle on running multiple steppers together in conjunction with limit switches. It doesn''t make for anything pretty to see, but it will save me a ton of work when I start working on gaits and the like.

-Mike

JonHylands
12-26-2009, 03:11 PM
That concept is entirely alien to me in my embedded programming experience, so I can't be of much help other than to tell you that it exists. In my world, we optimize for bits and microseconds - taking 10-50% hits for the sake of _anything_ is a one-way ticket to unemployment. Embedded programming really is different than PC programming.

Sure, but Jodie, you have to remember - you're doing embedded development that pushes the hardware to its limits, and you're doing it for a job. The faster your code runs, the more data you can process, and thus the more money you can make.

In the hobby robotics work, none of that matters, at least not with what most of us are doing. Modern microcontrollers are grossly over-powered for what most of us do, and if we run into trouble, we either get a faster one, or use more than one.

As I said before, I like to program in Smalltalk. Squeak runs 5-10x slower than C on a given platform, but jumping from a 16 MHz AVR to a 600 MHz gumstix gives me almost a 40x improvement. Figure in that the gumstix processor is 32 bits, and you possibly get another doubling of that again, so losing 5 or 10x to language inefficiencies is a sacrifice I'm willing to make in order to gain the enormous advantages I get from programming in a language like Smalltalk.

- Jon

Adrenalynn
12-26-2009, 03:29 PM
Jon, your post almost made my head explode...

It's got nothing to do with how fast it can process data equating to money.

But that said and addressing only the hobby: If you're trying to count steps on a high resolution encoder, microseconds MATTER. Whether pro or hobby, if it's the difference between your 'bot jumping off a cliff or driving a straight line, you're going to want those microseconds.

Your third paragraph, in all due respect, is[edit]n't much of an argument. You run 10x slower, so you throw 40x the processing power at it. Great. What happens when that's not enough? Where's the 6Ghz gumstix when you need it? If you ran 10x faster, that 600Mhz Gumstix would look like a 6Ghz Gumstix. And that 16Mhz AVR would look like a 160Mhz AVR (presuming you could even run smalltalk on it...)

And what do you get for all that waste? A non-standard language that isn't maintainable by [or even useful to] more than a teeny handful of people. Really - what does it buy you other than elitism?

JonHylands
12-26-2009, 04:17 PM
Yeah, sure, if you're trying to count steps on a high resolution encoder, you can hand-code assembler for it, count instructions, etc. Or, you can do what I did, and pay $6 for a chip that does it in hardware, and interface to that chip over a simple SPI interface. BrainBot's encoders run about 9000 counts per inch of robot movement, per side, and they are quadrature encoders. I spent a couple hours doing a software solution that didn't work very well, decided it wasn't worth the amount of time it would take to optimize it to where it was useful, so I chose a solution that worked with the least amount of hassle. If I was building BrainBot to sell 100,000 of them, I might choose differently, but I'm not.

Programming in Smalltalk buys me the ability to do things that I can't do otherwise.

Maybe you can write backtracking graph walkers in a couple hours off the top of your head in five different languages - I can't. I've done it in Smalltalk, though.

- Jon

Adrenalynn
12-26-2009, 05:05 PM
I try not to blame a hammer for driving a nail in crooked. It's tempting, but it doesn't get the nail driven in straight...

>> I've done it in Smalltalk, though.

On a PIC? AVR? SAM7? MIPS?

Adrenalynn
12-26-2009, 05:57 PM
Ok - scratch the MIPS. Most of those will run a DOS

JonHylands
12-26-2009, 06:08 PM
No, of course not on a PIC/AVR.

My brother and I have been tossing around porting Squeak to run on an ARM7.

The backtracking graph walker was for a reinsurance company in the US where I was doing a contract - it ran on a regular PC, on a different dialect of Smalltalk.

Squeak runs on a huge variety of hardware platforms and operating systems. Because it uses an interpreter, I can take the memory snapshot of my code running on Windows on a PC, copy it to a micro-SD card, insert that into my gumstix overo (which runs linux on the equivalent of an ARM9), and start up Squeak there, picking up exactly where it was on my Windows machine. Each machine has its own VM, but you don't generally make changes to that.

Anyways, I think we've hijacked this thread enough - if you want to debate how worthless you think Smalltalk is, we can do it somewhere else...

- Jon

Adrenalynn
12-26-2009, 06:12 PM
>> No, of course not on a PIC/AVR.
>> Anyways, I think we've hijacked this thread enough

'Nuff Said.

webgeek
12-26-2009, 09:49 PM
December 26th, 2009 Status
I was lazy today but did do some coding in front of the TV and got some work done. I've got the entire stepper motor movement basics down now with the most important part working - the accurate homing and movement of the joints/motors. Basically, you define a "joint" as a series of two outputs (for motor control) and one input (for limit switch). You say how many pulses per rotation, if the limit switch is in the clockwise or counter clockwise direction and if a high on the direction output causes clockwise or counter clockwise movement. Finally, you tell it the maximum speed at which pulses can be sent to this motor and the maximum number of steps it can move away from the home position. Whew... Lots of configuration!

The homing process works like this: when the robot is turned on and a joint is registered, it will move the joint to the "home" position until the switch is just triggered and then back it off one step. If the switch is already triggered when the robot is on, it will move away from the switch until it's just turned off. Once it hits that "home" position, it sets that joint as homed and resets the step counter to 0. This lets me avoid the messy logic and mechanics of having a limit switch at both sides of the movement range.

From this point on, all movement is handled by simply updating the struct via some logical methods to tell it what position to go to. The system automatically handles forward and backwards, etc. So if it's at position 10 and I tell it to go to 100, it will send 90 pulses at the set speed to get it to 100. I also support saying how many rotations you want. So you can tell it to turn one rotation and with these motors without microstepping, that's 400 pulses. This is all handled via the main loop of the robot. Every pass through the loop it checks to see if any steppers are not at their designated position and moves them one step in that direction - either forward or backward.

Currently, I have a delay in the main loop itself, but I'll make it work more like video game rendering loops tomorrow. The loop runs as fast as it can and you do a time check to see if motors need updating each pass. This lets you get very precise updates and really control behaviors. We use this technique to do things like update physics simulations far more frequently than the frame rate. Likewise, this let's me update sensors and logic at totally different rates than I update the steppers. Everything just has a "I need to do work at this time" field and when current time is >= this time, we do the work. This likely won't work for super precise timings but I don't have anything that needs that type of precision so I'm going to see how this holds up.

All of this is the lowest level of my control of steppers. Likely, I'll add an additional layer to hide the whole pulses and rotation thing and make it a true distance from the home position in either inches or degrees once I have the mechanics built and can calculate it accurately.

Anyways, sorry for the long explanation but I thought it might be of interest to any of you that might use steppers vs. the ubiquitous servos in the future. This seems to be one of the bigger hurdles to overcome when using steppers so I thought the details might help. Have fun!

-Mike

Adrenalynn
12-26-2009, 11:43 PM
>> This seems to be one of the bigger hurdles to overcome

I think torque will be a much larger hurdle. Do you have the specs on those steppers?

jes1510
12-27-2009, 12:02 AM
One more thing about steppers, You don't get the feedback that you would get with a servo. If you pulse the stepper to move X steps without any feedback then you have to assume that the stepper got there and everything went ok. The software may think things are going great when really your bot is flailing on it's back. Do you have encoders or anything providing feeback? If not then how do you plan to deal with the inevitable slippage?

webgeek
12-27-2009, 10:05 AM
I think torque will be a much larger hurdle. Do you have the specs on those steppers?No doubt my bot will have far less torque than the super expensive servos people are using currently. With my NEMA 17 stepper I'm testing at the expected 24 volts, I should be getting right around 90-100 oz/in prior to any gearing and such. I don't have an exact number as the stepper driver I have can't drive it at as much amperage as it wants, so I've had to guess how much to back off the torque - I think I've been nice and conservative. The motor is rated at about 180 oz/in at 24v and 1.3 amps and I'm running it at 24v and 0.8 amps.

The trick though is that my design goes out of it's way to limit the need for torque. Every aspect of the design takes into account low torque motors across the board. It's for this reason that I think it's enough. The one part of the bot that's doing the most mechanical lifting work (the foot moving up and down) is also the one with the strongest gear ratio - basically a screw-drive. Due to the nature of that joint it can't run backwards without the motors assistance so I don't even need to hold the stepper on once it's reached it's required position. The hip joints, due to running on a large-ish diameter turn table should have very little friction and resistance to movement even with a heavy bot.

Ultimately, if it doesn't have enough torque, I'll just go back to the drawing board and fix the problem with a new design. Now that I'm getting everything into CAD, it's pretty easy to make even radical changes and machine them out quickly. If my design is totally flawed than this can serve as an object lesson for others and I'll learn a bit in the process. If this design works, it might get people thinking of other ways to make complex robots than the use of expensive steppers.


One more thing about steppers, You don't get the feedback that you would get with a servo. If you pulse the stepper to move X steps without any feedback then you have to assume that the stepper got there and everything went ok. The software may think things are going great when really your bot is flailing on it's back. All true.

Do you have encoders or anything providing feeback? If not then how do you plan to deal with the inevitable slippage? This is where I start to disagree a bit. I don't have anything beyond the home switch to determine exact position but I do not believe slippage (I assume you mean lost steps here) is inevitable. CNC machines, particular the smaller ones, use steppers all the time and don't run into lost steps after even many tens of thousands of steps milling through hard materials. On my own CNC machine, I've run very long programs that have taken literally an hour plus to machine out of wood or aluminum and not lost even a single step in the process. It returns exactly to where it started when the program is done. The trick is simply not trying to drive too fast and making sure you use correct sized motors and power supply for the task at hand. It also helps that a single movement is many hundreds of steps - losing a single step here and there will be a minimal problem for a long time. It will take quite a while to add up. I also have hard stops planned in the design to prevent it from overrunning a location, so no catastrophic failures. Worst case scenario is that I'll simply require the gait to include touching off on the home switch periodically to reset coordinates or I'll create a second switch per stepper and it will be the "limit switch" to handle max extent of travel in a direction and force a coordinate reset when reached though I honestly don't think either of those will be necessary.

I know the use of steppers is the most controversial part of my design but it's also how I plan on building the project for a minimal amount of money. All of my motors and drivers come to a grand total of about ~$220 if I use all NEMA 17 steppers and EasyDriver boards (10 of each). It'd be even less if I made my own EasyDrivers but I'm too cheap and not good enough at SMT. The Axon II was $120, the aluminum will be less than $50, the guns were $15 each (normally $60 but I bought broken ones ;)). All told, I should come out around $650-$750 for everything (Assuming TrendNet camera). I plan on really nailing the "free day" at SparkFun too so that will likely save another hundred bucks there. It's certainly a risk, but one I'm willing to take to see how it goes. Thanks!

-Mike

JonHylands
12-27-2009, 10:23 AM
Mike, I think your ideas are very interesting. I've got plans to build a biped using linear actuators (actually series elastic actuators), and stepper motors may be a part of that, depending on the speed/torque curves I can come up with. For me, hobby servos are an easy in-between for now.

- Jon

darkback2
12-27-2009, 12:18 PM
Hey Mike,

I think some times we get hooked in conventional wisdom, and the idea that some things are just necessary in order to make things work. Until we are proven wrong. I too have often wondered if you could use stepper motors instead of servos, and plan on it with a robotic arm that has been floating around in my head...

Also, You may want to look at the cheap metal gear servos. They are sloppy and tend to overheat when over stressed for too long, but charlie used them, and squidword still has four of them in his legs...at $10-$20 a piece, they can cut the cost of a big project down, and allow you to "grow your bot over time.

Can't wait to see this bot in action.

DB

Adrenalynn
12-27-2009, 01:24 PM
>> I think some times we get hooked in conventional wisdom

I agree. Some of us do believe that we are bound by the laws of physics, help or hindrance.

webgeek
12-27-2009, 10:13 PM
December 27th, 2009 Status
Didn't get too much done today as I was enjoying my last day of Christmas break relaxing. I spent part a few minutes modeling the vertical leg plate for my mech. I've attached a render of it to this post. The design isn't yet clear from this image though it will be once I get some more parts in there. The key to the design is a pair of RC u-joints to change the angle of motion from horizontal to vertical. This new part serves as a way to attach a vertical rail on which the leg will move up and down. I'll likely get that all modeled out tomorrow.

I also spent some time working on the code. I've got the start of a pretty slick little menu system that I will be able to use to monitor the status of the mech as well as enable/disable various components like it's rockets or guns, etc. It also gives me control over homing the legs and such. It's not terribly sexy but seems to be coming together well and is teaching me more about coding in C.

Tomorrow, I also hope to get some time to put my mill back together - I won't have anything to show but it will be super helpful in general. Have fun!

-Mike

Adrenalynn
12-28-2009, 02:40 PM
>> than the super expensive servos people are using currently.

Just as an aside - would you stop trying to sell this bill of goods? An equivalent torque servo running on just 6v (less expensive/lighter batteries) that is substantially faster, has a standard PWM interface, AND has absolute position feedback is... drum-roll please... The same price, give or take a dollar or two.

I'm sure you just weren't aware, but there's the bottom line...

webgeek
12-28-2009, 03:00 PM
You are totally correct, my mistake. Though I believe you can get equivalent servos for even less than what I'm paying - for instance:
http://hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct=8776&Product_Name=BMS-620MG_High_Torque_Servo_(Metal_Gear)_9.1kg_/_.15sec_/_50g

I should be more specific though - it's the design, not the motors, that allow for the cheaper components to carry more weight. By not having the joint of a leg being supported by the holding torque of the servo as has been traditionally done, you don't need to have beefy servos to carry more weight. So when I'm talking about thousands of dollars in servos, I'm talking about the mech design as a whole vs. steppers vs. servos directly. I've been very unclear about that in my previous posts - sorry!

-Mike

JonHylands
12-28-2009, 03:06 PM
Actually, that's true only if you don't gear the output of the stepper motor. That servo probably has 200:1 gearing. If you put 20:1 gearing on the stepper, suddenly you've got a 2000 oz-in actuator. Of course, you'll lose speed that way, but like everything else in life, you trade speed for torque. A typical NEMA-17 stepper can do 3000 RPM (50 revs/second), so with 10:1 gearing, you've got a 1000 oz-in actuator that can turn 60 degrees in 1/30 of a second (3-6x faster than a typical hobby servo). You'll lose a little efficiency with the gear train, so maybe you'll end up with 750 oz-in of torque.

Its certainly not going to be as cheap as using something like an AX-12 in the end, but at the same time these types of actuators have advantages that can't be found in hobby servos.

- Jon

Adrenalynn
12-28-2009, 03:28 PM
Mike, thanks for the clarification! I don't want the unwashed that surf through getting the wrong idea about servos. They exist for a reason and if they sucked as hard as they've sometimes been portrayed - they wouldn't dominate the market the way they do...

>> but at the same time these types of actuators have advantages that can't be found in hobby servos.

Totally agreed. Like no absolute position reporting, minimal holding torque, integrated slip, super high current requirements, super high voltage requirements, ...

I'm not saying it can't be done, it certainly can. I drove the lifter for the SciOly bot with an acme screw on a DC motor (1200 inch-pounds) from a $20 DC motor, a cheapie motor controller, a small chain drive, and a $15 screw. Of course it took almost six seconds to travel 8"...

I'm not out to discourage anyone from experimenting, I just believe that when you start adding up the costs, additional weight requirements, and eventual speed, then do an apples-to-apples comparison, I think you find you learned a bunch, had some fun in the machine shop, and got hosed for price/performance. Each technology has its sweet spot in its sweet space. The AX-12's own small walking bots for a reason... They've an awful lot of technology goodness in a $40 package. But if you want to go cheap, there are $15-20 servos that can get the job done.

>> 60 degrees in 1/30 of a second

Wear eye protection - or do the math on the screw before you do that under load. They get testy about that as I've well experienced. Flying carbon steel shards will leave a mark. TANSTAAFL

billyzelsnack
12-28-2009, 08:16 PM
If you put 20:1 gearing on the stepper, suddenly you've got a 2000 oz-in actuator.

From hanging out a bit on CNC forums I get the impression that steppers have good starting torque, but the torque falls off dramatically with RPM so I'm not sure gearing down works as well for steppers in practice.

webgeek
12-28-2009, 08:28 PM
I'm not out to discourage anyone from experimenting, I just believe that when you start adding up the costs, additional weight requirements, and eventual speed, then do an apples-to-apples comparison, I think you find you learned a bunch, had some fun in the machine shop, and got hosed for price/performance. Each technology has its sweet spot in its sweet space. The AX-12's own small walking bots for a reason... Ah, that's the trick - my whole reason for not using servos and going with a non-traditional design is so I can carry more weight and hence better guns and a heavy duty turret mechanism without breaking the bank on high holding torque servos. I'm sure there are as-of-yet undiscovered quadruped designs that can use servos to carry more weight without requiring more expensive servos but I don't know of them. Based on everything I've read, my guns would be far to heavy for the AX-12's to deal with in a traditional quadruped - let alone the magazine, batteries and everything else.


From hanging out a bit on CNC forums I get the impression that steppers have good starting torque, but the torque falls off dramatically with RPM so I'm not sure gearing down works as well for steppers in practice. The gearing down works, it's just you need to take into account RPM very carefully. You lose a lot of torque very quickly. You'll see a lot of the people using cheaper steppers gearing them down on CNC routers and the like. The metalworking machines don't generally gear down much - they just go bigger cause more torque is always useful. My little X2 uses 380 oz/in steppers for instance. On my mech, I will be gearing down but not sure how much yet. I'm also keeping the RPM slow and not using microstepping, quarter or even half steps.

Thanks!

-Mike

Artificer
12-28-2009, 08:33 PM
>> 60 degrees in 1/30 of a second

Coming from an industrial background that is actually pretty slow. That only works out to 5 RPS. The most common screw pitch is 5:1 so that works out to be 1” per second. A rule of thumb is 12” per second for an acme screw max and 24” per second max for a ball screw with that pitch.

If you want to see scary watch a linear servo going 2 meters per second or totally insane a pneumatic servo going 8 meters per second.

lnxfergy
12-28-2009, 08:46 PM
>> 60 degrees in 1/30 of a second

Coming from an industrial background that is actually pretty slow. That only works out to 5 RPM. The most common screw pitch is 5:1 so that works out to be 1” per second. A rule of thumb is 12” per second for an acme screw max and 24” per second max for a ball screw with that pitch.

If you want to see scary watch a linear servo going 2 meters per second or totally insane a pneumatic servo going 8 meters per second.

60 degrees in 1/30 of a second is actually 5 revolutions per SECOND, not minute, hence Adrenalynn's comments about "watch out for the shrapnel"

-Fergs

darkback2
12-28-2009, 08:50 PM
Ok...I know this has...well...OK...so Charlie, my first mech used cheaper servos. at first I used MG-995s, and ended up upgrading to hs 645 mgs...I used a levered leg design that allowed charlie to weigh in at just over 10 pounds using less expensive servos. I "borrowed the concept from the crust crawler hdat. I believe jess is using similar legs in his robot...Its just another way of saving money...it comes at the cost of mobility...but it worked.

JonHylands
12-28-2009, 09:03 PM
Well, CNC machines use major gearing typically - the leadscrew coming from the steppers on my Sherline is definitely a form of gearing...

- Jon

JonHylands
12-28-2009, 09:06 PM
Coming from an industrial background that is actually pretty slow. That only works out to 5 RPS. The most common screw pitch is 5:1 so that works out to be 1 per second. A rule of thumb is 12 per second for an acme screw max and 24 per second max for a ball screw with that pitch.

I'm not talking about driving a lead screw from that - I'm talking about driving a lever arm, in the same way a regular hobby servo does...

- Jon

Artificer
12-28-2009, 09:07 PM
60 degrees in 1/30 of a second is actually 5 revolutions per SECOND, not minute, hence Adrenalynn's comments about "watch out for the shrapnel"

-Fergs

It should have been RPS (I edited the post to correct the typo). It is still very slow. I've only seen vastly undersized screws break at that speed, typically the screw was too long.

The best shrapnel I've seen is a piece of tooling hitting its mechanical resonance at 50,000 RPM. It sang for a second then went away.

webgeek
12-28-2009, 11:02 PM
I used a levered leg design that allowed charlie to weigh in at just over 10 pounds using less expensive servosI'm pretty sure I know what you are talking about but do you have some detailed close up shots that show this? I'd love to see it!
Well, CNC machines use major gearing typically - the leadscrew coming from the steppers on my Sherline is definitely a form of gearing...True enough, but it's a single stage to translate rotational motion to linear motion. And with ballscrews (vs. ACME lead screws) it's actually not that much of a gear reduction - I was really surprised at how large the threads are on ballscrews.
The best shrapnel I've seen is a piece of tooling hitting its mechanical resonance at 50,000 RPM. It sang for a second then went away.Not quite as cool but in HS we did this with a glass beaker. I was shocked at how it really "bursts" apart once the resonance frequency is hit.

-Mike

webgeek
12-28-2009, 11:59 PM
December 28th, 2009 Status
Ok, got a bit more design done today while I had time. I've attached a picture of the latest design.

Basically, I've redesigned the end of the leg yet again to provide the vertical rods (1/4" diameter steel) on which the foot assembly will ride. I've also attached the first draft of the top and bottom "sled" that will ride on those rods to move the foot up and down. As the design stands, the system has 1" of vertical travel in the foot. Not much, but more than enough to get over cracks in the cement and BBs. The mechanism to hold the nut riding on the threaded rod in place against the sled is not done.

Another thing I've done is started enlarging the holes all over the place. I'll finish that up tomorrow. I was going to use 2-56 socket cap screws but after seeking some advice I'm going to switch to the far more common 4-40 screws instead as apparently I have plenty of material for strength already. This will save some money as the 4-40s are both common and cheap in bulk. I'm going to try hard to use only a couple of sizes for the entire project to make things easier for maintenance.

Speaking of holes, I have no idea what size threaded rod I'm going to use so a few of those holes are guesses until I get my u-joints in hand. I'm ordering them tomorrow. I'm also ordering all the parts needed to use +5v logic to control both of my guns without frying things. Ideally the parts will arrive this week so I can build them this weekend - we'll see :)

Have fun!

-Mike

darkback2
12-29-2009, 12:00 AM
http://forums.trossenrobotics.com/gallery/files/1/4/9/9/charlie-12.jpg
Here is the closest image I have that is already uploaded showing the levers in charlies legs

http://forums.trossenrobotics.com/gallery/showimage.php?i=751&c=3&userid=1499
This is charlie next to lexi...lexi is a hexcrawler hdat...I borrowed the idea from them.

http://forums.trossenrobotics.com/gallery/files/1/4/9/9/charlie-7.jpg
Here is the base part for the jointed leg.

billyzelsnack
12-29-2009, 05:01 PM
Well, CNC machines use major gearing typically - the leadscrew coming from the steppers on my Sherline is definitely a form of gearing...

That's a good point. I did a little looking and ran across this..

http://www.woodweb.com/knowledge_base/Servo_vs_stepper_motors.html

Specifically this I found interesting..



Stepper motors have a much higher holding torque and will remain in a fixed position until overpowered. DC servo motors, however, have a higher torque *during rotation* than steppers and a much higher RPM. To match a stepper motor's holding torque, you would need an expensive high torque servo motor. Deciding wether to use a servo motor or stepper motor is based on the needed holding torque (steppers) versus torque while in motion (servo). And don't forget that servo motors have a higher RPM.

Adrenalynn
12-29-2009, 06:54 PM
Servos have a higher RPM and lower holding torque? Someone needs to proofread. I'd need to see that from a reliable source with a plotter output in their hand from a certified lab...

Any time you throw gearing into the mix the holding torque automatically goes up. Steppers are direct-drive in general. Servos are indirect drive. Just the drag in the gear-train alone increases holding. Add to that that steppers have to be able to float free to microstep (measured when unpowered, of course), and it suggests the author is either mistaken or on crack. (just based on your quote)

The DC motor DRIVING the stepper is lower torque/higher RPM lower holding torque, certainly. But certainly the servo that any of us is likely to touch is geared.

Artificer
12-29-2009, 11:22 PM
The stepper / servo quote was poorly worded. I think the problem is the terminology used by the two different disciplines, i.e. CNC machining and robotics and what servo motor means to each. The servo motors used in robotics are a totally alien phenomena to people working with industrial motion control.

With regards to gearing either is just as likely to be geared on a CNC machine, typically both would be. Both would also have linear scales on each axis for positioning. Steppers are only used on lower end CNC machines, it doesn't matter if it is a micro stepping motor the finish still suffers from the steps.

webgeek
12-31-2009, 09:32 PM
Thanks darkback2, I really like the photos. Using the servos with levers to increase torque is a good idea and looks like it worked well. How did it perform in the end? I've seen a few shots of it but not heard any of your feedback on it overall. Thanks again!

December 31st, 2009 Status
Didn't get as much done these last few days as I wanted but I plan on really hitting it hard this weekend. The goal is to finish the entire mech design in the next few days and I think it should be doable.

I did get my relay parts to control the guns and I've already got them assembled and tested with some code on the Axon II. They are dead simple but also cheap and reliable - a tough combination to beat. They are rated for far more than I'll be pushing through them so I figure they will hold up well.

I also finished modeling a NEMA 17 motor (as accurately as I could based on the generic NEMA 17 specs) and a micro-switch. The switch in particular had to be super accurate because I need to be able to position them all over the mech and getting proper contact reliably is a big concern. I've attached a new render with a micro-switch in one possible location (don't really like it there but it does work) and the motor in it's mount. It was gratifying to see it all line up like I'd hoped.

Finally, I soldered proper headers to my pair of EasyDriver boards as well. I plan on doing a fair bit of testing with my second stepper motor to see if I like to more than the NEMA 17. The motor mount is entirely replaceable so switching it out to support other steppers is easy enough - just not sure if it's an issue yet or not. More testing will be required to know.

Have fun!

-Mike

webgeek
01-01-2010, 11:26 PM
January 1st, 2010 Update
Only 110 days till RoboGames and 79 days till the "Central Illinois Robotics Bot Brawl". Time to really start making some progress!

Sadly, today was not a great day for progress but I did spend a few minutes hooking up a gun to the relay and trying it on a small 12v SLA battery I had sitting around. I'm really surprised at how much faster the gun shoots than expected. It's getting something like 19-20 rounds off per second. I determined this by ripping the audio from the video and slowing it way down so I could count it. This means that my BB feed drive is more critical than ever. It also means I'm likely going to have to do some sort of "burst firing" in software because at 40 rounds per second being fired I'll run out of ammo no matter how large the hopper happens to be. Something like flickering the relay off and on every 100ms or such, not good for the relay but the part is cheap to replace if needed.

Anyways, enough chat about rate of fire - here is a low quality video showing it in action (sorry it's so poor, the tiny camera I use needs great lighting or the quality suffers badly - I'll do better next time):
YouTube- Single Airsoft Gun Controlled by Axon II and Relay

I also uploaded two CAD models to the Data Center - a microswitch and a NEMA 17 motor. Both are primitive but should be accurate. I also modeled the hacked high capacity magazine that's used to feed the guns. I had to model it as mounting it and the servos is actually going to be more than a little tricky and modeling it is the only way to make sure it fits.

Tomorrow I hope to be inspired - I'm going to attend our local robotics club's monthly event. I didn't even know we had a local club but apparently we do - we even have a place to meet at a local science museum, fun stuff. One of our members goes to RoboGames every year as well so I'm looking forward to talking to him.

Anyways, time for bed. Tomorrow I'll be doing a touch of testing with both guns running at the same time as well as getting the foot modeled. Then it's just the turret and related parts left! See ya!

-Mike

darkback2
01-01-2010, 11:40 PM
Wow that gun is fast!

Can't wait to see it all put together on your mech!

Again...wow.

DB

JonHylands
01-02-2010, 08:12 AM
Just out of curiosity, where are you located?

- Jon

Artificer
01-02-2010, 09:21 AM
I bought a couple of those same pistols. They are fast and pretty accurate but very heavy. I saw a video of it on You Tube and it was firing 10 rounds per second with the stock battery. If you can handle the weight you will have a great weapon for your mech.

webgeek
01-02-2010, 09:20 PM
Can't wait to see it all put together on your mech! Thanks - me neither, now if I can just get the dang design done.

Just out of curiosity, where are you located? Kansas City, Kansas. You near here?

They are fast and pretty accurate but very heavy. I saw a video of it on You Tube and it was firing 10 rounds per second with the stock battery. If you can handle the weight you will have a great weapon for your mech. Yeah, I got on an Airsoft forum and asked a ton of questions and the consensus that this gun was the ideal compromise of weight, reliability, accuracy and fire rate. The big advantage it has over guns in the same price range is the all metal gear box. That's where a bit of the weight comes from - the frame itself is quite heavy as well though. About half the weight or more of the gun is in the frame which I'm replacing with some aluminum. The all-metal construction is what's letting me run it with more voltage than it's designed for without any issues, it's also what makes it far more reliable for repeated shooting. Thanks!

Mike

JonHylands
01-02-2010, 09:50 PM
Kansas City, Kansas. You near here?

No, I live in SW Ontario (Canada). I lived in Kansas City back in 2000 for about 8 months though.

- Jon

webgeek
01-04-2010, 10:16 PM
January 4th, 2009 Update
Not as much progress as I'd like - as usual. It's hard to get a lot of design work in when I'm being lazy (and don't really like the CAD work much, necessary as it is). I did get the basics for the initial turret done. The "elevation" portion of the movement is solved and that's the attached image. I've decided to go with #25 chain and a 13 tooth sprocket on the motor with a 25 tooth sprocket on the shaft. This was simply the quickest and easiest way to control it and should work fine. Additionally, the sprockets are only a buck each surplus so I'll save the time by not making them.

The tacky gun looking things on the sides are placeholders for the actual gun brackets. I'm going to have to make those very carefully as there is no good way to measure the position of the pins and supports. Probably going to be a multi-step process to get them all fit together in the end. I'll just leave the placeholders in there for now.

I've also attached a model of one of the rocket motors, this will help out with my rocket pods I'm using for the "hardcore" class. Finally, you can see the ugly blue blob - that's my rough model of the trendnet camera to make sure it all fits ok on the turret.

Have fun!

-Mike

webgeek
01-08-2010, 12:05 AM
January 7th, 2010 Update
Typically less progress than I'd like. I plan on ramping up the work a bit this weekend if at all possible. I've been really busy with my real job this last week and that's really cramped my effort a bit on this project.

In my spare time, I did get the hacked magazines attached to the spring feeder "tubes". I temporarily hooked up a servo and it seems plenty strong to drive the BBs into the gun at a fair bit of speed. I fed a few hundred rounds through the spring and it all went fine with no jams. It looks like the automatic ammo feed is going to work great in the end so I'm pretty happy with that.

I also tried to get some free stuff over at Sparkfun today and after that debacle I went ahead and just ordered all the rest of the electronics I need from Trossen. Specifically, I snagged 10 EasyDriver v4s (that gives me two spares in case bad things happen) and the XBee pieces so I can control my mech remotely. Andrew was very helpful over the phone and Trossen has just pulled in another customer because of it. I plan on ordering my gears tomorrow if I get some time.

Have fun!

Mike

webgeek
01-08-2010, 10:50 PM
Electrical questions abound! I spent a few minutes tonight drawing a very poor diagram of how I'd like to power my mech and I was hoping to get some feedback from the experts before I start wiring things up. I'm using two 11.1v LiPo batteries to power the mech. Here are the power requirements:

5v
Camera
XBee w/regulated board
Both servos for the ammo feeds
10 x EasyDriver boards
2 x gun relay boards

Right around 12v (11.1 works fine)
2 x guns

Less than 16v and more then 6v
Axon II

As much as I can supply, IE: 22.2v
10 stepper motors

Now the Axon has a pretty hefty regulator on it (<1.5 amps) so I believe it can power all of the 5v stuff no problem. Even if everything is turned on at once, I doubt the current draw will be over an amp and the regulator has thermal protection in it if I do go a bit overboard. The problem is that the Axon II can't get more than 16v into it as that's the max on the regulator.

So my idea is this: each gun gets taped to a different battery, the steppers use the batteries in series, and the axon taps off a single battery. I know that this will cause the batteries to drain unevenly but I think the differential will be small enough that it's ok. I'll be recharging the batteries individually, not as a 22v pack so for each run they will be re-balanced automatically. I know this is a no-no but I don't know of an efficient solution around it. Any ideas would be greatly appreciated.

My poor and confusing diagram is attached. I didn't have Visio handy so it's pretty nasty, sorry about that. The heavy lines are 22v, the thiner lines coming from the Axon are 5v and the gun lines are 11.1v.

Thanks!

Mike

societyofrobots
01-09-2010, 10:54 PM
For purposes of efficiency, you want the voltage regulator voltage difference to be as small as possible. For example, if you want 5V regulated output, but you give it 11V, you'll have a 5/11 = 45&#37; efficiency. That means half your battery energy will be burned up as waste.

Now it appears you are putting these 11V batteries in series, and your plan probably won't damage anything, but the uneven discharging will cause your total voltage to drop faster. That'll cause your motor torque to drop faster.

What I recommend is getting a 3rd battery - a small 6V NiMH battery used to power all 5V logic. Then use your beefy batteries to power the heavy load motors and relays and such. That way you have maximum efficiency, and your mcu won't reset if your motors drain too much power.

webgeek
01-09-2010, 11:23 PM
What I recommend is getting a 3rd battery - a small 6V NiMH battery used to power all 5V logic. Then use your beefy batteries to power the heavy load motors and relays and such. That way you have maximum efficiency, and your mcu won't reset if your motors drain too much power.Doh, I was worried you'd say that. Ok, I guess I'll snag another set of LiPo's to power the rest. Thanks for the input!

webgeek
01-09-2010, 11:35 PM
January 9th, 2010 Status
Ok, had a few hours to kick around on the computer today and I spent some time programing the PC side of the system. I wasn't sure if I was going to go with Java or C# in the end but I've decided on Java. It's generally my language of choice when in doubt due to the absolutely massive open source community behind it (I'm a big fan of both CodeHaus and the Apache Foundation and their Java projects.)

So I spent some time digging around to see what I could find. I've tracked down a pretty slick XBee Java API that looks perfect for my project as well as some MJPEG stream viewing code that should interface nicely with the TrendNet camera.

Finally I stumbled upon a library that allows access to game input devices. I'd not planed on using a game pad but after thinking about it a bit, I decided I would. So I took the library (JXInput from http://www.hardcode.de/jxinput/) and wired up the beginning of my control application. Lo and behold, it actually works pretty well. I've over-engineered the application a bit because, to be honest, I don't really want to even think about it long term. I see it was the least interesting part of this project and I want it to be totally bullet-proof. I've heavily decoupled the logic behind getting hardware updates from the game pad and the UI on the screen. This will make it easy to replace chunks of the program in the future if need be.

I don't have anything too cool to show but I did put a small video together showing the starting point of my app recieving information from the game pad (a Logitech Rumble Pad 2 in this case) and displaying it's state on the screen. It's a little hard to see at this small size, I suggest full screen or view it at YouTube to actually see what's happening.

YouTube- Logitech Game Pad in a Java Application

Have fun!

-Mike

societyofrobots
01-09-2010, 11:36 PM
Emphasis on NiMH battery. The smallest Li-Po battery you can use on a 5V regulator is 7.4V.

That gives you a 67&#37; efficiency. Plus, you really don't need to pay for a 20A current output when you won't use more than 1A for your 5V logic.

billyzelsnack
01-09-2010, 11:57 PM
For purposes of efficiency, you want the voltage regulator voltage difference to be as small as possible. For example, if you want 5V regulated output, but you give it 11V, you'll have a 5/11 = 45% efficiency. That means half your battery energy will be burned up as waste.

Now it appears you are putting these 11V batteries in series, and your plan probably won't damage anything, but the uneven discharging will cause your total voltage to drop faster. That'll cause your motor torque to drop faster.

What I recommend is getting a 3rd battery - a small 6V NiMH battery used to power all 5V logic. Then use your beefy batteries to power the heavy load motors and relays and such. That way you have maximum efficiency, and your mcu won't reset if your motors drain too much power.

If his 5V stuff does not require much current the efficiency gained from a second battery might be lost because now the robot has to carry around more weight.

Also.. A switching regulator would not have such horrible efficiency would it?

societyofrobots
01-10-2010, 01:07 AM
If his 5V stuff does not require much current the efficiency gained from a second battery might be lost because now the robot has to carry around more weight.
Compared to those two 11V 4000mAh batteries (I'm guessing the mAh), a single 6V 500mAh battery is negligible weight wise. It definitely wouldn't result in a ~40&#37; energy loss from extra weight!


Also.. A switching regulator would not have such horrible efficiency would it?
You can cut out the Axon regulator and replace it with a switching regulator. Worst-case, the SR will have an 80% efficiency. Keep in mind though that it won't be as accurate, resulting in decreased ADC sensor accuracy.

webgeek
01-10-2010, 11:42 PM
January 10th, 2010 Status
Actually made some great and unexpected progress today. On a whim, I found a local place that sells the TrendNet IP 110w camera and so I picked it up.

I fully expected getting it integrated to be a real hassle or to not actually work that well. The end result really surprised me! It was not too hard to get it integrated and more importantly, it works great. I was able to tie it into my control application with the addition of only a couple of classes and the performance is much better than I expected. I was worried the framerate would be quite low but even on the highest quality setting, it runs steady at ~30fps. I'm very pleased about that. The key code is here if anyone is interested:
http://forums.sun.com/thread.jspa?messageID=4042430#4042430

So while the progress isn't mechanical or electronic, it's still pretty crucial. I need reliable software to control my mech or competing will be tough. I'm going to spend some time tomorrow playing around with the HUD more, getting some sounds effects in there (cause it's fun and hopefully a crowd pleaser) as well as getting the most critical information displayed then it's back to electronics. I figure I'll show if I'm firing or not, where damage is coming from, the status of the rockets and guns, the health of the mech, etc. I'm thinking of having my company's office manager record some voice for the UI. She has a British accent and I think it'd be a suitably fun addition to the mech.

I've created a video of where it's at now to show off the new gamepad controls a bit. Nothing too snazzy but I'm pretty happy with it. The video is 640 x 480 and quite small for the sake of file size but the actual app window will be a bit larger - more like 1024 x 768. That makes the cursor such a better scale and looks better with more available real-estate. Anyways, here is the video:

YouTube- Preliminary Nostromo HUD

There is one problem irritating me... The red glow around the crosshairs and such is actually a fade in the source PNG files I created. For some reason, the JPanel isn't honoring the 24bit alpha setting of the image and showing it as totally opaque. I've found some source that appears to address the problem and I plan on giving it a go tomorrow. The UI will be quite a bit more "subtle" once I get 24bit alpha (as opposed to 8bit) working properly in the panel.

Have fun!

-Mike

Noog
01-11-2010, 12:09 PM
You've made some nice progress on the integration front. Keep up the good work!

Are you modelling the HUD after anything specific (like any of the mechanized combat games that currently exist) ?

Noog

webgeek
01-11-2010, 12:13 PM
You've made some nice progress on the integration front. Keep up the good work!Thanks! I appreciate the kind words!

Are you modelling the HUD after anything specific (like any of the mechanized combat games that currently exist) ?Nope, just kinda winging it. The last mech game I played was Mech Warrior 2 and I frankly don't remember much about it other than it was fun.

I plan on finishing up the HUD stuff for now today. I convinced my office manager to provide voice effects for it and I'm going to get all the other stuff added to it while I'm on a long conference call. Hopefully I've have a much more interesting video tonight.

-Mike

darkback2
01-11-2010, 01:11 PM
Hey,

Is your camera and gun mounted on the same turret? I found that it worked best to either move the camera and the gun at the same time, or just move the gun. Charlie one of my mechs did the first, Squidword does the second. So with Charlie the cross hairs are always centered because the joystick was connected directly to the turret. With Squidword you can click on the image, and the gun aims at what you are clicking on.

DB

webgeek
01-11-2010, 03:51 PM
Is your camera and gun mounted on the same turret? The guns/rockets and camera will be mounted together. The center "target reticle" in the video is where the guns will fire. The cross hairs will be used to control where the turret is pointing. For example, if the cross hairs are to the right and down of the targeting reticle, the turret will move in that direction. Make sense?

Thanks!

Mike

webgeek
01-12-2010, 09:05 PM
January 12th 2010 Status
YouTube was down for maintenance last night so I didn't get to post my latest HUD video. I'm almost done with it until I start integrating the XBee controls. I'm quite happy with how it's turned out. It's almost as video-gamey as I wanted and I think the robotic British accent wielding voice is just perfect :)

Anyways, I've got it showing health bar, ammo levels for each rocket bank and each separate gun. I've also got the software enable/disable controls all working so I can turn off rockets and such in the competition.

The last thing to add to the HUD is the visual indicator of where damage is originating in orientation to the current camera view as well as provide some indicator of what movement is occurring in the mech itself. I might also add some rotational information so I know how far from center the turret is in both elevation and attitude. Probably get all that in there tomorrow. Anyways, here is the video you can watch to see this all - you will want to turn on high quality and increase the sound to catch it all:
YouTube- Nostromo HUD Updated

On the hardware front, I got my Trossen order today - nice and snappy :) I have already installed all the needed headers on my EasyDriver boards. They are now outfitted and good to go. I'm still waiting on the special AXON II friendly XBee adapter board to arrive before I can really dig into the protocol stuff. Have fun!

-Mike

Noog
01-13-2010, 08:06 AM
That is awesome! You were right about using the British accent as the voice for your interface. It fits perfectly. =)

Sopzman
01-13-2010, 11:50 AM
The work you've done is really impressive, but I'm with Noog - that voice really makes it!
So when you're at work and she's giving you orders, do you over mash the "O" key in an attempt to override?

webgeek
01-13-2010, 12:33 PM
Thanks for the kind words, I appreciate it :)

The robotic voice was originally going to be the voice of my office manager but I liked the sound of this one for a mech even more. The irony is that this voice is VERY close to hers and so now we've been teasing her that this voice will be her replacement. I've even gone so far as to record her most common phone greetings so I can play them back to her :)

webgeek
01-13-2010, 09:22 PM
January 13th 2010 Status
No video for today - no time for coding. I did get my XBees configured properly - that was easier than I'd expected but I don't have the breakout board for the Axon II to interface with so I've not got them wired up, only set up via software. I also received my batteries from China today so I ran down to the hobby shop and got Dean's connectors for them and a new balancer board so I can use my RC car/helicopter charger to charge em up. I then soldered on all the connectors soldered and added insulation. The batteries arrived about two weeks earlier than I expected so I'm going to change the order of my plans a little bit to test out the guns and motors at proper voltages tomorrow once the batteries are charged. We'll see how it all comes together then. Have fun!

Mike

webgeek
01-14-2010, 10:19 PM
January 14th 2010 Status
Ugh, super sick - no work today. I'm posting here just so I can keep up my momentum. I've been fighting the bug for a few days now and it really stepped up the fight starting last night. Hopefully it will wind down this weekend as I really need to get back to my mechanics!

-Mike

webgeek
01-15-2010, 10:23 PM
January 15th 2010 Status
Another sick day, basically napped and watched TV all day - very boring and not my typical way to spend a Friday. I'm feeling a little bit better (slightly) this evening and so I spent some time soldering up my connector wiring harness to get my two 3800 mah LiPo batteries producing both 11.2v and 22.4v directly. I'm going to use a 7.4v LiPo packs I use for my small RC cars to power the electronics directly. I think it should all come together nicely.

Any advice on how many sets of batteries I should bring? I was planning on two sets (4 11.2v LiPos and 2 7.4v LiPos) that are all charged before I go but I wanted to know if other people suggest more than that. Thanks!

Mike

lnxfergy
01-16-2010, 01:20 AM
Before we can say how many sets: how many matches (up to 12 minutes + prep/shutdown time) can you do on a charge, and how long does it take to charge a full set?

-Fergs

webgeek
01-16-2010, 11:47 PM
January 16th 2010 Status
Still very sick - starting to get totally fed up with this danged illness!! It's progressed from sore throat and fever to now include a painful cough and lots of sneezing. Good stuff :)

As with yesterday, I basically vegged out all day in front of the TV but with a computer on my lap. I played around with some fiducial tracking APIs and got it working properly though it's too tightly tied to the concept of "augmented reality" currently. The tracker API is designed around the concept that you will only use it's results in a 3d engine and no where else. This makes for some annoying code work arounds I've not got implemented yet. Specifically I need to take the output of the API (which I think is the coordinate information for a camera pointing straight at the fiducial - good for 3d, bad for everything else) and turn it into something that says "here are the x/y coordinates and width/height of your target in the supplied image." Talk about a pain!


Before we can say how many sets: how many matches (up to 12 minutes + prep/shutdown time) can you do on a charge, and how long does it take to charge a full set?This is why asking questions while sick is a bad idea. I asked a different question on a different forum and it was equally as dumb. Once I get the hard numbers of motor drain while the mech is in use, I'll be able to ask this question a bit more intelligently. Thanks!

-Mike

webgeek
01-18-2010, 12:12 AM
January 17th 2010 Status
Another sick day - though I think I'm starting to get over the hump. Mostly just coughing now. Sadly my wife has caught the cold/flu too and now I'm a bit nervous about our 6-month old daughter getting her first illness. Fun stuff :(

I did get a little bit of work done today - I created a pair of battery regulator circuits to watch both of my big LiPos. That makes the work sound so much more impressive than it is. Really, it's just a pair of voltage dividers and some headers so I can easily connect them to the microcontroller.

With any luck my SelmaWare breakout board for the XBee will arrive tomorrow so I can start playing with it and get the microcontroller actually talking to my HUD software. I also need to get started on the machining soon so I can test all my ideas. The electronics are basically done at this point. Have fun!

Mike

webgeek
01-20-2010, 12:11 AM
January 20th 2010 Status
Started playing with XBees today. What a pain in the rear end. How the heck do people test these? I've followed the directions found here: http://forums.trossenrobotics.com/tutorials/how-to-diy-128/xbee-basics-3259/ (super helpful by the way!) but beyond being able to ensure each XBee is set up properly and I can talk to it via a com port, I'm stuck.

I tried using the range test application in X-CTU and it doesn't want to communicate with my other XBee at all. The "receive" light on the remote XBee goes off, but it never seems to echo back the expected response. To make it worse, I then wrote code to try and read off the bytes that are supposedly being received - nothing. The data is sent AND it acts like it's received but there is never anything to read on the buffer. Very irritating. I was worried this would be the most frustrating part of the project and it's looking like my fears are coming true.

-Mike

lnxfergy
01-20-2010, 09:43 AM
Are they setup properly? 99.9% of problems are in the setup:


Are both XBEEs on the same channel? Same baud?
Are they both on the same PAN (the ID)?
Do both have different MY address?
Does the DL of one point to the MY of the other? (for each?)

XBEEs really are quite easy and pain free in my experience, I've got about a dozen of them and have never really had any problems.

-Fergs

webgeek
01-20-2010, 10:43 AM
Are they setup properly? Hah, I posted my status update before getting it solved - I fixed it late last night. The problem appears to lie in the WebBotLib API. I was using an API call that returns the state of the receive buffer. It was always coming back as empty even though there was data to be read. Removing that call totally solved the problem. How frustrating :)

-Mike

webgeek
01-20-2010, 10:46 PM
January 20th 2010 Status #2
Ok, small update today. I spent some time playing around with the XBees a bit more and think I'm finally on the right track. I've got API mode working on both of them and they can communicate back and forth. The API problem giving me trouble was really the only thing I ran into.

Tomorrow I'm going to switch to C++ for this project and probably stop using AVR Studio in favor of using Make files. This will get me closer to how a friend of mine works on the AVR. Consequently, it gets me closer to getting effective help when I need it ;)

Have fun!

Mike

KurtEck
01-21-2010, 10:12 AM
Hah, I posted my status update before getting it solved - I fixed it late last night. The problem appears to lie in the WebBotLib API. I was using an API call that returns the state of the receive buffer. It was always coming back as empty even though there was data to be read. Removing that call totally solved the problem. How frustrating :)

-Mike
Hi Mike,
I did some more investigating of what was going on with your code that did:


while(!uartReceiveBufferIsEmpty(UART0)) {
...
}


I found that the problem was that you defined the buffer sizes after you included the system header files (sys\axon2). This file includes the atmega640.h which if the buffer sizes are not defined defaults to an unbuffered serial port. Then if you look at how the usartReceiveBufferIsEmpty definition you will find:

// Returns TRUE/FALSE if receive buffer is empty/not-empty.
#define uartReceiveBufferIsEmpty(uart) __uartReceiveBufferIsEmpty(&((uart)->_uart_))
static __inline__ boolean __uartReceiveBufferIsEmpty(const UART* uart){
return (__uartGetRxBuffer(uart)==null || __uartGetRxBuffer(uart)->datalength == 0);
}

Which as you have no buffer the function will always return TRUE and as such you will never enter your stuff within the while loop. Hope this helps.

Kurt

webgeek
01-31-2010, 10:26 PM
January 31th 2010 Status
11 days with no update is pretty awful, I know. I don't have anything but excuses. I ended up having to do a ton of work on my CNC mill to get it running again for this project. Additionally, I had to switch my CAD/CAM process from EdgeCAM to MasterCAM for a variety of reasons. This ultimately meant that I've had to recreate my models from scratch in MasterCAM (and learn it from scratch to boot). I think I'm finally now getting up to speed. I've got a good process down and the mill is humming along. I have at least some of the aluminum I need for the project and I expect to rip out a lot of parts over the rest of this week.

I'm going to be prototyping each part in conjunction with the others one at a time until I'm happy with the function of that assembly. For instance, the attached image shows the first four parts needed (still in their scrap - I've not cut them out yet) that will make up part of the leg assembly. My goal is to get a good bit more of the leg assembly done tomorrow night. Now that the process is going well, the actual machining goes pretty fast. It takes maybe 20-30 minutes to make one of those leg side plates from nothing to complete. Most of that time is the unattended milling itself. The other parts are considerably quicker.

Sadly, I'm going to be held up a few days waiting for a hand tapping machine to arrive. It's desperately needed for me to tap a lot of the tiny holes in the mech. There is no way I'll be able to tap some of the edge-on holes effectively without it. I'd rather a tapping head for my mill but I'm still too cheap for that :)


Which as you have no buffer the function will always return TRUE and as such you will never enter your stuff within the while loop. Hope this helps. Yup, that helps a lot Kurt, thanks!

Anyways, have fun!

-Mike

webgeek
02-04-2010, 12:01 AM
February 3rd, 2010 Status
Been SUPER busy with the day job these last few days so I've had CAD time but no machining time. I've finalized the design of the hip joints and had time to machine my first part for them. I'm going to use #25 chain to transfer motor power to the hips themselves and so I machined a sprocket with the ball bearing races needed for my design. I've attached some pics of it. I plan on machining a bit more of the assembly tomorrow and have something to show then.

-Mike

webgeek
02-07-2010, 11:57 PM
February 7th, 2010 Status
As always, less progress than I'd hoped but I did hit a solid milestone today. I finally got my CNC mill back up where it needs to be: consistent and reliable. I was able to churn out a few iterations of my parts this afternoon and have come up with what I believe will be the final design for the leg hip joints.

I also picked up a vibrating tumbler to clean up the parts. I like how they come out when done - a nice mat finish if you stop at deburing. I'm debating if I'll anodize or not. My friend mills, tumbles, and anodizes all of his parts and they look great but it's a ton of work in the end.

I've learned that final seems to have separate meanings. There is the final "paper" design which I've had for a while. Then you make that design in metal and find it has problems - like it doesn't leave enough clearance for the heads of socket cap screws, or it doesn't take into account how thick the edge of #25 chain really is. All sorts of fun things like that. I'm sure I'll learn new meanings for the word "final" when I start actually trying to use this joint.

Anyways, I created a rather long winded shaky cam video showing the joint and it's various components. You can see it below:
YouTube- Hip Joint Assembly Overview

Have fun!

-Mike

webgeek
02-11-2010, 10:37 PM
February 11th, 2010 Status
I've not been posting much, but it's not due to lack of progress. I've actually gotten quite a bit done but I'm slammed at work so by the time I get some parts made, it's time to go to bed.

In the last few days, I've designed and milled the two side plates needed for the turret - these include the flanged ball bearing pockets as well as the motor mount pocket and the holes needed to put it all together. I've designed and created the camera mounting bracket as well. The camera and guns will all attach to a 1/2" rod that's held by the bearings. The rod has a sprocket on it that will be used to handle elevation. The azimuth will use a hip joint like I show in the video. My goal is to have all the mechanics done for the turret this weekend.

Since my last post, I've also purchased all the aluminum needed to finish the project and I snagged the scoring electronics too. Just waiting on the target plates to arrive.

I'll get some images up either tomorrow or this weekend. Thanks!

-Mike

webgeek
02-13-2010, 10:23 PM
February 13th, 2010 Status
Things are going great. I've finished all the sprockets needed for the turret. I've also got the attachment collars done (a picture tomorrow will explain this) for the turret axle as well as for both motors.

I'm still hoping to finish the turret mechanics tomorrow, but it's going to be close. I have two design two more parts - both straightforward at least. I have to mill about 10 parts to finish it up. I also have to tap lots of little holes in those parts. I'm pretty confident I can get it all together though - I'm excited to see it done so I plan to put a full day in on it.

-Mike

webgeek
03-30-2010, 08:57 AM
Well it's official, I'm just not going to make it to the games. I've had to go out of town 4 times in the last two months and pretty much every trip has burned most of a weekend which is the only time I can do work. That, combined with my slow learning of machining, has basically ensured that while I have the design 80% done and the parts about 60% done I won't be able to make it with something I feel has a serious chance of winning. I have no interest attending with something that I don't feel is a real threat.

I can't tell you how disappointed I am in this, I thought I started early enough but apparently not. I'll be there next year for sure though and this does give me time to refine parts of my design that I'm not happy with.

Good luck to everyone at the competition!

-Mike

darkback2
04-01-2010, 12:55 PM
I'm not sure if it is too late or not, but regardless of the state of your bot I think you should attend. I learned a lesson last year, that I should have learned earlier, but we'll chalk it up to my being thick headed. Robogames is not about winning. Sure,,,there is the pride and recognition aspect, and the cool medals. But for me...its about spending a weekend with people who get it. People who understand why I just had to have that latest servo, or exactly what an accomplishment my robot is. Its about seeing cool solutions to problems that I never would have thought up, and stepping up my game along with everyone else.

I know for a fact that squidword won't be any more of a "threat" this year than he was last year. Given the explosion of issy like bots and bots using IK for smooth gates, I'm not going to be anywhere in the running. That said its not about winning...its about having a good time.

So I hope you can make it.

DB

mannyr7
04-02-2010, 11:22 AM
I'm not sure if it is too late or not, but regardless of the state of your bot I think you should attend. I learned a lesson last year, that I should have learned earlier, but we'll chalk it up to my being thick headed. Robogames is not about winning. Sure,,,there is the pride and recognition aspect, and the cool medals. But for me...its about spending a weekend with people who get it. People who understand why I just had to have that latest servo, or exactly what an accomplishment my robot is. Its about seeing cool solutions to problems that I never would have thought up, and stepping up my game along with everyone else.

I know for a fact that squidword won't be any more of a "threat" this year than he was last year. Given the explosion of issy like bots and bots using IK for smooth gates, I'm not going to be anywhere in the running. That said its not about winning...its about having a good time.

So I hope you can make it.

DB

I agree with you 100% DB!

societyofrobots
04-03-2010, 10:28 PM
Don't feel too bad, I got 'kicked out' of RoboGames as soon as they changed the competition date. I already bought my flight back to the US, too late!

And I agree with darkback2, its about having fun and learning, a prize is just a bonus. I never compete to win, its just a side-effect of my efforts before the event.

webgeek
04-04-2010, 07:57 AM
While I agree that I should still go, I'm having trouble justifying the various costs if I'm not competing. I'll be there next year for sure :)

Mike

societyofrobots
04-04-2010, 08:00 AM
Yea, agreed with the costs . . .

I'm going to try and do next year too. Hopefully I can justify it with the sale of a few Axons and break even . . .