This weekend saw some modest forward progress. I added to the programming. Nothing dramaticly new but used my current execution model to add in a new behavior.... "WATCH". This takes the place of the simple delays that I built into the PATROL function. The purpose here will be to make the robot sit still after each sucessful patrol sequence to monitor the security sensors, just PIR to start out. Those require a minute to adjust to a new ambient condition and of course can't be used on the move. So it will sit still and let them settle, then later it will sit and monitor them for another 2 to 3 minutes. Then WATCH releases and if nothing else to do it's another PATROL move.
I'm not thrilled with the current implementation. Lots of global shared variables and things you have to do just-so in each behavior or it goes off the rails. I'll have to spend some time down the road seeing if I can implement that better.
The machine work went off well this weekend. I made the final front IR braket for holding the little IR prox sensors. Didn't like the first prototype but really like the second iteration. Finally got my mist system working again. The old Craftsman compressor was not up to the task. It was originally 7Gal but I added a 10Gal extra tank. I got 4.5 minutes of run time on that but it took 4 minutes to refill. Got a new 15Gal 200PSI compressor that has the right motor for the size. I now get 7 minutes of mist and 1.5 minutes to recharge. Much nicer.
The sensors fit in like a glove. could almost leave off the screws and they would stay put just from the tight fit to the slots. I have ordered several more of these to cover left/right and rear as well as a couple to look down low since my bot rides pretty high. I did get the longer distance versions 2-10cm vs the current 0.5-5cm as I found it's easy to over-run the sensing range at high speed. I plan to use a PICAXE to take all the IR outputs and monitor them, that will then have an attention line to Prop and connect to my existing I2C bus. That takes the 8 to 10 inputs and reduces the extra pin count to 1. The IR object will then just monitor that input and then grab the data over I2C when there is a sensor tripped. Will probably do something similar with the PIR since it is another place where I can save several pins not having to monitor them individually.
I have also started to make up the shield board to plug the stepper drivers into and fit to the Uno32. I'll be using the Pulsar PCB fx kit to produce the circuit board for it. Hopefully in a few weekends I can get rid of the big pressboard with the prototyping boards on it and open up some space on the chasis for the power circuits to be made permanent.
Ok, the Pulsar claim of 8 minute boards.... well, I doubt it. The quality of what I can make in my basement though.... very cool. I'm getting pretty decent at the process now. Drilling the holes and setting up to do so takes much longer than making the board.
I'll see this weekend if my PCB clamp Idea will work. The idea is to allow me to grab any size board and clamp it into place by the corners. The height should allow a 1/2" piece of press board to fit under it for center support. Now if I can just figure out the way to map the axis movements to arbitary angles instead of having to perfectly square the hole pattern I think it will work nicely. Board is to be the main power distribution point for logic and motors. If I have to later I can dremel the traces and hack in seperate logic battery, but so far it's doing well even in a coupled/nasty/breadboard environment so I think a single battery is going to work for me.
Edit: Also added a block diagram of the initial plans for the various systems. I want to offload as much as possible to the I2C bus. It saves me I/O and cogs. I think the PICAXE 20X2 will serve nicely in doing the basic read and monitor the sensors role and I can get what I need via I2C since none of this is super timing critical. Eventually I would like to add in the little the gyros and accelerometers. Could be useful to detect when it's been told to move but isn't.
Lots of work, little time. The protoype for the IR sensor controller is working over I2C and I finished up the prototype shield PCB for the two motor drivers to attach to the Chipkit Uno32. Everything looked good but then a weird glitch started. Whenever I ask for the battery voltage from the Uno over I2C right after I send the read address and start clocking in bits from the Uno the data line flips high-low-high during the first clock and the Uno then sees that as a stop condition and the bus goes out-of-whack. Can't figure it out since the Prop has already released the data line by then and can't be grounding it. The Uno32 code I have is all high-level. We put data in a location and say how many bytes are there and go on just like other commands that are working. It's just the one command that does it as far as I can tell. Going to be a fun one to track down..... not.
Put the circuit back onto the breadboard and the issue is gone, so I'm really scratching my head on it. Put it aside for now though. I'm backpacking into the Grand Canyon next week so the robot remains on hold.
Figured out the I2C issue. Seems my choice for low pull-up R's was the culprit. When I replaced the 1.2K with 4.7K everything was back to normal. I'm not sure if the higher pull-up current was the real issue or if the slower rise time is masking something but for now I'm going to move on with 4.7K for the I2C pullups.
Spent most of the week piddling around making board mounting adapters for the Arduino UNO for factor. This is to adapt the layout of the UNO to a 1" or 0.5" grid. I made 3 since I wanted to try a few different methods. The adapter has 15 tapped 4-40 holes so it can be used without nuts if you have some short standoffs that are the right height. It also has some 0.128 holes that were used to clamp it for the machine work but they are on the same spacing so a nut could be used with those holes. Finally there are two 0.195 slots that could be used to mount it in a non-square arrangement with #4 or #6 screws. They were powder coated in my garage with the Horrible Freight powder coat sprayer. Did two in red and one in matte black. I figured I would use them anywhere I used an arduino and wanted to mount it since drilling on a defined grid is tons easier and more adaptable than marking out the three holes on the UNO.
If anyone is interested, the one in black is up for grabs. I ended up realy liking the Harbor Freight red glossy color.
Nice work! I haven't tried powder coating, I'm going to try out anodizing sometime this summer though. Does powder coating take any special equipment? How hard/chip proof is the coating?
Thanks Bob! The stuff is really tough though it would be better if it were acid etched or bead blasted first for better adhesion. No special gear unless you count two saw horses and a plank with a big cardboard box for a booth 'special'. It works like toner. Gun charges the powder as it's blown out the gun positive and a ground clip is attached to the part via a hanger to get the powder to stick to the part. After that I transfer them on the hanger over to a small toaster oven and set it to 400 degrees and give it about 30 minutes. It's a rather thick coat though 0.002 or 0.004 so it can not be applied to a dimensionally critical area since you can't really control how thick it goes on. I got a set of high-temperature silicone plugs to use to block areas like bearing bores where I don't want it to get into to help with that. I seems quite durable to me. I have to really work at it to even chip the stuff and so far the only way I have found to remove it is to grind it off or machine it off. I know the pro shops do more metal prep than I have access to though so there is probably some compromise in what can be achived painting in the driveway and curing in a toaster oven.
I did this for a set of 13 dresser drawer pulls I made for my father-in-law in a metalic bronze I got from Eastwood company. Those came out fantastic, really nice color and texture. I was really proud of them, but I would never again agree to do them if my life depended on it. Took about $120 in metal, and about $1500 in labor time to get those all finished for him. Makes for a cool story though. Eastwood has neary every color you can think of.
I'm hoping to hit on a few gadgets that might be useful to other robotics folks along the way here so I can potentially justify pulling the trigger on a Tormach 1100 when I finish the backyard shop building.
I have a Tormach 770 in my basement, great machines! I'll be on it quite a bit today, I'm trying out a new design for my robots leg down and collision sensor housing... Hopefully it'll work this time!
Great minds think alike!!!! I have actually had this very same idea for some time now. I have everything I need
for this project with the exception of one thing: TIME!!!! I have to build mine to be IP66 or better rated, since I live south of Seattle and it will be exposed to the elements. I have a couple videos from the start of the project that I will post once I find them. I am just in the process of getting back in to the bot building after about a 3 year hyatus. I will also post my progress and would be interested in seeing yours also. Currently, my sentry consists of several CCTV cameras. Some are fixed and others are PTZ so no one area of my property is never not covered. My thought on the roaming sentry is to have 3 or 4 of them so that all sides of my home are always covered. I plan to implement an extremely loud alarm on each so if they are picked up by an intruder the whole block will know!!!! My idea is to use a wire buried a couple inches in the ground around the perimeter and have that be the following point.
Also, I wanted to point out that you are doing an AWESOME job on this project.
Just FYI, 2024 aluminum is very nice to work with. It seems to be a bit more workable thatn 6061 and 7075.
Got around to getting a DXF out for the rear wheel brackets. Got enough CAM/GCODE done to get Side-A machined. Now I need to setup the program for Side-B and get it profiled out from the plate. I have the bearing hubs ready to mount when this is done. I'll just need to make axels that fit the VEX omni wheels and I can then remove the wooden jury-rigged castor mount.
First time in a while I didn't mess something up on the first run! Guess I should knock on something since I still need to finish the back of it.
@NWUpgrades - Definately post up yours sounds really interesting. Designing for weather resistance really ups the game! Thanks for the props. I appreciate the kind comments. All I can get locally is 6061 so I tend to just go with it. My favorite thus far has been Fortal. Stuff just cuts like a dream and it very durable. 5052 is the metal of Satan. I have not gotten any 2024 to work with yet.
Finished the two rear wheel brackets as well as the bearing hubs. Need to drill the holes to attach the hubs and make axles for it. I also have to figure out how to drill the bolt holes that go on the top edge of these two. Holding flat plates square on edge is always fun. I definately like the way it's going to look on the bot.
The bearing should allow for nice fluid motion for the rear wheels and have plenty of durability. I opted for a single bearing for this application since the load is very small without the side pressure of the belt drive in the front. If it turns out to be a problem I can easily add on another bearing hub in the back to better take on the load from the weight of the robot just by going to longer 4-40 screws and sandwiching them onto the bracket.
Q: When does that Irwin POC carbon tap you bought from ACE before you knew better break?
A: In the second to last BLIND hole of the part that took all afternoon to make.
Q: How much time and moneydid you save tonight going ahead and using that tap rather than going and getting a proper HSS tap?
A: About minus 8hrs once it's disolved and minus $15 for the now broken carbide endmill I chewed the center out with.
Ugggghhhh, off to the store to see if I can find something called "Alum" to dissolve this thing out.
Edit to Add:
At least I did get the hubs drilled and mounted up tonight.
Got the broken tap out with the Alum and went over to the lathe to make some shafts. I now understand the difficulty in 'turning sewing needles'. These shafts are not easy to make. I do think in the long term it's going to need the better fixing of a double bearing. The single radial bearing has a lot more slop than I was wanting. Figured it was worth a shot. I'll have to turn up two more shafts with longer bearing journels to interface with a bearing hub on both sides of the bracket. I'm going to let the mill produce the rough bearing hubs this time and then just use the lathe to clean up the pocket and part it off the stock. Much easier than boring and turning it on the lathe. The Vex wheel was a sloppy crappy fit on a 0.125" shaft so I upped it to 0.132" and that makes a nice tight 'snap-on' fit to the shaft so now I just need to go get a 4-40 die so I can thread the tip of the shaft for a nut to hold the wheel in place. Few more days and the omni-wheels should be on well enough to test it out.
Robot on 4 wheels! The omnis are installed in the back and I think my Yak shaving is complete on the rolling elements. I will eventually go to dual bearings on the rear wheels but this gets it rolling. Threaded the ends of the axles for 4-40 nuts. Drilled and threaded the end of the bearing journal the same and the shaft is slightly shorter than the width of the inner race to allow for holding force when a washer and screw are put in place there. No more wooden block and hardware store ghetto caster.
I'll get some video of it rolling about this weekend along with a video of the mill making the rear wheel brackets.
The mini-IMU may be able to help knock down the number of items that can hang up the bot forever minus intervention. No matter where or how I position all the IR sensors or bumpers it is obvious that in a cluttered home environment it is going to find a way to get hung up on something. The IMU should allow the robot to determine... roughly... that is was moving forward and then got stopped, or that it's supposed to be moving straight but is in fact 'pole-dancing' in circles.
Deck revision 2 is being designed. I kept the original deck to a size that the mill could handle without repositioning but I really need to get a couple extra inches into the width. I want to reduce the amount the wheels stick out from the deck. They hook onto EVERYTHING right now. I just need to extend the edges out some reduce that tendency. Also I'll eliminate the big slots in the rear. All they have proved useful in doing is being in the wrong place for nearly anything I want to do. I will keep the large cable access holes every so often down the center. finally the entire plate is going to get the 1/2" hole grid.
I made some 2.625" stand offs to allow for a second level deck as well. At first this will just be to hold breadboards to test out new stuff but eventually the upper deck will be mostly brains/sensors and the lower deck will be mostly drive and power.
It was a long and fairly frustrating night getting the prototype of this working. The sonar is an array of three HYSRF05 sensors (Erco's $4 ultrasonic sensors). They are controlled by a PICAXE 20X2 that is acting as an I2C slave. The master can control the number of sensors being scanned, and enable and disable the scanning. It can then read both the raw time of flight values or get pre-calculated distances of up to about 8ft in tenths of an inch. The PICAXE can be set to either continually sweep the number of sensors we want to scan or act like a single-shot device and only scan when commanded. The quiet time (50ms) of the sensors, and the PULSIN timeout of the PICAXE (80ms) really limits the practical number to three sensors or it gets too slow for my taste. You may remember the quirk of these cheap knock-off sensors but I'll state it again. They don't ever time-out if the echo is not detected. They will leave the echo line high until the next trigger pulse is generated. If you don't time out somehow when waiting on the falling echo edge you will lock-up forever. The PICAXE timeouts for PULSIN are fixed for a given clock frequency so I run at 32MHz to get that 80ms timeout.
Working this week I got to the point that I2C was getting good readings and control commands were working well. Early tests were great but once I put it into play where the master was very aggressively hitting it for values at some point it would lock up the bus and the robot went into paralysis, or worse kept on rolling with whatever it's last command was blind. The SCL line was being pulled low and held there forever when this occured. Resetting the PICAXE would restore motion immediately and the bot picked up where it left off. So it was the PICAXE program that was going off the rails. "Why"? Tried lots of little delays wondering if there was some race condition I had going on that I could isolate. But nothing could be found that was consistent.
Then it finally dawned on me. The PICAXE had serial debug lines in there from early testing and it was always when the I2C bus got busy that things went nuts. What if the hardware clashes? Sure enough. Can't have serial statements in there after I2C is started. The serial statements shut down all interrupts to set the timing and if it happens while I2C is getting clocked in or out it locks the I2C hardware up stone cold and it will never recover. Funny thing was, I was adding more debug in there to try and isolate what was happening and thus just making the problem worse and worse.
Anyway now the sonar seems to be working. For now I simply tacked it onto the existing AVOID routine for the IR sensors but they will soon get their own version of AVOID that is a bit more elegant. I plan to only fire the front sonar when moving forward but once I reach a threshold I'll scan front/left/right and select a direction to turn that has the largest reading. Should allow me to make better choices about which way to turn than random chance. IR AVOID will also do the same and select it's direction based on the readings we get scanning all three.
Well the new shoes came in and I have to say that I kinda like them but, and it's a rather big but.... the rubber tires are hollow. Look a lot like a car tire but minus any way to inflate them. So they will have a weight limit before they start getting squashed too flat. The rims that they came with had a hole pattern that was close but just a bit less than the 3/8" pattern on my pulley hub. I was able to rig it up though by drilling those holes open with a 1/4" bit and some washers for the screws. I really like the beefier look now with these tires and they keep the calibration on the drive pretty well dead-on. So I'm working on new rims being machined from 3" solid AL stock. The AL ribbons almost buried me by the time I got the hunk turned down to the rough dimensions.
Also I ordered some 4000mAh LiPo batteries for a bit more endurance than the current 2200's. My duty cycle is still giving the robot hours and hours of run time but you can tell as more and more gets added the power is getting used up a little quicker now as would be expected. I want to continue to target a 7-9hr run time on a charged battery. I will probably go on an LED culling expedition at some point too. I know every module wants an 'on' LED but that starts to add up too. I want to make sure that LEDs that are running are conveying information other than confirming power yet again.
Also made the lid for my switch housing this afternoon. It was just too dang hot to work on the shed today but the basement was cool and inviting.
Want to hook up a shutdown output on the brain so that the system can turn itself off if the battery is critically low. The drive automatically goes to power-save but really it needs to shut down completely so that is the programming goal for the weekend. Should be fairly easy to add to the current power soft-switch.
Lastly, the days of SPIN are numbered for my robot. While it has been useful to get a working example built there are lots of times that I find myself wishing for organized data structures, object inheritance, and passing object references not just pointers to the guts of something elses data. All this leads me back towards the world of C++. With PropGCC coming along nicely im going to start looking to convert my drivers and code over to C/C++. I will add some FLASH to the robot to allow for larger code size with XMMC. I will miss the simplicity of the file management in SPIN/PASM but it's turning into a real mess trying work around some things in SPIN.
Wow. Can't believe that it has been a month. Been working on my new workshop a lot despite the fact that the sun is trying to cook us alive here. Also took a week vacation to Canada where I started writing the C++ objects in earnest as well as camping, kayaking, and swimming. Not much has changed on the robot from the last post but I have made good progress on the code. I have a working 100/400KHz I2C open collector driver written in COG-C rather than PASM. It should allow support for multiple cogs and threads to access the bus and operates in full transactions (start -> stop) so protecting the bus from one stomping on another. It also allows for devices that use repeated start to access their registers. Wrote a C++ object to wrap that driver nicely for the higher level operations.
I have built up from that foundation, some objects that access the Pololu Mini-IMU 9 device (Accelerometer, Compass, Gyro). Those objects are now working and allow you to configure and read the raw values from the devices fairly easily. Now I need to build the Mini-IMU object up so that I can get higher level information like: Tilt angle, heading, turn rate, accel direction. These would be very valuable for determining if what I said to do is actually happening. It would also allow for some more advanced mapping and navigation assuming my brain can ever be wrapped around those concepts.
C/C++ on the Propeller I will continue to be a clever hack not a nice fit but the benefits to me are some easy to plug-in code from others for the behavioral model as well as access to writing programs that are not limited to 32K for code and data. Of course the trade off for that is the very heavy overhead that C++ and nearly any library adds to the project. SPIN/PASM really is a marvel for what it's able pack into the tiny space available. Still, It's nice to be able to do fun stuff like pass an object to a function and have that function call member functions of the object. Having to make all communication between non-contained objects through pointers and sequential variables makes a big complex program a mine-field. In all fairness though, the Prop really was not designed to run "big" programs so I'm sort of shoe-horning it into my project. Propeller II, when it finally appears, would be a nice fit to this project I think.
I have also ordered a Raspberry Pi (http://www.raspberrypi.org/) to give the more logical break-down a possible go later on. That is using a 700Mhz ARM running Unix with 256MB of RAM the burden of doing all the high-level processing and leaving the sensor management and control tasks to the Propeller doing what it excels at doing.
32K code and data is just not "big". It does a awful lot in that limited space though, and someone is always making it do a little more but when you get into seriously large and complex programs it's hard to argue that the Propeller is what you should target, although we can probably all argue about what is "seriously large and complex" and what is just bloat. The line seems to be blurring more and more though. MC's are getting to the point that they really do a lot of heavy lifting. I'm kind of hoping Chip and friends extend SPIN's notion of objects and allow them to be more flexibly referenced in Propeller II because I really appreciate the compact nature of a SPIN program.
I was a little tired of the robot for a while so I have been doing some other projects. Did manage to get the new upper deck cut out over the weekend. It's 2 inches wider than the old deck (8" vs 6") and I removed some decorative slots in the rear to open up some some space for more mounting holes. The bigger deck will likely help out with the impending move to Raspberry Pi for the brains and Propeller for the sensor controller. Early testing is going well on that front.
The Raspberry is now connecting up to I2C and can successfully read and get simple orientation information from an I2C IMU as well as I2C ADC for reading battery voltage. The other big change is that I have it connected to an L6470 stepper controller chip over SPI so the Raspberry can command the two motors through a serial protocol and move on to other tasks. This will eliminate the need for the Uno32 microcontroller that was running this task and should save a lot of space and maybe some power since the Raspberry is not a real battery friendly beast.
I was able to move the bot over to it's new deck last night so it's rolling around on it's fresh new frame!
(Pics to come)
I build compitition robots from scratch. I am learning the machine work the hard way, screw it up and then ask for help. Nice work but when are trying to save weight slots are better than holes. Pullys can be cut down between the rim and the hub which works better to keep them in balence. I takes a lot of holes to lose weight.
Thanks, It's already made a big difference in the number of 'pole dancing' events that It gets stuck in. The width is definitely a lot better now.
On the slots vs holes issue. The name of this game was flexibility. It's a mobile experiment platform at present so the rear slots were taking away a lot of useful space for attachments. The weight of all the frame parts at present is far exceeded by the weight of the two steppers motors and they have a capacity to move many times more weight. They are able to move a steel plate 1/2" thick, 6" wide and 12" long. That is a heavy hunk of metal. I got lucky on these steppers, they are quite powerful for the frame size. Once I have a better idea of how I want it all together the process of building the real bot will begin and then I will reduce the frame to only what is required.
I am finally working towards completion of my outdoor powered workshop. My goal was to have everything in before winter but I may not get the lathe moved before the bad weather sets in. I should have the mill in there though by the end of the month and if the weather doesn't get too nasty I hope to have the bench for the lathe completed by mid-December then it's just a matter of getting that 400lb beast out of the basement and into the shop.
Been working on making some brackets for the 1st generation Raspberry PI when I get tired of building, moving, and arranging equipment in the new shop. It's a challenge since they gave you nothing to attach to. Got the basic design milled out, so now I just need to finish some relief slots for the mini-USB connector and any others that the frame will interfere with. I want it to be fairly general purpose even though most all my connections will be made via the GPIO header.
Comments
I'm not thrilled with the current implementation. Lots of global shared variables and things you have to do just-so in each behavior or it goes off the rails. I'll have to spend some time down the road seeing if I can implement that better.
The machine work went off well this weekend. I made the final front IR braket for holding the little IR prox sensors. Didn't like the first prototype but really like the second iteration. Finally got my mist system working again. The old Craftsman compressor was not up to the task. It was originally 7Gal but I added a 10Gal extra tank. I got 4.5 minutes of run time on that but it took 4 minutes to refill. Got a new 15Gal 200PSI compressor that has the right motor for the size. I now get 7 minutes of mist and 1.5 minutes to recharge. Much nicer.
The sensors fit in like a glove. could almost leave off the screws and they would stay put just from the tight fit to the slots. I have ordered several more of these to cover left/right and rear as well as a couple to look down low since my bot rides pretty high. I did get the longer distance versions 2-10cm vs the current 0.5-5cm as I found it's easy to over-run the sensing range at high speed. I plan to use a PICAXE to take all the IR outputs and monitor them, that will then have an attention line to Prop and connect to my existing I2C bus. That takes the 8 to 10 inputs and reduces the extra pin count to 1. The IR object will then just monitor that input and then grab the data over I2C when there is a sensor tripped. Will probably do something similar with the PIR since it is another place where I can save several pins not having to monitor them individually.
I have also started to make up the shield board to plug the stepper drivers into and fit to the Uno32. I'll be using the Pulsar PCB fx kit to produce the circuit board for it. Hopefully in a few weekends I can get rid of the big pressboard with the prototyping boards on it and open up some space on the chasis for the power circuits to be made permanent.
][video=youtube_share;tRlp1J5yojY]
I'll see this weekend if my PCB clamp Idea will work. The idea is to allow me to grab any size board and clamp it into place by the corners. The height should allow a 1/2" piece of press board to fit under it for center support. Now if I can just figure out the way to map the axis movements to arbitary angles instead of having to perfectly square the hole pattern I think it will work nicely. Board is to be the main power distribution point for logic and motors. If I have to later I can dremel the traces and hack in seperate logic battery, but so far it's doing well even in a coupled/nasty/breadboard environment so I think a single battery is going to work for me.
Edit: Also added a block diagram of the initial plans for the various systems. I want to offload as much as possible to the I2C bus. It saves me I/O and cogs. I think the PICAXE 20X2 will serve nicely in doing the basic read and monitor the sensors role and I can get what I need via I2C since none of this is super timing critical. Eventually I would like to add in the little the gyros and accelerometers. Could be useful to detect when it's been told to move but isn't.
Lots of work, little time. The protoype for the IR sensor controller is working over I2C and I finished up the prototype shield PCB for the two motor drivers to attach to the Chipkit Uno32. Everything looked good but then a weird glitch started. Whenever I ask for the battery voltage from the Uno over I2C right after I send the read address and start clocking in bits from the Uno the data line flips high-low-high during the first clock and the Uno then sees that as a stop condition and the bus goes out-of-whack. Can't figure it out since the Prop has already released the data line by then and can't be grounding it. The Uno32 code I have is all high-level. We put data in a location and say how many bytes are there and go on just like other commands that are working. It's just the one command that does it as far as I can tell. Going to be a fun one to track down..... not.
Put the circuit back onto the breadboard and the issue is gone, so I'm really scratching my head on it. Put it aside for now though. I'm backpacking into the Grand Canyon next week so the robot remains on hold.
Video of the IR Sensor Controller:
http://www.youtube.com/watch?v=BhJAChg-_w8
Spent most of the week piddling around making board mounting adapters for the Arduino UNO for factor. This is to adapt the layout of the UNO to a 1" or 0.5" grid. I made 3 since I wanted to try a few different methods. The adapter has 15 tapped 4-40 holes so it can be used without nuts if you have some short standoffs that are the right height. It also has some 0.128 holes that were used to clamp it for the machine work but they are on the same spacing so a nut could be used with those holes. Finally there are two 0.195 slots that could be used to mount it in a non-square arrangement with #4 or #6 screws. They were powder coated in my garage with the Horrible Freight powder coat sprayer. Did two in red and one in matte black. I figured I would use them anywhere I used an arduino and wanted to mount it since drilling on a defined grid is tons easier and more adaptable than marking out the three holes on the UNO.
If anyone is interested, the one in black is up for grabs. I ended up realy liking the Harbor Freight red glossy color.
Bob
I did this for a set of 13 dresser drawer pulls I made for my father-in-law in a metalic bronze I got from Eastwood company. Those came out fantastic, really nice color and texture. I was really proud of them, but I would never again agree to do them if my life depended on it. Took about $120 in metal, and about $1500 in labor time to get those all finished for him. Makes for a cool story though. Eastwood has neary every color you can think of.
I'm hoping to hit on a few gadgets that might be useful to other robotics folks along the way here so I can potentially justify pulling the trigger on a Tormach 1100 when I finish the backyard shop building.
Bob
Made four of them as onesies. I need to find some way to tap with CNC if I keep makeing things with a million tapped holes in them.
for this project with the exception of one thing: TIME!!!! I have to build mine to be IP66 or better rated, since I live south of Seattle and it will be exposed to the elements. I have a couple videos from the start of the project that I will post once I find them. I am just in the process of getting back in to the bot building after about a 3 year hyatus. I will also post my progress and would be interested in seeing yours also. Currently, my sentry consists of several CCTV cameras. Some are fixed and others are PTZ so no one area of my property is never not covered. My thought on the roaming sentry is to have 3 or 4 of them so that all sides of my home are always covered. I plan to implement an extremely loud alarm on each so if they are picked up by an intruder the whole block will know!!!! My idea is to use a wire buried a couple inches in the ground around the perimeter and have that be the following point.
Also, I wanted to point out that you are doing an AWESOME job on this project.
Just FYI, 2024 aluminum is very nice to work with. It seems to be a bit more workable thatn 6061 and 7075.
Got around to getting a DXF out for the rear wheel brackets. Got enough CAM/GCODE done to get Side-A machined. Now I need to setup the program for Side-B and get it profiled out from the plate. I have the bearing hubs ready to mount when this is done. I'll just need to make axels that fit the VEX omni wheels and I can then remove the wooden jury-rigged castor mount.
First time in a while I didn't mess something up on the first run! Guess I should knock on something since I still need to finish the back of it.
@NWUpgrades - Definately post up yours sounds really interesting. Designing for weather resistance really ups the game! Thanks for the props. I appreciate the kind comments. All I can get locally is 6061 so I tend to just go with it. My favorite thus far has been Fortal. Stuff just cuts like a dream and it very durable. 5052 is the metal of Satan. I have not gotten any 2024 to work with yet.
The bearing should allow for nice fluid motion for the rear wheels and have plenty of durability. I opted for a single bearing for this application since the load is very small without the side pressure of the belt drive in the front. If it turns out to be a problem I can easily add on another bearing hub in the back to better take on the load from the weight of the robot just by going to longer 4-40 screws and sandwiching them onto the bracket.
Q: When does that Irwin POC carbon tap you bought from ACE before you knew better break?
A: In the second to last BLIND hole of the part that took all afternoon to make.
Q: How much time and moneydid you save tonight going ahead and using that tap rather than going and getting a proper HSS tap?
A: About minus 8hrs once it's disolved and minus $15 for the now broken carbide endmill I chewed the center out with.
Ugggghhhh, off to the store to see if I can find something called "Alum" to dissolve this thing out.
Edit to Add:
At least I did get the hubs drilled and mounted up tonight.
I'll get some video of it rolling about this weekend along with a video of the mill making the rear wheel brackets.
[video=youtube_share;2VCsqyuGpYE]
It's 17 minutes long and shows each machining step abreviated (other than the 4-40 tap-drill).
http://www.pololu.com/catalog/product/1265
The mini-IMU may be able to help knock down the number of items that can hang up the bot forever minus intervention. No matter where or how I position all the IR sensors or bumpers it is obvious that in a cluttered home environment it is going to find a way to get hung up on something. The IMU should allow the robot to determine... roughly... that is was moving forward and then got stopped, or that it's supposed to be moving straight but is in fact 'pole-dancing' in circles.
Deck revision 2 is being designed. I kept the original deck to a size that the mill could handle without repositioning but I really need to get a couple extra inches into the width. I want to reduce the amount the wheels stick out from the deck. They hook onto EVERYTHING right now. I just need to extend the edges out some reduce that tendency. Also I'll eliminate the big slots in the rear. All they have proved useful in doing is being in the wrong place for nearly anything I want to do. I will keep the large cable access holes every so often down the center. finally the entire plate is going to get the 1/2" hole grid.
I made some 2.625" stand offs to allow for a second level deck as well. At first this will just be to hold breadboards to test out new stuff but eventually the upper deck will be mostly brains/sensors and the lower deck will be mostly drive and power.
It was a long and fairly frustrating night getting the prototype of this working. The sonar is an array of three HYSRF05 sensors (Erco's $4 ultrasonic sensors). They are controlled by a PICAXE 20X2 that is acting as an I2C slave. The master can control the number of sensors being scanned, and enable and disable the scanning. It can then read both the raw time of flight values or get pre-calculated distances of up to about 8ft in tenths of an inch. The PICAXE can be set to either continually sweep the number of sensors we want to scan or act like a single-shot device and only scan when commanded. The quiet time (50ms) of the sensors, and the PULSIN timeout of the PICAXE (80ms) really limits the practical number to three sensors or it gets too slow for my taste. You may remember the quirk of these cheap knock-off sensors but I'll state it again. They don't ever time-out if the echo is not detected. They will leave the echo line high until the next trigger pulse is generated. If you don't time out somehow when waiting on the falling echo edge you will lock-up forever. The PICAXE timeouts for PULSIN are fixed for a given clock frequency so I run at 32MHz to get that 80ms timeout.
Working this week I got to the point that I2C was getting good readings and control commands were working well. Early tests were great but once I put it into play where the master was very aggressively hitting it for values at some point it would lock up the bus and the robot went into paralysis, or worse kept on rolling with whatever it's last command was blind. The SCL line was being pulled low and held there forever when this occured. Resetting the PICAXE would restore motion immediately and the bot picked up where it left off. So it was the PICAXE program that was going off the rails. "Why"? Tried lots of little delays wondering if there was some race condition I had going on that I could isolate. But nothing could be found that was consistent.
Then it finally dawned on me. The PICAXE had serial debug lines in there from early testing and it was always when the I2C bus got busy that things went nuts. What if the hardware clashes? Sure enough. Can't have serial statements in there after I2C is started. The serial statements shut down all interrupts to set the timing and if it happens while I2C is getting clocked in or out it locks the I2C hardware up stone cold and it will never recover. Funny thing was, I was adding more debug in there to try and isolate what was happening and thus just making the problem worse and worse.
Anyway now the sonar seems to be working. For now I simply tacked it onto the existing AVOID routine for the IR sensors but they will soon get their own version of AVOID that is a bit more elegant. I plan to only fire the front sonar when moving forward but once I reach a threshold I'll scan front/left/right and select a direction to turn that has the largest reading. Should allow me to make better choices about which way to turn than random chance. IR AVOID will also do the same and select it's direction based on the readings we get scanning all three.
http://www.youtube.com/watch?v=fkAkSHBwWQA
[video=youtube_share;fkAkSHBwWQA]
Also made a housing for the power switch. Will be nice not having it flopping about lose anymore.
Also I ordered some 4000mAh LiPo batteries for a bit more endurance than the current 2200's. My duty cycle is still giving the robot hours and hours of run time but you can tell as more and more gets added the power is getting used up a little quicker now as would be expected. I want to continue to target a 7-9hr run time on a charged battery. I will probably go on an LED culling expedition at some point too. I know every module wants an 'on' LED but that starts to add up too. I want to make sure that LEDs that are running are conveying information other than confirming power yet again.
Also made the lid for my switch housing this afternoon. It was just too dang hot to work on the shed today but the basement was cool and inviting.
Want to hook up a shutdown output on the brain so that the system can turn itself off if the battery is critically low. The drive automatically goes to power-save but really it needs to shut down completely so that is the programming goal for the weekend. Should be fairly easy to add to the current power soft-switch.
Lastly, the days of SPIN are numbered for my robot. While it has been useful to get a working example built there are lots of times that I find myself wishing for organized data structures, object inheritance, and passing object references not just pointers to the guts of something elses data. All this leads me back towards the world of C++. With PropGCC coming along nicely im going to start looking to convert my drivers and code over to C/C++. I will add some FLASH to the robot to allow for larger code size with XMMC. I will miss the simplicity of the file management in SPIN/PASM but it's turning into a real mess trying work around some things in SPIN.
Photos attached:
I have built up from that foundation, some objects that access the Pololu Mini-IMU 9 device (Accelerometer, Compass, Gyro). Those objects are now working and allow you to configure and read the raw values from the devices fairly easily. Now I need to build the Mini-IMU object up so that I can get higher level information like: Tilt angle, heading, turn rate, accel direction. These would be very valuable for determining if what I said to do is actually happening. It would also allow for some more advanced mapping and navigation assuming my brain can ever be wrapped around those concepts.
C/C++ on the Propeller I will continue to be a clever hack not a nice fit but the benefits to me are some easy to plug-in code from others for the behavioral model as well as access to writing programs that are not limited to 32K for code and data. Of course the trade off for that is the very heavy overhead that C++ and nearly any library adds to the project. SPIN/PASM really is a marvel for what it's able pack into the tiny space available. Still, It's nice to be able to do fun stuff like pass an object to a function and have that function call member functions of the object. Having to make all communication between non-contained objects through pointers and sequential variables makes a big complex program a mine-field. In all fairness though, the Prop really was not designed to run "big" programs so I'm sort of shoe-horning it into my project. Propeller II, when it finally appears, would be a nice fit to this project I think.
I have also ordered a Raspberry Pi (http://www.raspberrypi.org/) to give the more logical break-down a possible go later on. That is using a 700Mhz ARM running Unix with 256MB of RAM the burden of doing all the high-level processing and leaving the sensor management and control tasks to the Propeller doing what it excels at doing.
Hmmm. You might get a few replies on this one.
Don't burn me at the stake!
I was a little tired of the robot for a while so I have been doing some other projects. Did manage to get the new upper deck cut out over the weekend. It's 2 inches wider than the old deck (8" vs 6") and I removed some decorative slots in the rear to open up some some space for more mounting holes. The bigger deck will likely help out with the impending move to Raspberry Pi for the brains and Propeller for the sensor controller. Early testing is going well on that front.
The Raspberry is now connecting up to I2C and can successfully read and get simple orientation information from an I2C IMU as well as I2C ADC for reading battery voltage. The other big change is that I have it connected to an L6470 stepper controller chip over SPI so the Raspberry can command the two motors through a serial protocol and move on to other tasks. This will eliminate the need for the Uno32 microcontroller that was running this task and should save a lot of space and maybe some power since the Raspberry is not a real battery friendly beast.
I was able to move the bot over to it's new deck last night so it's rolling around on it's fresh new frame!
(Pics to come)
-Kyle
Big enough to exceed the Y axis capacity of the mill.
Side by side:
Developing the Raspberry Pi Stepper Driver and IMU
On the slots vs holes issue. The name of this game was flexibility. It's a mobile experiment platform at present so the rear slots were taking away a lot of useful space for attachments. The weight of all the frame parts at present is far exceeded by the weight of the two steppers motors and they have a capacity to move many times more weight. They are able to move a steel plate 1/2" thick, 6" wide and 12" long. That is a heavy hunk of metal. I got lucky on these steppers, they are quite powerful for the frame size. Once I have a better idea of how I want it all together the process of building the real bot will begin and then I will reduce the frame to only what is required.
Been working on making some brackets for the 1st generation Raspberry PI when I get tired of building, moving, and arranging equipment in the new shop. It's a challenge since they gave you nothing to attach to. Got the basic design milled out, so now I just need to finish some relief slots for the mini-USB connector and any others that the frame will interfere with. I want it to be fairly general purpose even though most all my connections will be made via the GPIO header.