I did SPI on the ARM7, and it’s written for the 4620, but not tested.
A simple walker with available code, no sensors, no Subsumption, or other more advanced architecture.
Yeah, I’d like to see it work on all of 'em.
I saw the changes. I also did a quick compile on the code, and was reminded that it’s written with the Microchip conventions, so it’ll take a little work. Only code for one end? any headers?
Probably true. Certainly makes things easier.
I think I’d rather have the RS-232 version. That way I can use it immediately on other projects. But it’ll have to wait; I have other 'Bot parts to buy first.
That’s what I meant! I’m trying to decide what the weight vs. legs ratios come out for an octapod. Seems to me, more legs, the body/battery/electronics becomes a smaller proportion the the total weight, so it should IMPROVE. I intend to weigh the legs, etc, and then I can add an appropriate weight to a hexapod 'bot, and see how it does with it. The gait is something else. Apparently not just a terapod gait, but more “dwell” of the legs on the floor. But that’s all later.
Still not what I’m thinking! These bipods walk too funny. The bearing part will do it for me. What, only 10 servos to go? What’s the hold up? Oh yeah, credit card…
That interesting. I want some rangefinders, although I was thinking of ultrasonics.
How about the 4620?
Hard to see it. I’ve done 4550 CNC controller board, but not 4 uPs. I’ll wait to see your layout!
Since you already have the code written for a 4620, and I need the SPI stuff now, I could be your tester. When I am done, I want to have full master/slave code for I2C and SPI. I only have to test the I2C slave code for PICs now, and have it setup for a 40 pin (4550) and a 28 pin (2860) PIC now.
So a simple walker could not be autonomous then? If it is just reactive, versus proactive, I think it could still qualify as simple.
I’ve completed porting of all the slave I2C code from the dsPIC to PIC now, so testing is in order. I just got done stuffing the last of the code into a 2680 project, and already have it in a 4550 project. I renamed the checksum variable in the i2c routines to i2c_checksum, because I will have a similar variable in the spi stuff called spi_checksum. I renamed a few of the I2C routines to add the “i2c_” prefix to the name so they would not collide with similar routines in the spi name space. Everything compiles clean now, so we will see if it actually works soon. I still have to choose the pins for the 3 address jumpers for the 2680 and 4550, and test the code to read them and create the I2C address from that and the I2C base address. That code is mostly done now though.
The code is still in a little bit of flux right now. I am still shuffling some stuff between files to get everything unique to the I2C stuff together. When I get all that done and it compiles and works, I will release the files to you. There are still a few things I need to get out of the main line and into the pic_i2c files. I want to get rid of as many global variables as I can too.
I want to follow the convention of having 3 address lines available to select the device address for PICs and dsPICs. Hopefully I can end up with code to handle all the peripherals of a given chip with a project for each common chip (2620/4620, 2550/4550, 2680/4680, 2685/4685, dsPIC4012, dsPIC4011, dsPIC4013, etc. From that set, it should not be hard to create a project for any other PIC or dsPIC, since mostly it’s just more or less of the same peripherals. I should be able to scale up to something like say, an 18F87J50, pretty easily.
Having an RS-232 module that you could put right on the serial port of an Atom Bot Board or a serial port on any other microcontroller board would definitely be nice.
That’s it, for sure. I can only focus my dollars on one thing at a time, and right now I am focusing on learning more about PICs and dsPICs. I have noticed something as I look at datasheets for various microcontrollers - Microchip seems to be the only company that multiplexed the I2C lines with the SPI lines. I have not found any others that have that setup so far, but there may be some.
I like to pair an ultrasonic ranger with an IR ranger because what one does not see, the other almost always will see. Each reacts best to different types of materials and surfaces.
I don’t have an Eagle symbol for a 4620 yet. I think I am going to have to make one. I need to complete that Eagle tutorial on making symbols and see what symbols Spark Fun has in their Eagle library.
I am going to stick to a dualPIC design for my first Eagle schematic. After I complete that to our satisfaction, I will work on a quadPIC design. I want to retain most of Pete’s original design, especially stuff like the charging circuit. There are only a couple design changes that need to be made to accomodate a 4550 in place of the original 4620/4680 master.
I had a good SPI waveform on the 'scope, with the proper timing. I was going to try the PS2 on it, but I didn’t want to have to wire another connector on that 'Bot board (maybe one of the others).
Sure! I’ll send it to you. I’ve only got the “master” end of SPI, by the way. So the code you posted is “master” as well? Actually, I don’t believe I’ve ever written the “slave” side. I like to be in control… ;>)
Did any of my emails get through?
Probably, but without sensors, it’ll be BLIND, and probably not very reactive! I’m all for autonomous 'Bots, but I want to explore gaits first. That may take a little while. But, you’re right; getting it out of the “R/C toy” category is a priority.
You’ve been busy! I think all I did was run the mill this weekend, and think about how I was going to machine a plate to take my uP board on the 'Bot. The design is still a little too big to machine, even if I do it in two setups (reverse 180). But I can quickly draw them with my CAD/CAM program, so I can try more then one. They take a LOT of expensive 1/8" aluminum plate $$!
Remember to use #defines for the pin names, and then some simple abstraction will allow the functions to be fully portable. The checksum variables can probably be kept private. Do you have header files for your modules yet?
OK, you’re already at work on header files and such! I thought you might be. These modules will be very valuable to you later (and us). I go through a similar “cleanup” phase when I develop, at first, I just tuck the code in somewhere, but later I try to “get it together”. Please DO get rid of any unnecessary GLOBALS.
[rant] Globals are of my main objections to BASIC. F(x) rules! Too much in a “main” routine makes code hard to follow. [/rant]
Yes, I think you’re right. I can actually use the same set of files, and compile them under two different MPLAB IDE projects (at two different sites) and automatically generate code for three different processors (and two different demo boards).
But that’ll have to wait for me. So much to buy, so little cash…
'Guess they figured we’d use one or the other.
Yes, that’s a good idea. What work have you done with your sensors?
I’ve made a symbol or two, and I STILL have to go back and try to learn it again. For some reason, that area of Eagle is not very intuitive.
That sounds like a plan! The 4550 is easy enough to design for. Mind the USB connector! And you might consider making the board “dual power”, able to run off of either USB or an on-board power supply (regulator).
I’m not sure I like the idea of a battery charger on THIS board. In fact, I think we need to evaluate the whole power distribution scheme. Running uP power off of the motor supply was always a no-no in other designs. I think if one still wants to tap off of the motor supply, then some sort of filter should be in the line to the uP board(s).
Actually, I have I2C master and slave code now for PICs, but have not tested the slave code yet. I just finished and tested the code to read the 3 address jumpers and create a valid I2C address out of that (low nybble) and a base address (high nybble).
I already use defines for any pins I assign to specific uses, and Pete had done that to a certain extent in his code already. I am just adding to that and have split the I/O configuration stuff into a separate dspic_ioconfig.h or pic_ioconfig.h file to make these defines easier to find and change. It also makes it very easy to change the pin definitions for different dsPIC/PIC chips or requirements of specific applications.
I did a LOT of code reorganization last night and early this morning (until 2:30 AM). I renamed some of the I2C routines to add an i2c_ prefix to them. This will prevent conflict with other bus type I/O routines like those for SPI and CAN. I will add similar prefixes to SPI and CAN routines.
I could use defines for things such as PIC28, PIC40, dsPIC28, and dsPIC40 to allow easy compilation of a single codebase for any of these types. I am not currently doing this though and have two separate code sets for 28 pin and 40 pin PIC/dsPIC, which means four separate code sets at present. This is getting difficult to manage, so I will start adding defines to differentiate between PIC28/PIC40 and dsPIC28/dsPIC40 since the 40 pin and larger chips have more peripherals.
I think Microchip made a bad decision to multiplex bus related pins together.
So far I have worked with the Sharp IR rangers, the IRPD, and a bit with the PING ultrasonic sensor. I also added code to read a compass module, but I ran out of program memory on my Basic Atom. I was in the process of converting everything to run on an Atom PRO when I ran into software issues. That’s when I decided to move away from the Atoms and start learning to use PICs and dsPICs where I have more control of everything.
I started out with just an IRPD on WALTER, and for quite awhile that is the only sensor he had. I wrote what I think are some very good behaviors using the IRPD. WALTER would rotate his whole body when he needed to check different directions to find a clear path, which used his scanning behavior. That was later replaced with a top mounted sensor turret that had Sharp IR and PING untrasonic sensors. I also added two other Sharp IR rangers at 45 - 60 degrees either side of WALTER’s front center point to handle blind spots around the center and wheels. WALTER still has problems dealing with low floor objects, even after I redesigned the sensor turret and mounted it right at his front center point. I have not really played with this new placement too much yet, which will allow WALTER to see low floor objects between 60 and -60 degrees from center and raise and lower the senors to see up 90 degrees and down far enough to see the floor.
I have heard there is a new version of Eagle coming out soon, and I hope this is one of the areas they address. I think it is way too hard to create new symbols, and it appears each needs to be created from scratch even if there is a similar symbol available to start with. I need to investigate this further, because a lot of PICs/dsPICs are very similar.
I am planning to use the mini style USB connector to save space. Dual power is already on my radar.
I never run my electronics off the same supply as the motors or servos. That is just a bad idea. We need to have a way to get power to off board components too. There is an article (I think in Nuts and Volts) that deals with power distribution that I need to time to reread and pay more attention to. The article actually uses a separate power board to distribute power to components from. It also can be used to provide different voltages needed by various components.
I sent an email with snips of SPI code. No proper module, or header files, but the bits when added should generate output.
I thought I had a slave from Pete’s files, but maybe not (Pic_i2c.c).
SSPCON1 = 0x08; // I2C Master Mode
Sounds like you’re on the right track.
I briefly tried PBP that we bought for some production test code, but it didn’t have all the variable types I wanted.
It would be interesting to see that work! My first robot just had simple “bump” sensors. I modified a 5K BASIC for the 8085 (written in assembly language) to handle some simple turn and move commands for a two-wheeled (+ tail wheel) box robot powered by stepper motors.
Really! They should have send me update information! I did manage to copy and modify a few symbols, but as you’ve said, it’s very difficult. I do like the PCB-GCODE app that will run with Eagle; it lets me mill PCBs on my Sherline mill!
I’ve seen 'em. They would save some space, but I’m currently using the OLD cables, which I’ve got a LOT of.
That’s wise. I haven’t seen the article, sounds useful. Wouldn’t be hard to come up with.
I am not getting e-mails from you for some reason. Try sending to [email protected] now. That site is with a different hoster.
Those are the files with the I2C stuff. I think I am almost ready to release my versions of Pete’s I2C files - significant renaming of routines, plus my own modification. Speaking of I2C, I can jumper the 4550 for Master or Slave operation now, and do processing based on which mode it is in. Now to test the slave code… When this works, it will be VERY exciting! I even have an LED that shows Master/Slave mode, but I think I will change it to be ON for Master mode since this is the default with no jumper installed.
I have some videos of WALTER in his early months up to the time I had the top mounted sensor turret on him. They are on YouTube. There are links to the videos in the WALTER thread of the Rovers sections.
I checked the CadSoft site today and there is no mention of a new version. I have a hard time making myself go fiddle with Eagle. It literally makes my head hurt to use it.
The article is very good, and I can learn much about power distribution on a robot from it.
It might come from [email protected], I forget which agent I sent it with. That could be a problem. I’ll copy this message to you.
Good! Maybe I can get my boards talking! I reworked the file, and got it to compile, not too much of a problem. You can jumper the same file and do either master or slave? That’s the way to do it!
I was looking in a quad/rover thread, and the immages were broken. And a youtube search for WALTER didn’t work too good.
I think my power distribution for the CH3-R shouldn’t be too hard. I’m planning on adding a charging connection.
Yes, I can jumper the 4550 to be either master or slave, with master being the default if there is no jumper installed. As soon as I get the dsPIC4011 outfitted with the jumpering code, I can start to test the 4550’s slave code. I have a 2680 on the breadboard in a different circuit talking to a dsPIC4012 running a slightly cut down version of Pete’s regular dsPIC code. When I get the 4011 setup with the new addressing scheme, I’ll connect the I2C bus of both circuits and see if the 2680 can talk to the 4550, 4011, 4012, and MCP23017. That should be a pretty good testbed for the new code.
Here are links to some of the early videos of WALTER, before his name changed. Early info on him is in the Octabot thread in Rovers.
I’d be most interested in slave/master routines to communicate between two or more 4620 family chips. I’m assuming you’ll have ALL of them connected up together, and write some sort of a test/demo? If I wasn’t tied up with mill work (I’ve got a too-large body plate to work out and cut), I’d see about making up a proto board for one of the dsPIC chips.
Thanks for the new URLs. I can’t access them from this computer, but probably late tonight.
Guess I’ll need to get some sort of video camera (my Sony is too old), and after my CH3-R bot is together get some footage of it. What are you using?
Right now, I am concentrating on getting the 2680 (Master) talking to the 4550 (Slave). I seem to have some problems with my 4550 I2C interrupt routine, which is not surprising. I ported the interrupt code from Pete’s dsPIC interrupt routine. I’ll have my RS-232 level shifter tomorrow, so will be able to use printf() to see what’s going on then. I’ll see if I can get inside the 4550 with my ICD2 also.
I’m just using a $49.95 Logitech Quickcam Messenger webcam right now. The video isn’t as clear as I would like, but it is enough to see what is happening.
I should think the same code would work for most of the 18F PIC chips we’re interested in. They should all be using the same registers, and internal hardware. The dsPIC is probably different. What have you seen for differences so far?
The 18F parts have two levels of interrupt, and a LOT of stuff to set up to use them. I’ve done it on my projects, but I haven’t looked at any I2C specific interrupt details.
I’m using some little CompSys dongles for level-shifting when I debug on my ARM7 board.
I have the Olimex ICD2. It works great, and programs both PICs (including the 18F87J50) and dsPICs. I have not used the debugging features much yet though, but that is changing since I have to debug my I2C interrupt handler on the 4550.
The registers are very different between the PIC and dsPIC. I had to change ALL the register references in the interrupt code I ported from the dsPIC to the PIC. I am not sure the code translates between the two 100% though, and there may be other differences I need to account for in the PIC version of the code.
As far as interrupts go, I think the dsPIC and PIC are the same in that they both seem to have two levels (high and low). I have not had any problems moving code between 18FPIC chips or between 30FdsPIC chips so far.
I need a TTL to RS-232 level shifter I can use on my breadboard, which I will have tomorrow. I am getting much better response from the 2680 and 4550 on the I2C bus now. At least the heartbeat LEDs of both chips are blinking properly. Now I can work at getting them to communicate with the I2C loopback test and go from there once that is working.
Speaking of ARM, I seem to have bricked my LPC2148 header board. I am hoping I can recover it once I get my RS-232 level shifter and can connect to a real serial port on the board. Maybe I can reflash it with the LPC2000 flash utility.
That’s what I guessed. The ad I read only mentioned 16F parts, so I wasn’t sure. My friend with the 'Bot could use it.
Funny, I wouldn’t think they would be. Still better then some other chips I’ve worked with.
Are you using both levels of interrupts? I remember they had a very complex tree of interrupts for the 18F
Just a Max232 chip would work for you then. What’s in your loopback test?
Yeah, you were saying that. Re-programming might do it. It’s hard to fry these parts!
You’ve done Alibre CAD drawings of parts; can you export simple DXF files? I have Alibre, but the last time I tried to look at bracket, it corrupted something terrible, and wouldn’t work for me at all. I really want to see if I can use a smaller body then the 10.5" bolt circle (servo shafts) of the CH3-R (3DOF-C legs). I have CAD/CAM, in designing my model steam engines I was able to draw wire frame parts, and use that to determine what clearances and fits were like. Maybe somebody has already done that!
I highly recommed the Olimex ICD2! I do not regret spending the extra dollars to get it verses one of the less expensive programmers. I keep reading about a lot of problems people have with the less expensive units, and I just don’t need that pain.
I think a completely different group of people created the PIC and dsPIC parts families. It would have been nice if somebody would have set down some naming conventions for registers and such so it would be easier to tell which registers of a PIC and dsPIC do the same function.
There are only two interrupt levels - HIGH and LOW, with respective handlers you have to define for each. I am only using the LOW interrupt handler at present. I am fortunate that Pete stubbed out the HIGH interrupt handler and all I have to do is flag a particular interrupt for HIGH level and put the code into the handler. Pete’s code is already configured to easily be able to use both levels.
Yes, a MAX232 would work, and I have several. However, I don’t have the right cabling/connector to connect to a PC serial port. I need a female DB9 and the only cables with connectors I have are male. I need one of those cables that were used on older motherboards to connect from the board to the back of the PC. I could just stuff the ends of jumper wires into the connector on the motherboard side of the cable.
I never saw any magic smoke escape and didn’t hear any crackling noises coming from the header board, so I am hoping I can just reflash it and make it usable again. I really want to work with the LPC2148 chip - it’s an awesome chip with a great set of hardware, including 512K of flash, 42K of RAM, TWO I2C and TWO SPI ports, as well as TWO UARTS and some ADCs. I think the LPC3248 would make an awesome master controller for a robot… I wish Spark Fun would get more of the LPC2148 proto boards in stock, because I WANT ONE.
I have all of the SES brackets in Alibre format already. I can send you a ZIP of them if you want, but it is rather large. Be sure to upgrade to v10.0 of Alibre. There should be a 10.0 XPress version available now, because I just got two version 10 CDs in a mailer that says “Please share these.”
It is so nice to be able to design using full 3D in Alibre. I could never go back to doing 2D CAD again. I just got my Alibre Design Expert all paid for too! You can purchase the unlimited versions of Alibre Design on a monthly payment plan direct from Alibre. They just take it off your credit/debit card every month until it is paid for in full. I am even getting into designing custom SES compatible brackets now, and have several designs. Unfortunately, I don’t have the ability to actually make them.
Watch my WALTER thread in Rovers for updates on him and new things being added…
Saw WALTER! Interesting little 'bot. So you say you bought it initially as a kit? That’s a nice size. I should post pix of mine. If I can find all the parts. I designed and built an arm also.
That is true. It can be a job finding the right enable and such for an interrupt you want to use. It’s pretty well laid out in the datasheets though.
Do you have any of those motherboard to DB9 female cables you want to get rid of? I could sure use one or two if you want to donate them to me.
I would think the LPC2148 would not be pin compatble with your ARM chips. They are from different companies. I think either company would be telling everyone if their chips are pin compatible with any others.
I can’t afford to get any of the LM robot kits. I would love to be able to build a CH3-R, but would be more likely to wait for the new Phoenix kit now. However. I would still like to have a CH3-R. It would take me 3 or 4 months to get the money to buy a CH3-R. All of my Alibre 3D models should be available on the LM site now. I have a couple of new ones, but I have to solve some alignment problems. They are for the GHM-04 motor and a new bracket that isn’t yet available.
Would you be interested in trying to make one or two of my bracket from the Alibre 3D models? The brackets I have designed are motor mounts for the GHM-04 and similar motors.
All the answers are in my Octabot or WALTER threads. Short answer is yes, I started out with a stock kit that used continuous rotation servos. Now, the only parts from that kit are the decks and the front caster. I’ve even changed the standoffs to get more clearance between decks.
To get back on topic, I have been fiddling with the interrupt routine for the PIC that I ported from the dsPIC. I still can’t get a connection between the 2680 (master) and 4550 (slave) though. In fact. right now I can only get the 2680 to talk to the MPC23017. There is something wrong with the new code I added to the dsPICs (4011 and 4012). I have 2 PICs, 2 dsPICs, and an MCP23017 I can tie together on the I2C bus once all the I2C code is working for all of them. I can jumper both the 4550 and 2680 for master or slave mode now. I got the switch code working on the 2680 finally. I should look into putting all this stuff into CVS, and I do have a Source Forge account.
Now that I have WALTER operational again, I am more anxious to get some PIC code to control him in place of the Basic Atom (1K program memory free). I need something with more memory. That OOBOT board is looking more attractive every day.
The data sheets are good. That’s what draws me to a company, the documentation.
Actually, I never get rid of anything! I can probably find a few. They ARE quite useful.
Nah, I wasn’t expecting them to be compatible, although there is apparently some level of compatibility at the “ARM7” level. Not sure what all that is yet.
Yes, it’s taking ME 3 or 4 months to buy all the hardware for a CH3-R as well. Doesn’t look so bad to the wife this way either!
Yes, the Phoenix IS interesting! Zenta has certainly designed a nice 'Bot. I’m anxious to see how it gets implemented into an SES robot. Or maybe it’s only going to be a kit? I’m not sure what the distinction is. I tend not to need “kits”, especially if I’m already familiar with components of the kit. I enjoy designing and making my own.
Yes, I could probably make you a few brackets for your 'Bot. I will have to get my Alibre updated as I mentioned earlier. In order to generate Gcode to mill the parts, the 2D CAD drawings have to be imported into my CAD/CAM program (Vector CAD/CAM), where I can do the offsets for tool path, and the canned cycles for drilling. As these are most likely sheet metal parts, then basically all that is needed is a single view. Remember to add the bend allowances. Can Alibre do that? I’m not a sheet metal man, but I have done some sheet metal projects in the past. Certainly no harder then milling parts for my steam engines!
It’s nice that kits are available now; not everyone has access to a machine shop and a computer lab. The best part is probably the EXCHANGE of ideas and sharing of knowledge!
Oh yeah, the topic thing. Will it work the other way 'round? 4550 slave, 2680 master? I find simple examples of I2C to EEPROM communications (I think I wrote one for an Atmel or was it Motorola EEPROM in the past). But no uP to uP communications! Which means no SLAVE examples.
I’m not really crazy about CVS, after working with Source Safe, PVCS, and other revision control systems in the past. I DO have to use it occasionally to exchange files with a consultant we have. Always seems to work backwards to me; maybe that’s a Linux thing! ;>)
Finally saw your WALTER movies, he gets around! I need a new video camera! The BASIC Atom belongs on your CH3-R!
Alan KM6VV
P.S. tell me if you don’t get another email today.
I’d really like to get a couple of those motherboard to DB9 female cables from you if you can spare them. I used to have a box of cables that allowed me to almost connect anything to anything, because I don’t toss cables either. Somewhere down the line, that box got lost.
The would be software compatible at the ARM7 core level if they are both ARM7, and the same sub/super set of the ARM7 spec. I am guessing that says what minimum hardware the chip has, register definitions, etc.
That’s the way to do it! Sneak in small orders under the radar. I would have to get CH3-R parts the same way, but for different reasons. That’s how I got all the brackets for The BiPod, which still needs servos (10 HS-645MG for the legs, and 2 HS-475HB for the pan/tilt turret). WALTER needs a new body too, which I have designed, but have no way to cut. I have the materials to make 4 new decks.
I am guessing the legs will be machined like those for the CHR-3, but just a different style. If Jim stays with how he has been doing things, he will make the legs (pair) available as a separate kit, and the body parts as separate components. He usually makes all the parts of each kit available separately as well, in various forms.
All my designs are done in 3D, not the sheet metal style. I would like to have them done in the same type of aluminum the SES brackets are made from. My first custom bracket designs are SES compatible motor mounts in 6 different styles. As far as I can see, I have the right dimensions of the SES holes, but am not completely sure I have the hole spacing right. I made my bracket designs to line up with the current set of SES 3D models, and that may not reflect reality.
Yes, the community here is wonderful! When I was originally planning to build a BRAT, I got my parts list from the assembly guide and just bought the brackets as I could afford them. Then I decided to go custom because I am curious about a different kind of biped leg. Hence, The BiPod was born!
I found some I2C slave code examples written in a dialect of BASIC for another microcontroller. I am in the process of converting that code to C now. I have converted the slave initialization routine and am about to look at the interrupt handler.
I think I would rather use SVN, but I don’t know of any site like Source Forge who hosts SVN repositories. Actually, I need to take a closer look at Source Forge, because they have been adding a lot of new stuff lately.
I keep having to slow WALTER down, because he is so fast there isn’t time to react to a sensor detection before he runs into what he detected. I am going to have to extend his detection distances and/or slow him down some more. He keeps trying to climb the walls!
Sure, I’ll have to check. I’ve probably lost more computer parts then I can count.
I think so. At the time the project was started, that wasn’t a major concern. I have the ARM books, all I have to do is read, read, read!
You need a lot! I don’t have any HS-645MG servos yet, maybe I should make the next batch '645? Which joint of a hexapod needs or can use the most torque? Probably NOT the Horizontal Hip. Vertical? Knee??
Another trick is to get them as birthday gifts. My wife is very helpful in that regard. Trouble is, it’s a L-O-N-G time between birthdays (and maybe Christmas). Even Christmas is a long ways off!
What’s the trick cutting ot a body for WALTER? It’s a large Octagonal sheet, right? I think I saw it. A bandsaw works great!
That’s what I suspect. That might make for some interesting combinations. I believe the Phoenix is considerably smaller.
No sheet metal? Maybe it’s SolidWorks I’m thinking of. At any rate, I need fully dimensioned drawings in order to make a part. I did work out some hole patterns for servo horns, probably not what you want. What SES holes are there? What does this bracket mate up to? I probably haven’t seen it.
You’ll need to get out your dial calipers, and do a little measuring. You can make a paper (thin cardboard) template of your part, and try it out.
Doesn’t Alibre export DXF? I tired to import DXF, but didn’t get anywhere with it. I wanted to view some of my steam engine parts in rendered 3D.
brackets are 5052 H32 1/4 hard, tubes are 6061 I think somebody said.
Still a little different then my yahoo lists.
Yeah, I saw the BiPod. Didn’t understand it! I was looking for a rotating (shoulder?) joint.
Ugh! I wonder how close they’ll be! Have you seen a transaction flow chart or something like that for the I2C protocol?
That could get ugly! Keep him off the walls! Slow is probably better, and cheaper in the case of mistakes! Like your driver-ed class instructor told you, don’t out-drive your headlights!
When I am done, I want to have full master/slave code for I2C and SPI. I only have to test the I2C slave code for PICs now, and have it setup for a 40 pin (4550) and a 28 pin (2860) PIC now.
Try sending to 
Short answer is yes, I started out with a stock kit that used continuous rotation servos. Now, the only parts from that kit are the decks and the front caster. I’ve even changed the standoffs to get more clearance between decks.