Well I turned on a huge tangent that left this project on idle for quite some time. After the Beagle folks released the new Beagle Bone Black it became apparent to me which single board computer would form the basis of my robot. The I/O capability of the BB Black just crushes the Raspberry in this role I think and I obtained a couple to play with. There is already some power management hardware on the board as well as the capability to have 3 or 4 UARTs and 2 I2C buses. The problem is the new Linux kernel has been deemed by the gods of the kernel world to need entirely new ways of handling GPIO and has broken nearly every tutorial dealing with GPIO on the Beagle Bone. So I'm slogging through with everyone else figuring out the best way to configure GPIO on boot and access it from user-space. I have written some C++ code to work with GPIO on the file system but it is stuck for now with only accessing the pins as they are configured from outside the program. It can't reallocate the pinmux on the fly and deals only with straight-up GPIO. Plan to work on getting sensors tied to a Propeller that will be controlled and queried via serial. Some of my I2C work will certainly port over to this platform as well. I'm waiting to see if the power management features are more fully implemented as that will be an easy place to tie in to control robot power in general.
I have been tweaking some design aspects and one was the interior space for the lower level that should house the main control boards and motor drivers. I liked the low profile design but it was getting really tight on horizontal space and vertical space was pretty cramped as well. I decided to increase the height of the lower level but that meant I would have to scale up the sonar sensor stands. While I was at it I figured I could make them a little more simple and make them from 1/4" AL angle rather than bolt on separate legs. This is one of those times when something seems cool on paper until it comes time to put endmill to metal. This design proved tricky to fixture in a way that was solid. I wanted to be able to make more than one per run. In the end I had to cut about 6 new parts to support making 4 sensor stands. While the new one-piece design is very solid it would have been easier to make as a two-piece project. The new stands are 2.75" tall and include tapped 4-40 holes to make it easier to secure instead of trying to tighten nuts in cramped space. Because of the angled sides on the front of the bot it will require a custom hole to be drilled in the robot base platform for each of the side-sonar stands. The non-45 degree angle of the nose was a foolish design choice I just have to live with. I have decided on a hornet color-scheme with black and yellow powder-coat for most of the design.
I'll also be making a new design for the drive mounts. The new plate will include both the front and rear wheels and allow me to enclose the underside of the bot. While the clearance is nice, routing wire under there is getting to be a snag problem. I may go with black acetal plastic for the underside plates so I'm not ramming AL into ground obstructions.
Good to hear from you again! I'm glad the project is still on- going, I like these larger projects that require a lot of design work and patience . What are the specs on the new board for IO and ADC? I'm getting close to finishing up my mechanicals and will be shifting to electronics and programming soon, so new stuff out there is always looked at closely.
Bob
Thanks Bob, I've been working up the parts needed to close the lower level. Once I have that, then I'll focus on getting the new drive mounts. Then I guess I need to get back to programming to populate the lower level with the new motor drivers and controller board. Plan to make a cape design for the Beagle that includes the Propeller and maybe some modular designs of my own so I can plug in shift registers, RTC, or ADC / etc as needed.
BeagleBoard.org has full specs but IIRC it's something like 45+ GPIO and 6 ADC. Of course a lot depends on if you want all the hardware backed I/O like UARTS, and I2C or if you want more GPIO and don't care about those. All that is setup in the pinmux settings when Linux boots. The ADC is 1.3V though so noise spikes just got a lot bigger but I guess noise is always a serious concern with an ADC. If you do not use the HDMI interface then you have a lot of GPIO opened up right there.
Sometimes the side-quests are as much fun as the main project. So anyone that spends much time in the CNC mill world learns of Mitee-Bite clamps, thinks "That's cool, where do I get those" followed shortly after by "They want me to pay WHAT"! I went through something similar lately when I investigated Pittbull clamps for making some of my repeated parts. Cool little clamp that just needs a trench to sit in and a tapped hole to apply the clamping pressure. They are like $50 bucks though for a small set of them and I just can't bring myself to pay that. Anyway, spent the weekend working out both how they work and how to make some. Net result is that for $1.00 in scrap steel and $6.00 of ACE hardware screws and bits I have made them for myself. The biggest issue is parting them off of the footing left from the initial profile operation. This is only my second real attempt to make anything in steel on the CNC. Went well I think but I need to allow more roughing clearance on the radius portions. It's amazing the amount of flex that a HSS cutter can encounter in a full slot cut.
I had to make a special set of clamps to hold the angled surfaces for the last operation of parting them off the footing. Should be no problem now to knock out more of them and scale up for bigger clamps with more grip.
Got the new sonar stands mounted on the bot today. You can see the original size sitting on top. This gives me much more room on the lower level now. I'm working on the design for the solid front/back wheel mounts now. If I can then enclose that area, then I have even more room for the power distribution underneath. I note that in my absence from programming on the Beagle Board Black that others are starting to get the memory mapped I/O working again and getting better at setting up device tree overlays. By the time I come back to writing code the major hurdles may already be cleared!
Made another round of clamps for the upcoming job to make that large wheel mount plate. Here's some neat photo's that process. When you machine a lot of aluminum, working on hogging out steel feels like watching paint dry though, 15 to 25+ Inches per minute drops to 3 to 5 IPM chewing through a deep cut in steel.
Roughing the profiles:
Finish after a clean-up pass with 1/4" carbide endmill:
Ready to add the slotted holes for the 8-32 screws in the tops:
So I have 11 clamps now, over $130.00 worth if I had to buy them. I got to spend that money on these beauties instead. $200 for 10 TTS-style ER25 collet chucks delivered from China to my door in 5 days. All but 2 have under 2.5 ten thousandths of an inch of runout. $20 a pop... not bad at all.
These will be the side-wall attachments. They will clamp to the support pillars that hold up the upper deck and present a face that can be screwed into to attach the side-walls. A horizontal 4-40 screw clamps it to the pillar.
So I free'd the clamps from their footings and finished the stand-offs to size. The little clamps work nicely and secure to the aluminum stand-offs quite well. After I finished those I've gone back to a little more work on the BeagleBone Black. Such a neat bit of hardware but man getting down to the brass-tacks of managing I/O is a bit of a chore that is not enhanced when the distro goes and changes things again. Now anyway I have a large experiment board created with a Propeller SpinSocket board, 2 sonar sensors, 2 IR motion sensors, I2C IMU, 4 IR Prox sensors, some LEDs and buttons, as well as two SPI stepper controllers. I think this will give me a nice test-bed to start working on getting the BBB working as a controller for the ProwlerBot.
One large hurdle is cleared. I was able to activate all the available serial UARTs (4) and the SPI bus on the BBB using device tree overlays that are automatically inserted and configured at boot time. I have been able to confirm working serial communications to the Propeller. I've been able to get it to boot up into a condition where I can simply echo text to the serial device and it will arrive at the propeller at 115200bps. This makes testing early code for the Propeller command parsing simple. Now I need to work out how I want to go about sampling the simple sensors like the IR prox and motion sensors and get into the world of pThreads. Luckily one soul already wrote a nice c++ interface to MMAPed GPIO so that's one less task off my plate to get there. I am trying to get an understanding of linux gpio_keys so I can have the kernel monitor for events on lines that need to act like interrupts. I have starter code from the Raspberry for the SPI stepper controllers and the I2C IMU so I should be able to adapt those pretty quickly (relatively speaking for my glacial pace on this).
The major outline of the one-piece wheel mounts is done with just a few details left to work out. I hope to correct a few access issues I had with the previous design where the belts made it hard to get to some screws, I'm also working on giving the rear wheel some shock absorption. Right now those rear wheels are loud and the largest sources of heavy vibration and shock when the bot crosses over small bumps. I'm hoping this simple vertical spring system helps with that some.
Big project on the mill is a 1" thick x 18" long x 8" wide tooling plate I'm working on making from flat-bar. Should make certain projects like the deck floors and wheel mounts easier to do. Right now I am taping 117 holes for 3/8-16 thread (less than fun). Next is the really critical part where I drill and ream 120+ holes for 1/4" dowel pins for a positioning grid. Those need to be as close to perfect as I can muster. Flat bar is not ideal for this but I got a chunk of it and I imagine it will work well enough for my needs.
Big step forward this week. I was able to get the framework put together for a dispatching serial parser on the prop. Using Jazzed SpinSocket design I have connected a couple of test sonar sensors to the prop and hooked the prop up to one of the UARTS on the BBB. I was able to get it to parse out a command to read a sensor, perform the read, and return the result over the serial line. Nothing earth shattering, but I have been working on a framework in C++ to make it possible to take any number of different types of Sonar Sensor and hook them into the code with no real changes to the upper-level systems. My current class will handle one or two pin sensors and I will try adding in I2C type sensors as well. The other sub-systems I see using this arrangement are servos and possibly the stepper controller interface as well. The SPI drivers on the BBB seem to have some ongoing issues.
The images attached show the sequence:
Command: [SN:R:S:1]
Ranging
Acknowledgment: A
Result: [222]
Been working on cleaning up the test code into something useful. The new Simple Libraries definitely make smaller tasks a lot easier now with things like pulse_in and pulse_out implemented nicely so you don't have to reinvent the wheel to do basic things. From the initial design I have now made use of a cog to actually run an array of up to 8 sensors. The SonarSensor class hierarchy means that I could mix-n-match two pin, one pin, and smart serial sensors without changing the command code or the loop that triggers them. In continuous scan mode the most recent results from any number of sensors can be obtained in about 9.5ms (CMM compiled code). In single scan mode the results are not returned until a complete cycle is finished and that can mean <PER SENSOR SCAN RATE> * <N SENSORS> delay in getting a reading. Continuous scan will be used when in motion to get results quickly with less overhead. Single scan will be used when not moving for decision needs, otherwise keeping the power consumption down not banging away with sonar for no reason.
I've attached the code and documentation I have so far. My 'library' is tiny at this point and is a source-code library too so you still have to include the .cpp files in a project to use it. Hope to expand on this some over time as I work to interface more gizmos to the propeller with C++.
Also a screen-shot of the new parallel processing version handling three sensors (2 x 2-pin sensors and 1 x 1-pin sensor).
Thanks! It's now become a quest to see if I can ever "finish" it!
Update: I now have a functional control program for running steppers from the BBBlack using the STI L6470 stepper driver chip. Using SPI I can command each motor without need to generate steps and for much less real estate than my Chipkit Uno version uses. The biggest hurdles were adapting the Arduino code over to Linux and re-implementing in C++. I have a pretty nice object built for them now though. I did get hit with the fact that internal OSC on each chip appears to have very wide tolerance on frequency. The motors turn at different enough rates between the two driver chips that it will cause issues. So next up is how to correct for that or sync them to a single clock source. The accuracy of the clock is not critical, it's more important that they be the same, whatever that is.
I'll post up more detail this weekend on my own blog and link to it from this thread. I don't want to turn this into a BeagleBone discussion on Parallax forums. This is a big step forward too though, now I need to redo the mounting arrangements and gets some boards made up so I can get this on the robot chassis and off the experiment board.
I ran into one serious problem using these that a Parallax Propeller may be the solution too! The driver chip only moves at the value stored in the MAX_SPEED register when you command a distance movement. To move at various speeds you need to set that register then perform the MOVE command. Problem is that unlike EVERY other speed value in the chip, MAX_SPEED is a @$%@ 10bit number to represent 0 to 15,300+ steps per second. Leaving you a resolution of about 15.25 steps per second per increment of that number. Utterly useless to speed match the motors for this application.
What I came up with though is that each L6470 can be driven from an external clock. The propeller can easily generate the 16 or 32MHz clock signal it wants on that external OSCIN pin. So if I control the clock rate I also control the output speed. Tell the chip it has a 16Mhz clock but drive it with 16.2Mhz and it's going to turn the motor shaft faster for the same speed value. I'll just add that facility to my existing Propeller in the design and I think that presents a solution for this.
Since I have been home sick the past few days with nothing much to do but sit I have been putting the final touches on what I hope will be my robot's "Motherboard" for lack of a better term. I'm creating a board to plug the BeagleBone Black into as well as the excellent SpinSocket boad from Jazzed. This will interface the two together over one of the serial ports from the BBB. The rest of the board is dedicated to buffering the I/O of the BeagleBone to interface to 5V logic and devices as well as breaking out the SPI bus channels and the I2C busses and other UARTs. The Propeller breaks out to 12pins of unmolested 3.3V bi-directional I/O as well as 8 more 5V tolerant I/O. To keep it affordable to produce I stacked the BBB over the Prop in hopes of saving space and easing routing but everything about breaking out that many pins from that header arrangement has been a PITA (and I'm a poor PCB designer). For the most part this has been built out on my huge contraption breadboard so I'm hopeful of functionality from the get-go. We shall see. I'm not completely happy with the density but I'm having trouble getting anything more on there with making a mess of the power. I've ripped up and restarted many times but never seem to find a much better way. At this point I just would like to give it a whirl and see what issues come.
The other interface boards I think I can develop at home and plug into the various connections. PIR / PROX / IMU / SONAR will all be on separate smaller sub boards. Also the SPI based stepper drivers will need to be located elsewhere. I'm considering putting them on the underside of the bot.
The Propeller handled matching the clocks for the two driver boards very nicely. On the test board they turn at exactly the same rate now and I can send serial commands to speed up or slow the clock on one or the other so I have a way to calibrate out any real world speed differences in the right and left wheels. The 8Mhz clock signal definitely shows the limits of the breadboard contraption. The scope showed the signal looked like rats gnawed on it by the time it got over several inches of breadboard and ribbon cable. Series termination helped greatly there.
The robot control program is going to be implemented in Linux as a series of processes that communicate via unix sockets. This keeps me from needing to get into thread programming but still allow for several processes to run their own program loops for sensing and behavior arbitration. I'm considering a third process for actuation but given my limited aims and only two motors to deal with I think arbitration and motor control can happen in on process. Especially since the L6470 stepper drivers are fire-and-forget movement anyway.
A new milestone in my hobby career is reached! My first commercial boards are on their way. One is the soft power switch I plan to use with my bot. This board largely replicates the features of the prototype at the top of this page but shrinks the design considerably doing away with the I2C ADC in the switch design. It's roughly 3x the board area of the Polulu Power Switch but this design gives me:
1) Notice to the CPU/MCU that user pressed the power button.
2) Delayed shutdown pin - Shuts down on falling edge of the PWR_OFF signal rather than instant off.
3) Can integrate into the BBB's PWR_BUT signal to use the existing Linux interrupt structure (assuming Arch ever fixes it to work again)
4) Provision for on-board micro-switch and header for a remote button.
50uA cost while in power-off, 700uA in power-on state. Limited to around 25V, possibly less, depending on real power dissipation on the 3.3V regulator to the MCU on-board. Should be able to switch 4A to 6A I'll have to see how much heat the MOSFET produces.
The second board is the power distribution board. This board carries the above power switch and a stack of the EBay switcher modules to provide VIN, 3V3, and 5V0 the rest of the boards in the bot. 4 connectors for remote boards and one switched raw VIN on terminals. The regulators connect via pigtails to the terminals for the two regulated voltages as well as a switched terminal for VIN. This makes it possible to service or replace the modules later if needed without de-soldering. An I2C ADC is available to measure VIN for main CPU. In my opinion the BBB ADC is next to useless at 1.8V in a noisy environment. I was seeing significant noise just monitoring and averaging the battery voltage using those. 3.3V provides better results. 5V would probably be better but then I have to level shift the bus, and I'm lazy.
Can't wait to get them and see what I forgot or screwed up!!!!!
PCBs arrived from OSH park for the power switch and power distribution. They do really nice work, Aside from 2 small sizing errors of my own making everything even works right!
Thanks Bob! You are correct It is quite an ordeal to make PCBs as I have come to find. SO MANY DETAILS. I was very relieved that the design was sound and working. The two sizing errors were:
1.) The holes for the micro-pushbutton switch were undersized. I forgot to measure them and the default size of 38mil is too small. I sanded the leads on the switch and got them in there.
2.) I widened the distance between pin rows on the daughter board but forgot to carry that down to the larger board. Almost a disaster except I was able to bend the pins on the female sockets enough to fit.
Otherwise it functions A-OK and is now installed on the test rig. I can now power down from the command prompt with no additional intervention as the BBB turns off SYS_3V3 when it shuts down and that falling edge turns off my main switch. Next up is digging out my powermond daemon and coding it to work with the BBB GPIO so I can start a shutdown with a button press.
I even crammed some more function into it I didn't plan for. Holding the PWR_OFF signal high as the switch is connected to power puts the PIC into a programming mode where you can change mode of operation and optional delay timer.
Mode 0 - Immediate shutdown on falling edge (2ms latency)
Mode 1 - Immediate shutdown on rising edge (2ms latency) - Work alike for the Polulu switch.
Mode 2 - Delayed shutdown on falling edge (Programmable delay for up to 51 seconds, 200ms intervals)
Mode 3 - Delayed shutdown on rising edge (Programmable delay for up to 51 seconds, 200ms intervals)
So mode 0 works great if you have some signal that will drop to low after the embedded OS shuts down. Mode 3 would allow for a less intelligent solution if such a signal is not available.
Main board has arrived. Should be able to test it soon. I have a working sensor process now that can accept a socket connection and return sensor data to the client process. Decided to work in strings for now as that makes debugging far easier. Now I need to work on the behavior process design and clean up the sensor process and serial port access code a bit as well. It seems so simple in your head but getting coms between all this working is harder than I thought it would be. I'm anxious to see if the promised C compiler for the Beaglebone's PRUSS devices comes about. That opens up a lot more high speed real time work.
Got all the ICs mounted and soldered in place. I do have one foot-print error with the tiny 2 channel inverter I'm using. I thought it was SOT-23 but it's smaller than that. I still managed to get it on there only to discover it's also the non-inverting part number so I'll have to reorder those and rework that little booger again (sigh). Unfortunately that one is a show stopper since it controls the OE connection on the input buffers to the BBBlack and those lines have to be floating until the BBBlack is fully powered and begins to boot. However all the ICs look like they are properly powered and working correctly. Making notes for revision 2.
It lives! The board is now functional with the proper inverter.
- Linux boots up.
- Battery voltage is detected properly
- Buffers are all functional
- Real Time Clock module works
- Connects to WiFi
Lots of programming work ahead. Hopefully I can modify the propeller GCC loader for the Raspberry Pi to work with the BBBlack so I can program the propeller while mounted to the main board. A couple of silk-screen errors to fix and one IC footprint needs adjustment. Still pretty happy to get a functional board on the first go-round.
Thanks Bob. I keep plugging away a bit at a time. I'm hoping that with a little more thought I can shrink the main-board a bit more and perhaps make a more generic BBBlack robotics platform that could be useful to others as well.
I have got the mainboard and power distribution board mounted on the chassis and it appears there will be enough room to add a long, skinny sensor interface board on the lower deck to convert the 10pin I/O connectors to the various types of connectors needed to hookup the disributed sensors. I'm going to focus first on the sensors and interface needed to handle the simple on/off types (IR Prox / IR motion / bumpers) as well as I2C based stuff (Temp, IMU, LCD). Linux can handle managing those without a great deal of difficulty. So I can hopefully get the bot moving again in a few months. SONAR will have to wait till I can either:
1.) Get the PropGCC Propeller loader modified to use my GPIO for reset on the Propeller chip
2.) The C compiler for using the BBBlack PRU get finished,allowing me to use the PRU for SONAR and other real-time async tasks.
Whichever comes first wins. I'd have to do some HW hacking to get enough I/O from the BBBlack to do the SONAR task.
I have come to both love and hate 3D modeling software. Specifically Alibre. It appears that a number of the parts that I created for my model were saved in the local documents folder of the VM I used to design them. When I went to open the complete model this weekend, it threw errors all over the place for missing parts. Thinking it would be easier to reorganize the parts, as there are a lot of them now I took the chance to go ahead and re-arrange the folders a bit to separate drive / frame / electronics / and mechanicals. I also wanted to move the working copy to the local drive to speed up load times. However the Alibre file format uses the full, rather than relative path of the parts and this in effect killed all the assemblies. I've got to re-create a number of parts from DXF's that were used to make them. I'll have to also reconstruct a lot of the assemblies that made up the design. Ughhh. In fact, overall organization needs to be addressed. I have a lot of GCode and CAM files now that I need to organize and annotate. Looking back I've forgotten what assumptions were part of the machining process of quite a few of the early parts.
Metal, while durable and cool looking is not friendly to seat-of-the-pants construction and my prior attempts to forget the model and just wing-it have usually failed miserably so I will need to get this fixed up. It sucks because I lost a couple of nice 3D models of my SONAR sensors, the sensor stands, and the BBBlack PCB. Futzing with 3D models is not the fun part.
I did start construction of the side walls though this weekend. I hope to have those done by the end of the week.
I'm not sure if I will continue detailing the build (or lack of build as you think) on these forums. My main use for the Propeller was going to be as a sub-controller to the Linux system for real time jobs. I've come to the conclusion that all the conversion and wrangling of strings between two systems and the code to do it all is just not working out for me. I've been having some type of strange memory allocation issue in the library to parse the strings on the Linux side that leads to the program going off in the weeds after a few thousand iterations. I'm tired of fighting with it.
I ended up implementing my sonar controller in an Arduino Nano. It's managing 4 sensors and I'm accessing the data over I2C. Programming is way easier without all the string conversions and my I2C code is pretty easy to build off of. The sensor process is now running 100% after tens of thousands of iterations which leads me to believe it's fairly stable. The behaviour process is going to have access to the sensors via Linux Shared Memory. So the behaviors should have fresh data easily available as well as a simple channel to communicate back to the sensor process when needed. I'm working up the schematic for the sensor connection board. Proximity sensors will be fed to AND gates so that I can have any of the front sensors tripped use only a single I/O pin per side of the robot. I'm likely going to use only two PIR sensors back to back.
So this is not really a Propeller project anymore or really a Parallax project. So I'll ask now if that means I ought to close this out and post elsewhere?
I attached the sudo-datasheet I made for the Arduino controller. I find that it's easy to come back after a few months and find yourself scratching your head wondering how on earth it was that this thing worked again? The debug output from the sensor process below shows the various sensors and what data from them is stuffed in shared memory:
cnt: 00000019
Prox: 01 F B L R
1 0 0 0
Motion: 00 F L R
0 0 0
Sonar: L F R B
40 6 25 251
Temp: BAT EXT
77.3 77.3
I've continued working a bit on getting it moving again. I'm making up cables to wire up the L6470 boards to the 10pin SPI headers on my main board. I'm adding in locking connectors for the motor wiring so working on that is less troublesome. I expect to have it rolling again by end of September assuming I get a few weekends to dedicate to it.
Please keep it here. Among other reasons, your objective comparison of Prop vs Nano may be helpful to others, including Parallax. Hey, a cool bot is a cool bot.
I still enjoy reading about your robot! There aren't to many 'complex' bots which were designed from the ground up. They can be both engineering marvels and disasters waiting to happen, sometimes you don't which it will be until all the parts are assembled! So keep up the documentation and show us what your creation can do! I don't want to be the only long-winded thread left here!
If we get a vote,
Besides, I bet you find a great use for the Propeller after all.
One thing that would be a boon to me is I2C fast slave on the Prop. I think I err'd early on going for a human readable code for the serial data. It just became a problem maintaing parsing and conversion and strings on both sides. Second issue was 115200 is not all that fast. I prefer 400Khz where I can get it. The socket is still there on the board so I can always plug one in later for something new. Sending an integer command code with option bits is 100X easier as is just reading in byte data.
I was able to bang out an I2C protocol on the Nano over the weekend that allows me to random read any byte in the Nano's "i2cDataBuf" with auto-increment as well as transfer all 16 bytes including setup in about 1ms. Here's where the Prop would shine though. I need to spend some effort in the Nano to keep from hogging the command loop when doing a ping sweep. Each sensor eats 50ms of time, four sensors is 1/5 of a second just to get through all of them. To break up the hit I made scanSoner() re-entrant. Each call advances to the next sensor and fires it, reads the results, writes them to the buffer, and delays for what's needed to make it 50ms till the next sensor is fired. Even better will be to make the ping firing time dependent so that there are NO long delays other than actual ranging.
If I could do I2C slave with the Prop at 400Khz then it would be a no brainer for this. Sonar ranging would have zero impact on command execution time but for now I've not seen a 400KHz slave implementation and I don't have the stamina to tackle it.
I'll keep the thread here as long as Parallax is ok with it. I don't want to be seen as promoting a competing product, but I also noted that this sub-forum is more focused on bots than on particular products.
HA HA..... So after getting the SONAR control all finalized I started working on getting the motor drives connected up. I discovered I was missing a clock signal for the motor drives. Care to take a guess what was providing that clock? That's right. The Propeller SpinStamp module. Major "Doh" moment. That was a big part of the design, the external clock signal from the Prop and the ability to slew that clock to speed match the motor drivers. No other chip in the arsenal can do this either, generate two 8Mhz clocks for driving the motor controllers and do command processing on serial lines. Wouldn't matter anyway, the board was designed for SpinStamp. Nothing else is going to work in that socket.
So.... I ripped out the old complicated text-based serial protocol and instead created a very similar command setup for the Prop. Single byte commands with known follow-up bytes for parameters. No parsing, no conversions, no slow string processing. It's already a ton easier to deal with. Should be able to hang extra functionality on there with little heart-burn. Future additions may include Expansion GPIO, PulseOut, PWM, and FreqOut. Several things the BeagleBoard would find difficult to do.
For now I got a super simple version in place that pumps out the needed frequencies so I at least have both motors running on the same clock. The good news is that the signal on the PCB looks freaking fantastic compared to the ringing hideous signal on the breadboard version. Crisp edges, just a slight bit of rounding at the corners from the termination resistors. That makes me feel pretty good about the attention I paid to getting that part right.
Comments
I have been tweaking some design aspects and one was the interior space for the lower level that should house the main control boards and motor drivers. I liked the low profile design but it was getting really tight on horizontal space and vertical space was pretty cramped as well. I decided to increase the height of the lower level but that meant I would have to scale up the sonar sensor stands. While I was at it I figured I could make them a little more simple and make them from 1/4" AL angle rather than bolt on separate legs. This is one of those times when something seems cool on paper until it comes time to put endmill to metal. This design proved tricky to fixture in a way that was solid. I wanted to be able to make more than one per run. In the end I had to cut about 6 new parts to support making 4 sensor stands. While the new one-piece design is very solid it would have been easier to make as a two-piece project. The new stands are 2.75" tall and include tapped 4-40 holes to make it easier to secure instead of trying to tighten nuts in cramped space. Because of the angled sides on the front of the bot it will require a custom hole to be drilled in the robot base platform for each of the side-sonar stands. The non-45 degree angle of the nose was a foolish design choice I just have to live with. I have decided on a hornet color-scheme with black and yellow powder-coat for most of the design.
I'll also be making a new design for the drive mounts. The new plate will include both the front and rear wheels and allow me to enclose the underside of the bot. While the clearance is nice, routing wire under there is getting to be a snag problem. I may go with black acetal plastic for the underside plates so I'm not ramming AL into ground obstructions.
Bob
BeagleBoard.org has full specs but IIRC it's something like 45+ GPIO and 6 ADC. Of course a lot depends on if you want all the hardware backed I/O like UARTS, and I2C or if you want more GPIO and don't care about those. All that is setup in the pinmux settings when Linux boots. The ADC is 1.3V though so noise spikes just got a lot bigger but I guess noise is always a serious concern with an ADC. If you do not use the HDMI interface then you have a lot of GPIO opened up right there.
I had to make a special set of clamps to hold the angled surfaces for the last operation of parting them off the footing. Should be no problem now to knock out more of them and scale up for bigger clamps with more grip.
Made another round of clamps for the upcoming job to make that large wheel mount plate. Here's some neat photo's that process. When you machine a lot of aluminum, working on hogging out steel feels like watching paint dry though, 15 to 25+ Inches per minute drops to 3 to 5 IPM chewing through a deep cut in steel.
Roughing the profiles:
Finish after a clean-up pass with 1/4" carbide endmill:
Ready to add the slotted holes for the 8-32 screws in the tops:
So I have 11 clamps now, over $130.00 worth if I had to buy them. I got to spend that money on these beauties instead. $200 for 10 TTS-style ER25 collet chucks delivered from China to my door in 5 days. All but 2 have under 2.5 ten thousandths of an inch of runout. $20 a pop... not bad at all.
These will be the side-wall attachments. They will clamp to the support pillars that hold up the upper deck and present a face that can be screwed into to attach the side-walls. A horizontal 4-40 screw clamps it to the pillar.
One large hurdle is cleared. I was able to activate all the available serial UARTs (4) and the SPI bus on the BBB using device tree overlays that are automatically inserted and configured at boot time. I have been able to confirm working serial communications to the Propeller. I've been able to get it to boot up into a condition where I can simply echo text to the serial device and it will arrive at the propeller at 115200bps. This makes testing early code for the Propeller command parsing simple. Now I need to work out how I want to go about sampling the simple sensors like the IR prox and motion sensors and get into the world of pThreads. Luckily one soul already wrote a nice c++ interface to MMAPed GPIO so that's one less task off my plate to get there. I am trying to get an understanding of linux gpio_keys so I can have the kernel monitor for events on lines that need to act like interrupts. I have starter code from the Raspberry for the SPI stepper controllers and the I2C IMU so I should be able to adapt those pretty quickly (relatively speaking for my glacial pace on this).
The major outline of the one-piece wheel mounts is done with just a few details left to work out. I hope to correct a few access issues I had with the previous design where the belts made it hard to get to some screws, I'm also working on giving the rear wheel some shock absorption. Right now those rear wheels are loud and the largest sources of heavy vibration and shock when the bot crosses over small bumps. I'm hoping this simple vertical spring system helps with that some.
Big project on the mill is a 1" thick x 18" long x 8" wide tooling plate I'm working on making from flat-bar. Should make certain projects like the deck floors and wheel mounts easier to do. Right now I am taping 117 holes for 3/8-16 thread (less than fun). Next is the really critical part where I drill and ream 120+ holes for 1/4" dowel pins for a positioning grid. Those need to be as close to perfect as I can muster. Flat bar is not ideal for this but I got a chunk of it and I imagine it will work well enough for my needs.
The images attached show the sequence:
Command: [SN:R:S:1]
Ranging
Acknowledgment: A
Result: [222]
I've attached the code and documentation I have so far. My 'library' is tiny at this point and is a source-code library too so you still have to include the .cpp files in a project to use it. Hope to expand on this some over time as I work to interface more gizmos to the propeller with C++.
Also a screen-shot of the new parallel processing version handling three sensors (2 x 2-pin sensors and 1 x 1-pin sensor).
Update: I now have a functional control program for running steppers from the BBBlack using the STI L6470 stepper driver chip. Using SPI I can command each motor without need to generate steps and for much less real estate than my Chipkit Uno version uses. The biggest hurdles were adapting the Arduino code over to Linux and re-implementing in C++. I have a pretty nice object built for them now though. I did get hit with the fact that internal OSC on each chip appears to have very wide tolerance on frequency. The motors turn at different enough rates between the two driver chips that it will cause issues. So next up is how to correct for that or sync them to a single clock source. The accuracy of the clock is not critical, it's more important that they be the same, whatever that is.
I'll post up more detail this weekend on my own blog and link to it from this thread. I don't want to turn this into a BeagleBone discussion on Parallax forums. This is a big step forward too though, now I need to redo the mounting arrangements and gets some boards made up so I can get this on the robot chassis and off the experiment board.
http://www.cranehome.info/index.php?/archives/7-Using-the-L6470-Stepper-Driver-with-Beagle-Bone-Black.html
I ran into one serious problem using these that a Parallax Propeller may be the solution too! The driver chip only moves at the value stored in the MAX_SPEED register when you command a distance movement. To move at various speeds you need to set that register then perform the MOVE command. Problem is that unlike EVERY other speed value in the chip, MAX_SPEED is a @$%@ 10bit number to represent 0 to 15,300+ steps per second. Leaving you a resolution of about 15.25 steps per second per increment of that number. Utterly useless to speed match the motors for this application.
What I came up with though is that each L6470 can be driven from an external clock. The propeller can easily generate the 16 or 32MHz clock signal it wants on that external OSCIN pin. So if I control the clock rate I also control the output speed. Tell the chip it has a 16Mhz clock but drive it with 16.2Mhz and it's going to turn the motor shaft faster for the same speed value. I'll just add that facility to my existing Propeller in the design and I think that presents a solution for this.
The other interface boards I think I can develop at home and plug into the various connections. PIR / PROX / IMU / SONAR will all be on separate smaller sub boards. Also the SPI based stepper drivers will need to be located elsewhere. I'm considering putting them on the underside of the bot.
The Propeller handled matching the clocks for the two driver boards very nicely. On the test board they turn at exactly the same rate now and I can send serial commands to speed up or slow the clock on one or the other so I have a way to calibrate out any real world speed differences in the right and left wheels. The 8Mhz clock signal definitely shows the limits of the breadboard contraption. The scope showed the signal looked like rats gnawed on it by the time it got over several inches of breadboard and ribbon cable. Series termination helped greatly there.
The robot control program is going to be implemented in Linux as a series of processes that communicate via unix sockets. This keeps me from needing to get into thread programming but still allow for several processes to run their own program loops for sensing and behavior arbitration. I'm considering a third process for actuation but given my limited aims and only two motors to deal with I think arbitration and motor control can happen in on process. Especially since the L6470 stepper drivers are fire-and-forget movement anyway.
1) Notice to the CPU/MCU that user pressed the power button.
2) Delayed shutdown pin - Shuts down on falling edge of the PWR_OFF signal rather than instant off.
3) Can integrate into the BBB's PWR_BUT signal to use the existing Linux interrupt structure (assuming Arch ever fixes it to work again)
4) Provision for on-board micro-switch and header for a remote button.
50uA cost while in power-off, 700uA in power-on state. Limited to around 25V, possibly less, depending on real power dissipation on the 3.3V regulator to the MCU on-board. Should be able to switch 4A to 6A I'll have to see how much heat the MOSFET produces.
The second board is the power distribution board. This board carries the above power switch and a stack of the EBay switcher modules to provide VIN, 3V3, and 5V0 the rest of the boards in the bot. 4 connectors for remote boards and one switched raw VIN on terminals. The regulators connect via pigtails to the terminals for the two regulated voltages as well as a switched terminal for VIN. This makes it possible to service or replace the modules later if needed without de-soldering. An I2C ADC is available to measure VIN for main CPU. In my opinion the BBB ADC is next to useless at 1.8V in a noisy environment. I was seeing significant noise just monitoring and averaging the battery voltage using those. 3.3V provides better results. 5V would probably be better but then I have to level shift the bus, and I'm lazy.
Can't wait to get them and see what I forgot or screwed up!!!!!
1.) The holes for the micro-pushbutton switch were undersized. I forgot to measure them and the default size of 38mil is too small. I sanded the leads on the switch and got them in there.
2.) I widened the distance between pin rows on the daughter board but forgot to carry that down to the larger board. Almost a disaster except I was able to bend the pins on the female sockets enough to fit.
Otherwise it functions A-OK and is now installed on the test rig. I can now power down from the command prompt with no additional intervention as the BBB turns off SYS_3V3 when it shuts down and that falling edge turns off my main switch. Next up is digging out my powermond daemon and coding it to work with the BBB GPIO so I can start a shutdown with a button press.
I even crammed some more function into it I didn't plan for. Holding the PWR_OFF signal high as the switch is connected to power puts the PIC into a programming mode where you can change mode of operation and optional delay timer.
Mode 0 - Immediate shutdown on falling edge (2ms latency)
Mode 1 - Immediate shutdown on rising edge (2ms latency) - Work alike for the Polulu switch.
Mode 2 - Delayed shutdown on falling edge (Programmable delay for up to 51 seconds, 200ms intervals)
Mode 3 - Delayed shutdown on rising edge (Programmable delay for up to 51 seconds, 200ms intervals)
So mode 0 works great if you have some signal that will drop to low after the embedded OS shuts down. Mode 3 would allow for a less intelligent solution if such a signal is not available.
- Linux boots up.
- Battery voltage is detected properly
- Buffers are all functional
- Real Time Clock module works
- Connects to WiFi
Lots of programming work ahead. Hopefully I can modify the propeller GCC loader for the Raspberry Pi to work with the BBBlack so I can program the propeller while mounted to the main board. A couple of silk-screen errors to fix and one IC footprint needs adjustment. Still pretty happy to get a functional board on the first go-round.
1.) Get the PropGCC Propeller loader modified to use my GPIO for reset on the Propeller chip
2.) The C compiler for using the BBBlack PRU get finished,allowing me to use the PRU for SONAR and other real-time async tasks.
Whichever comes first wins. I'd have to do some HW hacking to get enough I/O from the BBBlack to do the SONAR task.
I have come to both love and hate 3D modeling software. Specifically Alibre. It appears that a number of the parts that I created for my model were saved in the local documents folder of the VM I used to design them. When I went to open the complete model this weekend, it threw errors all over the place for missing parts. Thinking it would be easier to reorganize the parts, as there are a lot of them now I took the chance to go ahead and re-arrange the folders a bit to separate drive / frame / electronics / and mechanicals. I also wanted to move the working copy to the local drive to speed up load times. However the Alibre file format uses the full, rather than relative path of the parts and this in effect killed all the assemblies. I've got to re-create a number of parts from DXF's that were used to make them. I'll have to also reconstruct a lot of the assemblies that made up the design. Ughhh. In fact, overall organization needs to be addressed. I have a lot of GCode and CAM files now that I need to organize and annotate. Looking back I've forgotten what assumptions were part of the machining process of quite a few of the early parts.
Metal, while durable and cool looking is not friendly to seat-of-the-pants construction and my prior attempts to forget the model and just wing-it have usually failed miserably so I will need to get this fixed up. It sucks because I lost a couple of nice 3D models of my SONAR sensors, the sensor stands, and the BBBlack PCB. Futzing with 3D models is not the fun part.
I did start construction of the side walls though this weekend. I hope to have those done by the end of the week.
I ended up implementing my sonar controller in an Arduino Nano. It's managing 4 sensors and I'm accessing the data over I2C. Programming is way easier without all the string conversions and my I2C code is pretty easy to build off of. The sensor process is now running 100% after tens of thousands of iterations which leads me to believe it's fairly stable. The behaviour process is going to have access to the sensors via Linux Shared Memory. So the behaviors should have fresh data easily available as well as a simple channel to communicate back to the sensor process when needed. I'm working up the schematic for the sensor connection board. Proximity sensors will be fed to AND gates so that I can have any of the front sensors tripped use only a single I/O pin per side of the robot. I'm likely going to use only two PIR sensors back to back.
So this is not really a Propeller project anymore or really a Parallax project. So I'll ask now if that means I ought to close this out and post elsewhere?
I attached the sudo-datasheet I made for the Arduino controller. I find that it's easy to come back after a few months and find yourself scratching your head wondering how on earth it was that this thing worked again? The debug output from the sensor process below shows the various sensors and what data from them is stuffed in shared memory:
cnt: 00000019 Prox: 01 F B L R 1 0 0 0 Motion: 00 F L R 0 0 0 Sonar: L F R B 40 6 25 251 Temp: BAT EXT 77.3 77.3I've continued working a bit on getting it moving again. I'm making up cables to wire up the L6470 boards to the 10pin SPI headers on my main board. I'm adding in locking connectors for the motor wiring so working on that is less troublesome. I expect to have it rolling again by end of September assuming I get a few weekends to dedicate to it.
Bob Sweeney
I vote, Keep it here, "A cool bot is a cool bot."
Besides, I bet you find a great use for the Propeller after all.
-Tommy
One thing that would be a boon to me is I2C fast slave on the Prop. I think I err'd early on going for a human readable code for the serial data. It just became a problem maintaing parsing and conversion and strings on both sides. Second issue was 115200 is not all that fast. I prefer 400Khz where I can get it. The socket is still there on the board so I can always plug one in later for something new. Sending an integer command code with option bits is 100X easier as is just reading in byte data.
I was able to bang out an I2C protocol on the Nano over the weekend that allows me to random read any byte in the Nano's "i2cDataBuf" with auto-increment as well as transfer all 16 bytes including setup in about 1ms. Here's where the Prop would shine though. I need to spend some effort in the Nano to keep from hogging the command loop when doing a ping sweep. Each sensor eats 50ms of time, four sensors is 1/5 of a second just to get through all of them. To break up the hit I made scanSoner() re-entrant. Each call advances to the next sensor and fires it, reads the results, writes them to the buffer, and delays for what's needed to make it 50ms till the next sensor is fired. Even better will be to make the ping firing time dependent so that there are NO long delays other than actual ranging.
If I could do I2C slave with the Prop at 400Khz then it would be a no brainer for this. Sonar ranging would have zero impact on command execution time but for now I've not seen a 400KHz slave implementation and I don't have the stamina to tackle it.
I'll keep the thread here as long as Parallax is ok with it. I don't want to be seen as promoting a competing product, but I also noted that this sub-forum is more focused on bots than on particular products.
So.... I ripped out the old complicated text-based serial protocol and instead created a very similar command setup for the Prop. Single byte commands with known follow-up bytes for parameters. No parsing, no conversions, no slow string processing. It's already a ton easier to deal with. Should be able to hang extra functionality on there with little heart-burn. Future additions may include Expansion GPIO, PulseOut, PWM, and FreqOut. Several things the BeagleBoard would find difficult to do.
For now I got a super simple version in place that pumps out the needed frequencies so I at least have both motors running on the same clock. The good news is that the signal on the PCB looks freaking fantastic compared to the ringing hideous signal on the breadboard version. Crisp edges, just a slight bit of rounding at the corners from the termination resistors. That makes me feel pretty good about the attention I paid to getting that part right.