New Configuration for Skid Steer and . . .
Bill Chennault
Posts: 1,198
All--
My skid steer mechanism is mechanically finished. I have run it in a straight line by simply jumping the batteries to the two Banebot gearmotors. It is VERY powerful. I changed the configuration of the tracks due to over-complexity and the fact that the timing pulleys/belts did not meet the recommended minimum configuration of six groves engaged at all times.
Here is a picture of the new configuration which works very well . . .
And HERE is what has been taking my time away from robotics! (I just got it set today. This picture was taken while it was still on its pallet.)
Tomorrow, I am going to the range and download a few rounds. I need to RELAX!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
My skid steer mechanism is mechanically finished. I have run it in a straight line by simply jumping the batteries to the two Banebot gearmotors. It is VERY powerful. I changed the configuration of the tracks due to over-complexity and the fact that the timing pulleys/belts did not meet the recommended minimum configuration of six groves engaged at all times.
Here is a picture of the new configuration which works very well . . .
And HERE is what has been taking my time away from robotics! (I just got it set today. This picture was taken while it was still on its pallet.)
Tomorrow, I am going to the range and download a few rounds. I need to RELAX!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Comments
1. very nice design on the chasis... very professional looking! how are you going to attach the circuit boards?
2. I so freakin jealous!!!!! I hear Grizzly's are very highly regarded... what did something like that set you back?
The mill itself was only $2595.00. However, the basic tooling I bought with it raised the price to $3600. I imagine I will buy an additional thousand to two thousand worth of tooling.
I will set the electronics on top, above the batteries. I mounted the HB-25s this morning in the "rear" with the muffin fans pointed out . . . they look like exhausts. Cool!
Thank you for the compliments.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Your skid steer is looking good.· Guess I should take some pics of my project and post them.
Jim.
Count me in with Steve on being jealous...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Jim, I have been to the Springfield Grizzly showroom twice . . . my Dad (93) lives 27 miles outside of Ava. It is a fantastic place and now that I have a mill I am sure I will be stopping there on the way to Dad's more often!
You SHOULD take some pictures and post them. I stole a lot of my ideas from pictures on this forum.
Whit, thank you. I know from reading your posts that you see all the machining errors and other mistakes I made. Hopefully, the next machine I build will have less due to the fact that I will replace the drill press used as the primary tool to create this one with the mill you may have seen above.
·
The skid-steer is fairly heavy. Each battery weighs 7lbs. The machine as you see it above weighs 15.5lbs. I imagine it will top out at about 17lbs. by the time I mount the two·nickel metal hydride (NiMH?)·4200 maH batteries. This will give me·a total of 8400 maH for the processors and MAYBE a little bit of external electronics. If I power anything else off the NiMH batteries, it will not be much. That way, the multi-processor brains of the skid-steer will live for weeks (months?). I plan to power all other electronics and servos of various kinds from the 12vdc, 24 aH, lead-acid batteries (two batteries; 12 aH each).
When I get my multi-processor bit-signaling concept working the way I want--or I abandon it as one of those great ideas that actually suck in reality--I will design and implement a multi-articulated arm that will fold up and stow itself on top of the machine. At this time, I do not know whether I will implement 'bot to PC communications via Parallax RF or simply stick a tablet PC on the 'bot and let it be part of the wireless network here at home. The tablet PC route SEEMS easiest and the skid-steer has MORE than enough power to lug the tablet PC around. Each of the Banebot gearmotors is rated at 4935 oz-in stall torque at 12vdc. Plus, my timing pulley and belt arrangement multiplies that by 8.75, minus operating friction, of course. At 134 rpm (gearmotor flat out), the gearmotors/timing pulleys will drive the skid-steer at 51 feet per minute.
Pictures when I do the next significant thing! (Well, the Parallax HB-25 "exhausts" are neat looking, but not a big addition to the machine.) Plus, I take jillions of pictures anyway and will make some kind of hoakie web site out of them.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Gee. I guess I can!
Here are three pictures. All are from a "rearward" direction. The top two show my breadboard with five Parallax microcontrollers on it. They are "networked" via a bit-signaling scheme. Currently, the "master" is a BS2p40 because I need all those pins to talk to the slaves. (But, I MAY reduce the number of slaves.)
The slaves are OEM-BS2s, which are very neat. However, I have discovered that I do not need them in the OEM format and would be better off with the modules and simply create a single power supply and one or more RS232 interfaces (you can see one of the RS232 interfaces in the pictures . . . it is connected to the BS2p40).
If I eliminate the OEM BS2s, I will replace them with the far faster BS2px modules (4k instructions per second versus 19k instructions per second). The breadboard is just sitting on top of the frame cross members right now. The HB-25s are simply bolted onto the side frames. It is far from done, but it is rock-solid. When I get it under microcontroller control, I will post a lot more, INCLUDING the mistakes I made, all of which were mechanical . . . to date! (Sucker sure runs well, though. And, it is very powerful.)
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Other than the power regulator and the RS232 interface, I don't know what the OEM Stamps offer me. On the other hand, the modules provide an extremely flat profile. I will try to take a picture of what I mean and post it soon.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Regarding the OEM boards vs. the Stamp modules for my application . . .
The OEM boards are great. However, I would love to have the much faster BS2px modules and I don't think I give up ANYTHING in the process other than no RS232 interface (easy to make and you really only need one) and a power supply. Again, easy to make.
I think you can get the idea I have in mind (low profile) by looking at this picture . . .
This is my current bit-signaling multiprocessor configuration. Bit-signaling works very well and is VERY fast. I am going to at least give it a try. It sure is a cheap way to do incredibly simple, reliable networking while reducing code overhead.
The flat thing in the upper right is a BS2p40. My homebuilt RS232 connector is "interfaced" to it. If I replaced those four OEM BS2 boards on the left with four BS2px modules, the height of my microcontroller board would be reduced dramatically.
I have not made up my mind. Still thinking. Comments MORE than welcome!
Oh, look! Somehow a Parallax HB-25 sneaked into this post!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Is that how you are architecting it?
It is much simpler than you imagine. However, for the "master", it is pin intensive . . . it takes a lot of pins, that is why I am using the BS2p40.
Let's take a simple example;·the advantage of this technique is that ALL examples are simple. Assume we want to control a single motor. What is it that you tell a motor to do, anyway? Forward, reverse, and speed come to mind. (Remember that 0 rpm is also a speed.) So, you need a bit off or on for forward and reverse. That's one bit. If you arbitrarily decide that you will have 16 speeds, including stop (0 rpm), then you need four bits. What I am describing is a 5 bit "instruction set" to completely control a single motor.
For example . . .
10000 (or 00000) would be stop. Who cares if the high order bit represents forward or reverse if you set the rpm to zero?
10001 would be forward (if you made the high order bit the direction bit and 1 represented forward) at speed 1. Speed 1, and all other speeds would simply be arbitrarily determined. My plan is to divide the 250 steps between the HB-25's zero speed (750) and its maximum forward speed (1000) into 15 even increments. The robot will travel forward in one of those 15 speed increments. The same is true for reverse (750 to 500).
Likewise, 11111 would be forward at speed 15. (Forward, flat out.)
The instruction 00001 would be reverse, speed 1 while 01111 would be reverse, speed 15.
Now, how do you implement this using I/O pins? I plan to dedicate five master pins per motor slave. I will set each of these five master pins to represent the command to the motor. Of course, you can't add pins to accumulate the actual command, but you CAN test to see if they are high or low and add a bit to a counter if it is high. The result will represent the actual five bit binary command which can then be easily and quickly executed. CASE statement, perhaps.
The master will set its output pins according to the instruction it desires the slave to execute. The slave will sit in a VERY tight loop, simply looking at the master's output pins. If nothing changes, keep on a'truckin'! (Do nothing.) However, if there is a change, interpret it and execute a single PULSEOUT command to the HB-25.
The advantages are obvious: The motor-slave does absolutely nothing if there is no change. If there is a change, then it needs to interpret the change (one of 32 possibilities) and execute it. This won't take long at all since a CASE statement will determine which command has been sent and a single PULSEOUT will then execute it.
This scheme is far too simple to be called "networking." That is why I have labeled it bit-signaling. Of course, one could devise instructions set commands of both longer and shorter lengths, depending on the number of commands the controlled device required. (I think all·possible instruction sets·a person might design must have fixed length commands, though.)·There are two huge advantages: It is fast and very reliable. If a slave were to SOMEHOW miss the master's command the first time around, then the slave will do nothing and IMMEDIATELY check the master's command again. The master's command will remain static until changed by the master. The slave will ignore every ensuing, unchanged command.
This is a hardware intensive approach. But, it does cut way down on program execution overhead because each slave program is very small. Another advantage is that each slave will have a LOT of I/O pins left over . . . just in case experience proves that additional code can be added to the slave to use the I/O pins for . . . whatever. For example, my current configuration has 66 SPARE I/O pins. Another plus is maximum flexibility. This approach gives you the hardware to implement just about anything because there is no reason that slaves cannot talk to each other and make simple decisions, thereby off-loading the master to do other things.
I do not know if it will work. But, I am sure going to try it.jj (I've had it up and running doing the ABSOLUTE ACID TEST: Blinking an LED!)
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Think about 1 more pin on the master for a buss line using a pullup and connect the slaves to that buss. Keep the line low from the master and release it when data is ready to be read on the parallel line. When a slave receives its data I guess by comparing the input buffer with the previous input data·to see if there is a new command it can respond to the master by pulling the buss low, when the master gets that message it can again pull the buss low and process more information. that way it knows the data is being received and wont spin in circles if one of the slaves does not respond. Using 2 buss lines you could directly address one of the three slaves, that would allow you to send the same data just to check and see if the slave will respond, with one buss you can't just check a slave unless you send it a different command than it had the previous time.
I guess I would really think about using 4 buss lines and send a packet of three nibbles, nibble 1 addresses the slave, nibble 2 is speed 0..15, and nibble three is direction and 14 other possible commands. Your slaves then all see the·first nibble and if not addressed to them skip the next·3 nibbles, yes , I said the next 3 because the slave responds to the masters 3·nibble packet with a nibble of its own allowing 15 status messages from the slave.
Looks like a fun project, ahh geese i was having so much fun tonight its after 5am now.. geesh
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think Inside the box first and if that doesn't work..
Re-arrange what's inside the box then...
Think outside the BOX!
Thank you for the advice. It may well be that my scheme will involve some unknown-to-me problems and I will have to implement a more traditional approach, such as what you propose. We'll find out and in the meantime have a lot of fun!
There are several different networking approaches that should work. All involve some overhead. I only THINK mine involves the least overhead. Perhaps it does. Perhaps it does not. I intend to have one entire slave dedicated to watching either one or two 128 CPR encoders. I do not want miss a bit. This is an example, though, of where the hardware available and the minimal software necessary combine to produce MORE overhead. If one slave monitors only the encoder on the left gearmotor and another slave monitors the encoder on the right gearmotor, then there must be some way for them to compare results. Do they do that slave-to-slave or slave-to-master then the master makes a decision and signals the appropriate slave controlling an HB-25? Either way, it is obvious that there may be more total code involved, albiet spread over multiple processors, than if a single slave was used to watch BOTH encoders and had enough intelligence to know when the error range had been exceeded. It could THEN signal the master.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Anyway, cool project, I cant wait to see what happens.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--DFaust
I am having the same thoughts as you. Truthfully, I will try it both ways. I have plenty of hardware to let me do it any way I wish. I want to try the bit-signaling idea. If it proves worthy, I will cut it down to where it REALLY makes sense and do the rest in a more traditional manner.
My main goal is not to miss any inputs. If I did EVERYTHING I want to do with, say, the 19kips BS2px and used shift registers to expand the inputs, it is very possible I might miss a bit. Maybe not, too . . . and I will try exactly that! I am playing this game to learn and you guys have taught me a lot.
I put in several hours on the skid-steer today; mounted the breadboard, wired everything, mounted the batteries for the Stamps, wired the HB-25s (they look and sound neat when I power up the 12vdc system!) and some other stuff. I used screw terminal strips for 12vdc·power distribution. I put one strip on the left and one on the right and labeled them POSITIVE and NEGATIVE!!! (Wonder if I can still screw up? Probably.)
I think it is ready for me to cut some code. I will test using a single BS2. If nothing smokes, then I will begin code design in ernest.
My wife wants me to put a fully articulated arm and gripper on it so, of course, I will! And, I want to mount a wireless tablet PC on it for obvious reasons.
I have had it running without Stamp control. It is neat and powerful. Those tracks REALLY like the carpet.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--DFaust