It's being considered! I am not sure I want to deal with making it fully omni-directional in movement.... at least not yet. I do think that it could very easily handle the load of 2 more steppers for additional drive power and not suffer too badly at the battery end with auto-disable working as it is. Maybe jump up to 3.3Ah batteries or a bit more. I will see how much the timing belts improve the accuracy of the two reduction drives to each other and if that pans out I may go ahead and give it 4WD. Only thing I dislike about omni's is that I see a potential to have issues in floors like my garage where there is a not insignificant slope to the floor. With 4 omni-wheels it's rolling down to the drain, period.
Not a big thing considering it's expected to operate on my downstairs tile floor but I kinda want to see how it could fair on driveways and sidewalks too. Another option is the Mechanum(sp) wheels, but they are quite spendy.
Another option is the Mecanum(sp) wheels, but they are quite spendy.
If so, go for the VEX mecanum wheels, cheaper than and infinitely superior to Sparkfun's sorry offering from Fingertech. Duane is using those on a Rover 5 chassis, but I think that chassis is too flexy & motors too weak to take full advantage of the VEX wheels, which are heavy & strong.
WHY. WHY. does the #$^#$%^ "+ Reply to Thread" button (otherwise known as "Trash my Post" button) position itself directly where I want to click it to submit a post.
The HY-SRF05 is a strange bird (AKA "The four-buck ultrasonic sensor"). Obviously physically copied from the SRF-05 sensor down to the pin names. Obviously not copied in the functionality of those pins. The OUT pin does not switch it into a single-pin mode, so far as I can tell to this point... it does nothing but take up space. So no copy-n-paste ping drivers for this one. The other functional difference is that it will not lower the echo line after a failure to hear an echo after some period of time. If the echo is lost somewhere in the fog then the line will remain high till Jesus comes home or you fire the sensor again. You have to discard readings that take longer than 12 or 13ms for the return trip. Testing in my junk filled basement indicates that is a bit beyond realistic expectations for reliable returns. For $4 to $8 each though, they work well enough.
I have made up a propeller driver for the HY-SRF05 that will deal with those issues and have it in testing. It uses cog counters for timing the flight so you can fire and forget if you have open counters. So far so good, they do seem to have a broader beam so they pick up ground clutter a bit more than the real PING))). So mounting it higher or slightly angled upwards will yield longer range.
I also made an object to bundle up 1 to 4 sensors in a group and offload them to a cog for a continual sweep. I may up that to 6 but the more sensors it has to sweep through the slower the update rate of course. Found I got best results from them by giving them 40ms between firing to keep reflected echos from messing up each others readings. With 6 sensors that would be a maximum of 4 times per second.
Hopefully by the time I have the hardware to mount them ready I'll have some software to get started with letting it roam a bit on it's own.
Here are the HY-SRF05 drivers that I have created for the robot. Borrowed several bits from the DualPing object but made some modifications to account for the pinout differences and operational differences. They seem to be working quite well for me. I have 3 of them on a breadboard sweeping away reading distances. My experimental results show 9-10 feet is just about it. Beyond that they get flakey. I set the timeout for the device at about 24ms (12ms echo return time max) because I never got any actual reading longer than that.
The group object uses the HYSRF05_S drivers (small footprint since I use 4 of them). The HYSRF05 driver is stand alone and will allow you to control 2 sonars in a single cog easily if that cog has counters that are not used.
Inching closer.... DXFs produced tonight and entered into CAM to plot the tool paths. The only drawback is that this stuff is 5052 AL and it's kinda 'gooey' when you cut it. It's claimed small tools before from chip-welding. Need to cut some plywood substrate to mount the plate to and should be cutting metal tomorrow. I did at least turn out the bearing hubs for the rear wheels today.
Neat little device. You can wire it to any number of parallel momentary push buttons for multiple power switch locations. My favorite part is 'OFF' pin. Trigger that from software and the system has a way to completely power off. My drive system will disable the stepper drives if the LiPOs drain to 10V for the pack but could still easily run them into a crater if the condition persisted for a couple of days. This switch would allow the robot to turn the lights out completely if the batteries get too low. Should be able to handle the current draw of my robot easily.
Inching closer.... DXFs produced tonight and entered into CAM to plot the tool paths. The only drawback is that this stuff is 5052 AL and it's kinda 'gooey' when you cut it. It's claimed small tools before from chip-welding. Need to cut some plywood substrate to mount the plate to and should be cutting metal tomorrow. I did at least turn out the bearing hubs for the rear wheels today.
.
You need to switch to something like 6061 Aluminum, it cuts much better, is fairly rigid and easily obtainable.
It's just a matter of what's sitting on my shelf. The local metal place only has 6061 from 3/16" thick up. The 1/8" stuff is 5052 but I didn't know that until after I bought the sheets. First tool that hit the stuff welded up and snapped in a couple of seconds. By about tool number three I had figured it out, had to be Johnny on the spot with the air and WD-40. You are right though, 6061 is great to cut, and 7075 has to be like the mark of perfection for machineability.
Well, been a long afternoon. After some things were going great in cutting the openings, the new mist system was doing fine in keeping it going unattended. I then started the slots for the drive unit attachments and it went to #$%@ in a handbasket fast. Came close to total spindle bearing failure. I noticed the smell of really hot oiled metal and put my hand on the head.... it was smoking hot!! I e-stopped and the spindle very nearly stopped inside a single rotation. It was entirely too hot to touch... at all. Themo said close to 190*F inside the casting. Not good. Stopped and dropped the whole thing out and let it cool to take a look. I think the bearings are not long for this world. I backed off the pre-load and reinstalled the spindle to finish up but they don't sound good. Way to much noise. The damage may already be done.
Then I discovered an error in the drawing when I went to machine the rear side. The holes were not symetrical as I had thought and I was using them to locate when I flipped the part over to chamfer the reverse side. Tore up the underside good and proper. Took a while to figure out how i went wrong and compensate the program for it. I did not get around to profiling the outside outline like I had wanted to today. I've had enough for the evening. Need to order new bearings and get ready for the joy of breaking them loose from the spindle. I had a feeling that they were installed a bit too tight from the get-go based on the heating I was getting back in the 3000RPM days. Should have followed my instinct on that one. After I backed the load off they were running at under 110*F at 5500RPM.
Yeah, it's going to be a $100 owchie. I just got the bearings all pulled off and they don't look fried to me. Could be a combination of too much preload and crappy china grease. The bearings surprised me a bit. NSK... not shabby really at all, unless they are counterfiet. However in the process of knocking the spindle out I smashed the lower bearing's roller cage.... "She's dead Jim!". So it's a loss. I figure if I am going to replace one I may as well do both. MSC to the rescue. Should have them before the end of the week. Ordered SKF bearings, that have a couple thousand more RPM rating (8500 vs 6500). I also ordered the Kluber miracle bearing grease. Generally it runs closer to what oil would vs grease.
Anyway I'm turning this into a fixing my machine thread so enough. Time to go back to programming for a bit cause metal cutting is done for a while.
Just to keep up the updates in one place, the proto-bots entry to Erco's figure 8 challenge from the other thread. Proving that with hundreds of dollars in machining and hours of programming I can almost do what he pulled off with some stuff from the junk drawer!
It is definately a lot harder than it looks like it will be to follow any defined arc with a diff-drive even when you have decent command over distance and speed.
I improved the speed syncronization by allowing the Arc function to calculate in RPM vs the 0 to 128 speed level which worked out to about 4 RPM. Now it can get within 1 RPM of the correct speed to syncronize the motors to each other. Obviously the bigger the arc and the longer they are moving the more even a small error can pile up on you. It will be more accurate making small turns than large ones.
I'm close to putting my spindle back in service. All the bearings are here and three of the four races are in place, just need the grease to get here so I can finish up, set the pre-load and reinstall the machine spindle. Hopefully I'll have the deck done this weekend if the grease arrives tomorrow.
WOW, It's really starting to look Lean and Mean.. I really like the look..:thumb:
And your last photo shows some clever thinking, in order to shave off a few grams of weight..;)
Good looking job! I find the large thin pieces to be the biggest challenges to machine; you can't put them in a vise and you need sacrificial material under them if they are on the table, the clamps are always in the way, and I'm always worried about a g-code problem that cuts through to the table! I've got to machine a piece like that for the HB25 motor mounts, only I need 6 of them!
Good looking job! I find the large thin pieces to be the biggest challenges to machine; you can't put them in a vise and you need sacrificial material under them if they are on the table, the clamps are always in the way, and I'm always worried about a g-code problem that cuts through to the table!
True Dat! The plate jobs are always the ones that have me scratching my head at 'how am I going to hold it to do that'. This time I used a 1/2" plywood board to hold it down. Did all the inside work with the camps on the edges then drilled holes in the plywood where my big access holes in the frame were and used those to bolt through and clamp the inside while I cut the profile. I'm probably going to make a fixture for these though. I'll probably be working on a couple more decks and I did not enjoy flipping and re-indexing them for the reversee side work.
Aluminum pegboard... I like that. The holes were a good idea. Glad I didn't leave it off because that is going to be very useful, if a bit tedius to clean up all the holes. In fact I should have continued them on back all the way. The deck came in at 11.5 oz. I was hoping for closer to 8 oz. That little bugger is now over 5lbs. I'm going to have to start being careful. Might have to start looking at makeing parts in Delrin if possible. It was to expensive for the deck though. I'm paying more for a plastic deck than I would to make a nice metal one.
@ DriverBob, yeah but I'm betting you have a good deal more that ~200 oz-in of (idealized) motive force..... fatso!!!!
Prowler-Bot has it's first sense of the world! Sharp IR proximity detectors allow my demo code to abort when it senses an object in front. Nothing exciting yet, it just forces a hard-stop and a reboot but no more plowing into stuff in front anyway! Now i have just enough to start playing with behavior based programming for this sucker. Probaly will start with little more than patrol and avoid but should be enough for me to learn on. I guess I better start looking to make a PCB for the motor drivers and main power. The breadboard is getting awful full and it's going to be much more likely I fry something by accident.
Great job, sensors are wonderful. Just don't get hoodwinked and go down the "behavior" buzzword path. If I read one more story touting "emergent behavior" and the wonderfully complex and unanticipated actions stemming from "sensor fusion" (more like sensor confusion if people can't figure out why their multi-sensor bot did something), I'm gonna find a new hobby. Sensors "sense" and your code interprets the readings and reacts. Pretty straightforward stuff!
Behaviour in the sense of a defined set of actions and priorities. The last thing I am interested in something that does whatever it likes and I write papers about how interesting it was when it unexpectedly opened the front door and chased the nieghbor kid.
A test of basic roaming and avoiding. Aside from the false triggers I keep getting from one IR sensor it's working OK. The scope shows one sensor keeps having little 5ms excursions to low. I'll see if making the sensor cog sample as best two out of three helps any with that. I remember seeing one sensor that kept blinking a little here and there in testing too.
Other change needed is I'm going to need a physical 'BUSY' line for the motor controller. I need to be able to sample that rapidly to decide if the last move was completed but doing it 10 times per second over the I2C interface starts to interfere with the generation of step pulses and you can hear it. I was hoping to avoid having to do that. Kinda takes away from the '2 wire' thing. But at robot speeds faster than this even checking 10 times per second I can quickly over-run the sensors detection range and I don't want to eat the whole I2C bus with nothing but status checks while moving.
My behavior functions I'm trying to keep re-entrant. They don't block execution so that another higher priority function can get a bite at the apple if needed so it's complicated to get it right. I'm hoping once I get these two working together good then it will provide a template to build on. The main issue I see is how I can deal with the situation where I see an obstacle ahead, I start avoiding but then run into something behind me... but I'm already avoiding this way so how do I prevent it just oscillating back and forth or becoming paralyzed. For now it's easy! I just bash into whatever is behind me.
The sampling method took care of the false trigger issue. Works exactly as it should. I added a few indicator LED signals and a flashing battery meter 60+ / 30+ / 0+ so I have some indication of how close it is to exhaustion. Because of it's low duty cycle nature, I do think it's going to be able to get through a night on a single charge or very close to it.
Ok, back to getting parts made again. Had to see it moving on it's own first though.
Comments
-Tommy
Not a big thing considering it's expected to operate on my downstairs tile floor but I kinda want to see how it could fair on driveways and sidewalks too. Another option is the Mechanum(sp) wheels, but they are quite spendy.
If so, go for the VEX mecanum wheels, cheaper than and infinitely superior to Sparkfun's sorry offering from Fingertech. Duane is using those on a Rover 5 chassis, but I think that chassis is too flexy & motors too weak to take full advantage of the VEX wheels, which are heavy & strong.
The HY-SRF05 is a strange bird (AKA "The four-buck ultrasonic sensor"). Obviously physically copied from the SRF-05 sensor down to the pin names. Obviously not copied in the functionality of those pins. The OUT pin does not switch it into a single-pin mode, so far as I can tell to this point... it does nothing but take up space. So no copy-n-paste ping drivers for this one. The other functional difference is that it will not lower the echo line after a failure to hear an echo after some period of time. If the echo is lost somewhere in the fog then the line will remain high till Jesus comes home or you fire the sensor again. You have to discard readings that take longer than 12 or 13ms for the return trip. Testing in my junk filled basement indicates that is a bit beyond realistic expectations for reliable returns. For $4 to $8 each though, they work well enough.
I have made up a propeller driver for the HY-SRF05 that will deal with those issues and have it in testing. It uses cog counters for timing the flight so you can fire and forget if you have open counters. So far so good, they do seem to have a broader beam so they pick up ground clutter a bit more than the real PING))). So mounting it higher or slightly angled upwards will yield longer range.
I also made an object to bundle up 1 to 4 sensors in a group and offload them to a cog for a continual sweep. I may up that to 6 but the more sensors it has to sweep through the slower the update rate of course. Found I got best results from them by giving them 40ms between firing to keep reflected echos from messing up each others readings. With 6 sensors that would be a maximum of 4 times per second.
Hopefully by the time I have the hardware to mount them ready I'll have some software to get started with letting it roam a bit on it's own.
Video of the new turning commands and auto-sleep functions
The group object uses the HYSRF05_S drivers (small footprint since I use 4 of them). The HYSRF05 driver is stand alone and will allow you to control 2 sonars in a single cog easily if that cog has counters that are not used.
I picked up a couple of these latching push-button switches to try out:
http://www.pololu.com/catalog/product/750/resources
Neat little device. You can wire it to any number of parallel momentary push buttons for multiple power switch locations. My favorite part is 'OFF' pin. Trigger that from software and the system has a way to completely power off. My drive system will disable the stepper drives if the LiPOs drain to 10V for the pack but could still easily run them into a crater if the condition persisted for a couple of days. This switch would allow the robot to turn the lights out completely if the batteries get too low. Should be able to handle the current draw of my robot easily.
You need to switch to something like 6061 Aluminum, it cuts much better, is fairly rigid and easily obtainable.
Bob
Then I discovered an error in the drawing when I went to machine the rear side. The holes were not symetrical as I had thought and I was using them to locate when I flipped the part over to chamfer the reverse side. Tore up the underside good and proper. Took a while to figure out how i went wrong and compensate the program for it. I did not get around to profiling the outside outline like I had wanted to today. I've had enough for the evening. Need to order new bearings and get ready for the joy of breaking them loose from the spindle. I had a feeling that they were installed a bit too tight from the get-go based on the heating I was getting back in the 3000RPM days. Should have followed my instinct on that one. After I backed the load off they were running at under 110*F at 5500RPM.
Sigh..... Long day.
Bob
But hey, what you did get machined, looks impressive though.
-Tommy
Anyway I'm turning this into a fixing my machine thread so enough. Time to go back to programming for a bit cause metal cutting is done for a while.
Just to keep up the updates in one place, the proto-bots entry to Erco's figure 8 challenge from the other thread. Proving that with hundreds of dollars in machining and hours of programming I can almost do what he pulled off with some stuff from the junk drawer!
It is definately a lot harder than it looks like it will be to follow any defined arc with a diff-drive even when you have decent command over distance and speed.
I improved the speed syncronization by allowing the Arc function to calculate in RPM vs the 0 to 128 speed level which worked out to about 4 RPM. Now it can get within 1 RPM of the correct speed to syncronize the motors to each other. Obviously the bigger the arc and the longer they are moving the more even a small error can pile up on you. It will be more accurate making small turns than large ones.
I'm close to putting my spindle back in service. All the bearings are here and three of the four races are in place, just need the grease to get here so I can finish up, set the pre-load and reinstall the machine spindle. Hopefully I'll have the deck done this weekend if the grease arrives tomorrow.
The new bod:
Of course I always jack something up on the last operation of an incredibly long and complicated job:
This is why version 1 is always eventually replaced.... I learn what not to do.
And your last photo shows some clever thinking, in order to shave off a few grams of weight..;)
-Tommy
Bob
Makes far more sense than these aluminum wrenches. Can someone please explain these to me...
http://cgi.ebay.com/Summit-8-Piece-Aluminum-AN-Wrench-Set/330698221263?_trksid=p1468660.m2000037
True Dat! The plate jobs are always the ones that have me scratching my head at 'how am I going to hold it to do that'. This time I used a 1/2" plywood board to hold it down. Did all the inside work with the camps on the edges then drilled holes in the plywood where my big access holes in the frame were and used those to bolt through and clamp the inside while I cut the profile. I'm probably going to make a fixture for these though. I'll probably be working on a couple more decks and I did not enjoy flipping and re-indexing them for the reversee side work.
Aluminum pegboard... I like that. The holes were a good idea. Glad I didn't leave it off because that is going to be very useful, if a bit tedius to clean up all the holes. In fact I should have continued them on back all the way. The deck came in at 11.5 oz. I was hoping for closer to 8 oz. That little bugger is now over 5lbs. I'm going to have to start being careful. Might have to start looking at makeing parts in Delrin if possible. It was to expensive for the deck though. I'm paying more for a plastic deck than I would to make a nice metal one.
Bob
Prowler-Bot has it's first sense of the world! Sharp IR proximity detectors allow my demo code to abort when it senses an object in front. Nothing exciting yet, it just forces a hard-stop and a reboot but no more plowing into stuff in front anyway! Now i have just enough to start playing with behavior based programming for this sucker. Probaly will start with little more than patrol and avoid but should be enough for me to learn on. I guess I better start looking to make a PCB for the motor drivers and main power. The breadboard is getting awful full and it's going to be much more likely I fry something by accident.
A test of basic roaming and avoiding. Aside from the false triggers I keep getting from one IR sensor it's working OK. The scope shows one sensor keeps having little 5ms excursions to low. I'll see if making the sensor cog sample as best two out of three helps any with that. I remember seeing one sensor that kept blinking a little here and there in testing too.
Other change needed is I'm going to need a physical 'BUSY' line for the motor controller. I need to be able to sample that rapidly to decide if the last move was completed but doing it 10 times per second over the I2C interface starts to interfere with the generation of step pulses and you can hear it. I was hoping to avoid having to do that. Kinda takes away from the '2 wire' thing. But at robot speeds faster than this even checking 10 times per second I can quickly over-run the sensors detection range and I don't want to eat the whole I2C bus with nothing but status checks while moving.
My behavior functions I'm trying to keep re-entrant. They don't block execution so that another higher priority function can get a bite at the apple if needed so it's complicated to get it right. I'm hoping once I get these two working together good then it will provide a template to build on. The main issue I see is how I can deal with the situation where I see an obstacle ahead, I start avoiding but then run into something behind me... but I'm already avoiding this way so how do I prevent it just oscillating back and forth or becoming paralyzed. For now it's easy! I just bash into whatever is behind me.
Ok, back to getting parts made again. Had to see it moving on it's own first though.