W.A.L.T.E.R. v2.0

[LinuxGuy]

Those who know me from the Lynxmotion forums (http://www.lynxmotion.net) have probably seen more than they ever wanted to see about W.A.L.T.E.R. ;) I started working on W.A.L.T.E.R. (the Wheeled Autonomous Learning Terrain Exploring Rover) in August of 2006 as my very first robot project. W.A.L.T.E.R. started out as an Octabot II kit from Budget Robotics. To put it mildly, W.A.L.T.E.R. is receiving a MAJOR make over now. I designed a set of brand new and larger octagonal shaped decks based somewhat on the original kit, and fixing what I saw as problems with that kit (wheels not properly centered in the body, all decks were not perfect octagons, etc). So, I designed four decks I believe to be perfect for two wheeled rovers like W.A.L.T.E.R.

I use Alibre Design (http://www.alibre.com) Expert for 3D CAD and I model every robot in full 3D before I even consider ordering parts and starting a build. So far, I have designed many more robots than I can ever probably hope to build, but I also enjoy the design and CAD process very much too. I got together with KM6VV (another Lynxmotion forum user and friend) who has a small Sherline setup. Alan (KM6VV) is a cool fellow and helped me learn what he needed to make stuff from my designs. This is the very first time I have actually seen a design of mine become real and I got a real rush when I saw the first pictures of the new decks. ;) As it turned out, the ONLY problem with my design is that the mounting holes for the Lynxmotion MMT-02 motor mounts are spaced too far apart. I've only been working with 3D CAD since starting work on W.A.L.T.E.R. I'm really happy the way this came out!

W.A.L.T.E.R. started out using continuous rotation servos for locomotion, but gained so much weight the poor servos failed under the load. I have since converted him to roll around on a pair of 5" off road tires on two Lynxmotion (http://www.lynxmotion.com/) GHM-04 (now discontinued) gear head motors controlled by a Dimension Engineering (http://www.dimensionengineering.com) Sabertooth 2x5 motor controller. I also have a Lynxmotion (http://www.lynxmotion.com/) SSC-32 servo controller for servo control and have the Sabertooth 2x5 (bottom deck with the motors) connected to it for PWM based control at present. This is what the software for W.A.L.T.E.R. is setup for right now. I also have a pair of QME-01 shaft encoders for the GHM-04 motors, I2C compass and RTC modules, and a 3-Axis accelerometer to eventually install on W.A.L.T.E.R.

As for sensors, there are currently 5 consisting of 3 Sharp IR Rangers (one on the end of the arm), an IRPD (rear mounted, for sneaky kitty detection), and a PING mounted above the Sharp IR Ranger on the end of the arm. I've been controlling all this and obstacle avoidance so far with a Basic Atom microcontroller made by Basic Micro, but have run out of space for much needed code additions (currently 79 bytes free).

I have decided that I no longer want to use microcontrollers or modules that do not have decent Linux based development tools or are closed and proprietary. I want to do all development I can under Linux from now on and only really need Windows for working with Microchip PICs/dsPICs, Renesas Highspeed Embedded Workshop (which I really do like, and I have four Renesas starter kits), and of course Alibre Design Expert for 3D CAD. Well, OK, I also need Windows for when I want to play WoW (Silver Hand for Alliance and Bronzbeard for Horde) but I have not been able to play for almost 3 months now. :( :(

Right now I am tinkering with the Hammer Board module from TinCanTools (http://www.tincantools.com), which will be W.A.L.T.E.R.'s next main controller. I could wish for more RAM and Flash on Hammer, but I believe it will work out very good for a new main controller. I already have the Hammer Carrier board mounted on W.A.L.T.E.R. and also have the components I need to modify that for dual power (battery or wall wart). I can pretty easily convert the current software that runs W.A.L.T.E.R. over to a language such as Python (http://www.python.org) since I have not used any microcontroller specific features. I have been tinkering with a Subsumption architecture, based heavily on work by members of the DPRG (http://www.dprg.org), for the new control software. I hope to also create a version of software for W.A.L.T.E.R. in Smalltalk (Squeak (http://www.squeak.org)).

My first real project with Hammer is going to be interfacing two Microchip dsPIC30F4012's to it, using I2C, which will each handle the tasks of reading and processing data from the shaft encoders (one quadrature encoder module per 4012), providing five 10-bit ADCs, more GPIOs, and perhaps other things in the future. The 4012's also have a 6 channel motor control PWM module I might eventually implement.

These are my current plans for W.A.L.T.E.R. v2.0. I believe I can accomplish all of this in bits and pieces over a very long time. You can see some early development videos, and some current pictures, of W.A.L.T.E.R. on my website.

8-Dale

[Droid Works]

Very cool, Awesome project. I cant wait to see more videos.

[LinuxGuy]

Very cool, Awesome project. I cant wait to see more videos.
I probably will not be posting any more new pictures or videos because all I have is a cheap $50.00 webcam. I can't get the resolution I want to show the real detail I need to show.

However, I am almost finished with the new 3D model of W.A.L.T.E.R. 2.0, so can post a 3D PDF of that, which you will be able to rotate and zoom to see whatever you want to see from any angle.

8-Dale

[LinuxGuy]

OK, I posted a few grainy and otherwise bad pictures of the new decks for W.A.L.T.E.R.

I am also working on an IRC bot to integrate with the rest of the software for W.A.L.T.E.R. to provide an IRC interface. :happy:

Since the rest of the control software will also be written in Python, this should work well.

8-Dale

[LinuxGuy]

I have uploaded two images of the front arm I have designed for W.A.L.T.E.R.

The end effector is the wrist rotate for a Lynxmotion Little Grip Kit (http://www.lynxmotion.com/Product.aspx?productID=161&CategoryID=).

8-Dale

[LinuxGuy]

I finally did it - broke down and ordered five servos for the front arm on W.A.L.T.E.R. I should have them early next week. I am getting 5 Hitech servos, 3 HS-645MG and 2 HS-475MG. I'll use at least two HS-645MG servos in the arm itself, with the third (pan servo) being an HS-475MG. The Gripper, which I need to add to the order, will have an HS-475MG for wrist rotation and an HS-645MG for the actual gripper. I'll shuffle servos around as required.

8-Dale

[LinuxGuy]

I've been doing some tinkering with the front mounted arm, deck spacing, etc. I'm trying to get the arm and decks working where the arm can actually reach in and pick objects (which could be RSRs) from the cargo deck and put them on the floor, as well as retrieve them from the floor and put them back on the cargo deck. I got my inspiration for this from a comment Sienna made on IRC one evening after I mentioned I also want to build a Really Small Robot. I am very close now, and may just have to raise the second deck another 1/2" or so to make it possible.

Right now, I have the arm mounted on the front of the top deck. which does not allow it to reach all the way to the floor. I am trying to coordinate the deck spacing with the arm design, and this is proving to be quite a challenge. I've already redesigned the arm completely once and have another idea for it. The arm is made of SES brackets, so my spacing options are pretty limited.

Update 04/21/2008: I think I have found a deck spacing, 3" between the bottom/second and second/third decks that will indeed allow W.A.L.T.E.R. to load/unload from his new cargo deck. I am also tinkering with a different way to mount the end effector sensors. I have an idea..

I love tinkering!

8-Dale

[LinuxGuy]

Here are a few new pictures of W.A.L.T.E.R., taken at the March meeting of PARTS. All photos were done by Tyberius J5 Productions. :happy: I pulled this from my blog in case some had not had a chance to see them.

Top Deck:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_top_deck_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=195&c=3&userid=1657)
This shows the new top deck, with all the SES compatible hole mounts for brackets, sensors, and much more.

Left side of the arm:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_left_arm_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=199&c=3&userid=1657)
This shows the left side of W.A.L.T.E.R. with the new front mounted 3DOF arm and sensor/gripper head.

The Electronics (Third) Deck:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_top1_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=197&c=3&userid=1657)
Here is a view of the electronics on the third deck. You can see the Hammer Carrier Board near the center and the Lynxmotion SSC-32 at the rear. Nothing is connected at present.

Closer view of the electronics:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_top2_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=198&c=3&userid=1657)

IR Sensor Mount:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_ir_mount2_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=193&c=3&userid=1657)
Here you see the way I can mount sensors without interfering with the deck standoffs. The standoff just does go through the sensor mount.

Another view of the sensor mounts:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_ir_mount1_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=192&c=3&userid=1657)


Fully exposed bottom:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_bottom1_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=191&c=3&userid=1657)

View of the new arm:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_arm1_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=189&c=3&userid=1657)
I think I am going to move the arm to an upper deck. I don't think it can have full function where it is now.

Detail of the sensor/gripper head:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_arm_head_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=190&c=3&userid=1657)
I finally figured out a way to mount two sensors together without needing an additional bracket. :happy:

Here's lookin' at you kid: :veryhappy:
http://forums.trossenrobotics.com/gallery/files/1/6/5/7/walter_looking_thumb.jpg (http://forums.trossenrobotics.com/gallery/showimage.php?i=196&c=3&userid=1657)

8-Dale

[LinuxGuy]

Here is a small update: I've solved the problem of how to get the entire sensor/gripper assembly to rotate the way I want it to. I only need a Little Grip Attachment kit to attach the Little Grip and gripper servo. I don't know if the end effector assembly is too heavy for an HS-475HB servo to rotate, but will be finding out very soon. :veryhappy:

8-Dale

[LinuxGuy]

I've switched to using Gentoo Embedded Linux (http://www.gentoo.org/proj/en/base/embedded/) for software development on W.A.L.T.E.R. This gives me access to much more software. I've caught the interest of the lead developer for Gentoo Embedded, and we are discussing various ideas. He wants to see W.A.L.T.E.R. operational. :happy::happy::veryhappy:

I've now got a web server (Cherokee (http://www.cherokee-project.com), configured and working), SQL Database (SQLite (http://www.sqlite.org/), configured and works), web framework (DJango (http://www.djangoproject.org)), and an IRC Bot (Phenny, configured and working) SSH (Dropbear (http://matt.ucc.asn.au/dropbear/dropbear.html)), plus supporting dependency packages stuffed into the 16 MB of Flash on the Hammer (http://www.elinux.org/Hammer_Board). I just need two more packages (pysqlite and python imaging) to complete the software components for W.A.L.T.E.R. These last to components will allow images to be processed and connection between DJango (http://www.djangoproject.org/) and SQLite (http://www.sqlite.org/) to be made. PySQLite will, of course, also allow SQLite to be accessed from any Python (http://www.python.org) program.

I'm doing software development using a TinCanTools (http://www.tincantools.com) Nail Board (http://www.elinux.org/Nail_Board), which has built in JTAG. There are just two USB connectors protruding from the case, one for the USB Client connection to the PC and the other for USB Host to connect other devices. The USB Client provides up to three devices - JTAG, Console port, and one Gadget device. The Gadget device can be Ethernet, serial, mass storage, etc. I have it configured for Gadget Ethernet.

I am also working on a tutorial for Gentoo Embedded Linux (http://www.gentoo.org/proj/en/base/embedded/), but it will be awhile before I can post it here. If you want to see the progress on this tutorial, check it out on my Wiki (http://www.thedynaplex.info/tikiwiki). I also have a Blog (http://www.thedynaplex.info/serendipity) and Forums (http://www.thedynaplex.info/smf) (not setup yet).

As you can see, I have not been idle. :veryhappy:

8-Dale

[Adrenalynn]

Good to see you, Dale! We were plotting to send out a search party to hunt you down!

[Electricity]

Walter is a really cool project! You've put so much effort into him, its absolutely unbelievable.

[LinuxGuy]

Walter is a really cool project! You've put so much effort into him, its absolutely unbelievable.
Thankyou. :veryhappy: W.A.L.T.E.R. will have some interesting capabilities when I have all the hardware together and some software written. The arm itself is a unique design, having a double joint - this gives the arm some incredible flexibility. :veryhappy:

8-Dale

[LinuxGuy]

Good to see you, Dale! We were plotting to send out a search party to hunt you down!
Thanks. I've just been lurking mostly, lately.

8-Dale

[Adrenalynn]

Well cut that out and post darnit! We miss you! [But our aim is improving all the time... ;)]

[LinuxGuy]

Well cut that out and post darnit! We miss you! [But our aim is improving all the time... ;)]
Ha ha, but you'd have to catch me first! :p I can move at almost 10 MPH in my chair.. :veryhappy:

I finally have the rest of the electronic and arm parts for W.A.L.T.E.R.! I got 50 of the 2n7000 FETs to use for level shifting and other things, some 74AHC245 tri-state octal bus transceivers, and a few 2 position screw terminals to test out for the new battery power supply of the Hammer Carrier Board. I also got the last of the SES brackets to complete the arm assembly. :veryhappy: A very nice friend from the UK sent me some money for robot parts.

I've also setup a GIT repository on GitHub (http://www.github.com) for all the sources of software I will write for W.A.L.T.E.R. 2.0, including all the startup scripts used to initialize his various subsystems. I have chosen all the software that will be used, which I of course will add a significant part to.

8-Dale

[droidcommander]

W.A.L.T.E.R. looks cool, what program do you use to do your modeling? Did you have to model all the components yourself or did you find them pre-made somewhere?

All I've used in the past is google sketch-up

DroidCommander

[LinuxGuy]

W.A.L.T.E.R. looks cool, what program do you use to do your modeling? Did you have to model all the components yourself or did you find them pre-made somewhere?
I use Alibre Design Expert (http://www.alibre.com) for my 3D CAD and modeling. There is a free no timeout version once it is registered. Lynxmotion has a library of 3D models of all their Servo Erector Set brackets, some of which I have created.

8-Dale

[LinuxGuy]

Here are some pictures that show the flexibility of the new arm.

http://www.thedynaplex.info/pics/walter-arm-up.jpghttp://www.thedynaplex.info/pics/walter-arm-cargo.jpghttp://www.thedynaplex.info/pics/walter-arm-down.jpg
8-Dale

[ooops]

I use Alibre Design Expert (http://www.alibre.com) for my 3D CAD and modeling. There is a free no timeout version once it is registered. Lynxmotion has a library of 3D models of all their Servo Erector Set brackets, some of which I have created.

8-Dale

Dale, great link! I don't know when I will get time to play with it, but I downloaded it in the off chance I do.

[LinuxGuy]

Well, I finally did it! After over a year of not working on W.A.L.T.E.R., I finally got back into researching controllers and chose one. I've been looking more seriously at the Axon, and it certainly does have all the hardware features and memory I want at present. So, I have ordered one and should have it early next week! :) I've already got the development system setup and validated it so I know it works. All that remains is to get my Axon and start learning how to program it. I'm pretty exited! :D

I'll attach one of my SSC-32 servo controllers to one of the Axon's serial ports. The SSC-32 will handle the arm, a new front pan/tilt, plus provide control for the Sabertooth 2X5 motor controller. I will finally be able to have up to eight pairs of IR/Ultrasonic sensors, I2C devices, etc plugged into W.A.L.T.E.R. For other analog type sensors such as accelerometers, I'll most likely be using RoboDuinos that will communicate to the master Axon (and later a master Linux based controller) using I2C. With a Linux based master controller, I'll also have the possibility of interfacing these using USB.

Oh yeah, I'm baaaaa-aaaaack.. :D

8-Dale

[Adrenalynn]

Welcome back!

You certainly don't need the SSC32 connected up to it. It'll support more servos than the SSC32 could ever dream of.

[sam]

Hey!

8 pairs of Ultra-sonic/Ir sensors... :eek:

Wow! can't wait to see that. Keep us posted!

Sam

[LinuxGuy]

Welcome back!
Thanks! :D


You certainly don't need the SSC32 connected up to it. It'll support more servos than the SSC32 could ever dream of.
I realize that. It's just my preference to use the SSC-32 for all things having to do with servos. I just don't want to have to dink around trying to get the features the SSC-32 already has built into it. Servo control is just one aspect I am not interested in working with at a low level. :)

8-Dale

[DresnerRobotics]

Thanks! :D


I realize that. It's just my preference to use the SSC-32 for all things having to do with servos. I just don't want to have to dink around trying to get the features the SSC-32 already has built into it. Servo control is just one aspect I am not interested in working with at a low level. :)

8-Dale

It also keeps that plethora of I/O available for other things.

Welcome back btw!

[LinuxGuy]

It also keeps that plethora of I/O available for other things.
Yes, indeed it does, and that's definitely another consideration for W.A.L.T.E.R. I'll have some LEDs I will be wanting to PWM for visual indicators and "mood" of W.A.L.T.E.R., as well as sounds. I love using sounds to indicate what is happening on a robot.


Welcome back btw!
Thanks. :)

I'm really looking forward to working with the Axon now, but need to reformat some things for my way of doing things. I've already done a small bit of that. I prefer having things in linkable libraries, so will be looking at how best to do that as I use more of the Axon's features.

I'm very picky about my source code. :)

8-Dale

[Adrenalynn]

Have you looked at John's code? He's done quite a bit of work, such as in the servo control libraries and what-not.

It's just a difference of priorities. Hardware UARTs are a lot scarcer than I/O. I'd rather give up I/O and keep my UARTs.

[LinuxGuy]

Have you looked at John's code? He's done quite a bit of work, such as in the servo control libraries and what-not.
I have not looked at much of it yet. For me, it's probably going to mostly be a matter of how stuff is formatted and/or indented. I did say I am picky. :)


It's just a difference of priorities. Hardware UARTs are a lot scarcer than I/O. I'd rather give up I/O and keep my UARTs.
Hardware UARTs are almost always in short supply, so I favor giving up I/O to keep them also. :) I've already pretty much decided how the top section (analog and digital pins) are going to be used on W.A.L.T.E.R. (8 pairs of PING and IR distance sensors). I'll use RoboDuino(s) for other stuff, like accelerometers, that require multiple analog I/Os.

I have a few wish for the Axon at this time, but that's me.

1) Jumper selection for whether I/Os get +5V or unregulated power, maybe in groups of 4 pins.
2) Group sets of pins, like those for PWM.
3) A +5V pin on the I2C header to make daisy chaining and powering devices a bit easier.

I'm extremely happy to have so much actual code to look at and use - that's got a LOT to do with me choosing the Axon over other possibilities, plus the fact it is designed for robotics. I am very pleased with what I see in the Axon, and I think it will be a great addition to my controller arsenal. :) I should be able to get back to doing what I enjoy most pretty quickly - writing robot software.

Linux, Axon, and RoboDuinos, Oh My!

8-Dale

[LinuxGuy]

Have you looked at John's code?
I've started digging into the Axon code now. I've pulled a couple of routines out of sensors.c into control.c and added a new control.h header. Now I can change or add defines unique to the setup for W.A.L.T.E.R. without messing with the hardware.c or sensors.c files. This will preserve the ability to upgrade to later versions of the Axon software without affecting my own stuff.

Right now, I am working to modify the sonar_Ping() routine to allow passing one or two parameters to select a specific PING sensor I want to read. This will hopefully allow me to read sensors in a loop as I did before when using a different MCU. I just have to dig deeper into the AVR hardware definitions to see if I can calculate the actual PIN on PORTA the sensor is attached to, based on the new pingnr parameter.

I've pulled the sonar_Ping() routine from sensors.c into control.c and redefined it as read_ping(int pingnr) to avoid conflicts and preserve the original for comparisons and debugging. I won't change John's code more than to allow selecting the specific PING sensor I want to read. There will be up to eight PINGs (each one paired with a Sharp GP2D12) on W.A.L.T.E.R. when everything is setup the way I want. If this works as I hope, I will follow the same format for the Sharp IR sensors.

8-Dale

[LinuxGuy]

Since I don't have my AXON yet, I decided to fire up my Sanguino and tinker with some sensors. I found some code for the PING on the Arduino Playground, so loaded it up and checked it out. It does work, so that's good. The next thing I did is pull the code that actually reads the PING into a function of its own. This is so I can read a bunch of PINGs connected to consecutive pins in a loop.

I am considering using a RoboDuino for dedicated sensor processing, especially for PING and Sharp GP2D12 IR sensors. It would be interesting to make a RoboDuino into an I2C slave that just processes a group of these sensors located around W.A.L.T.E.R. A RoboDuino could even be used for dedicated processing of the two sensors on the pan/tilt as well as moving the pan/tilt servos, so this could always be scanning as W.A.L.T.E.R. moves around. The RoboDuinos could interrupt the AXON when an event occurs, such as coming too close to an object.

Using RoboDuinos for dedicated processing would always mean W.A.L.T.E.R. has an up to date sensor readings anytime. I think this could work out very well and it would take the load of basic sensor processing off the AXON, so it could handle other important stuff. I like the idea of always having sensors being processed as W.A.L.T.E.R. moves around, independent of anything that is being done on the AXON main controller.

This would leave all the processing power of the AXON available for other tasks, such as processing a 3-Axis accelerometer, I2C compass, and eventually a camera. This could be the beginning of the distributed processing architecture I've always had in mind. With this sort of setup, I don't think I will need a faster multiprocessing capable controller for the master controller. I think the AXON would fill the role of master controller very nicely.

8-Dale

[lnxfergy]

I think you were going along fine until you added "and eventually a camera". The shear amount of processing required means that a uC at 16MHz can barely keep up with a small camera module (take a look at the code for the AVRCam, which runs at 17.something MHz), there's just not a lot of clock cycles per frame. If you seriously want to do any vision processing on the main core, you'll want to make that main core be more than an AVR.

-Fergs

[Adrenalynn]

Not enough memory or bus, either. Even at 320x240x8bpp, we're talking 76KB/frame. Three frame buffer minimum, 230KB. We need to run at least, say, ten of those a second to be meaningful.

Realistically, unless you have a meg of memory, you really don't need to apply.

[darkback2]

I wonder...could you send the video data offbot for processing? Or is there a chip that could process the video for you? seams like some vision is better than no vision...(in the world of the blind the one eyed man is king?)

DB

[Adrenalynn]

>> Or is there a chip that could process the video for you?

Absolutely. It's called a "microcontroller with more guts than the AVRs." ;)

>> could you send the video data offbot for processing

Absolutely! You'll need a microcontroller with more guts than the AVR to handle packetizing and shipping the data. :)

[darkback2]

Sorry to junk up your thread, but could you use something like this? (http://www.mindsensors.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=78)

[lnxfergy]

Sorry to junk up your thread, but could you use something like this? (http://www.mindsensors.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=78)

I'd probably get an AVR cam first, has non-I2C interface, costs $50 less, and has same specs otherwise. Either way, it's fairly limited, tracking 8 blobs seriously eats up ALL the processor time. You probably want to look at something like a surveyor camera for real processing ability.

-Fergs

[Adrenalynn]

Just like the avrcam. Do you really need to detect a large blob of color and nothing else, typically? Is that all that useful?

[jes1510]

Moving the video processing offboard is a good idea. A wifi cam talking to a laptop for processing is a good option if you don't want to add electronics to the robot but still need to do video processing.

[Adrenalynn]

I agree with that, in general. The wifi cam has a sizable amount of processing power on it. Usually a DSP and an MCU.

[LinuxGuy]

I think you were going along fine until you added "and eventually a camera". The shear amount of processing required means that a uC at 16MHz can barely keep up with a small camera module (take a look at the code for the AVRCam, which runs at 17.something MHz), there's just not a lot of clock cycles per frame. If you seriously want to do any vision processing on the main core, you'll want to make that main core be more than an AVR.
You seem to be making an invalid assumption here. Of course I know an AVR isn't going to be able to process video. I'm not planning to use an AVRCam, CMUCam or similar camera. It's going to be the Blackfin camera. If not the Blackfin camera, I'd throw something like a BeagleBoard in as the master controller.

8-Dale

[Adrenalynn]

LinuxGuy Wrote:
> You seem to be making an invalid assumption here. Of course I know an AVR isn't going to be able to process video.

>> This would leave all the processing power of the AXON available for other tasks, such as processing a 3-Axis accelerometer, I2C compass, and eventually a camera.

Sorry! My mistake! I don't know how I ended-up assuming you might want to use an AVR for anything like the task of processing a camera.I think we read more into it than was there. Mea Culpa. ;)

[lnxfergy]

You seem to be making an invalid assumption here. Of course I know an AVR isn't going to be able to process video. I'm not planning to use an AVRCam, CMUCam or similar camera. It's going to be the Blackfin camera. If not the Blackfin camera, I'd throw something like a BeagleBoard in as the master controller.


This would leave all the processing power of the AXON available for other tasks, such as processing a 3-Axis accelerometer, I2C compass, and eventually a camera. This could be the beginning of the distributed processing architecture I've always had in mind. With this sort of setup, I don't think I will need a faster multiprocessing capable controller for the master controller. I think the AXON would fill the role of master controller very nicely.

What? Where did I draw an assumption? I give up...

-Fergs

[LinuxGuy]

I received my AXON and new casters yesterday, but I have to figure out a slightly different way of powering it. The connectors on my batteries are not compatible with the connector on the AXON power switch. However, I think if I power the SSC-32 direct from the battery as is done normally, I should be able to connect the AXON power switch to one of the servo terminals for power.

Unregulated power comes off the SSC-32 servo connections, so this should work fine. I'll just leave the VS=VL and VS1=VS2 jumpers installed on the SSC-32, since I won't be driving more than 10 - 12 servos.

8-Dale

[darkback2]

I've been thinking about how I run batteries and power all over the place. I'm thinking (for me that is) of starting to incorporate a terminal block from which each device can draw power. That way it will be easier to add/subtract subsystems. Also, I can build regulators so that everything has the power type it needs.

As for your project, Good luck and keep us posted. It seams like your on to some really cool ideas.

DB

[LinuxGuy]

As for your project, Good luck and keep us posted. It seams like your on to some really cool ideas.
Power distribution on W.A.L.T.E.R. doesn't require anything too complicated, so I should be OK with my new idea. I only have to power the SSC-32 and AXON (same battery) plus a Sabertooth 2X5 motor controller (separate battery). I'll use a [email protected] NiMH pack for the SSC-32/AXON and switch that up to a [email protected] pack eventually. I've got a [email protected] pack for the Sabertooth and motors.

This should give me some respectable runtime.

I'll also be switching to using a slightly smaller wheel (Banebots 4 7/8" (http://www.trossenrobotics.com/store/p/5798-Rubber-Wheel-4-7-8-x-0-8-1-2-Hex-Bore.aspx) with these hubs (http://www.trossenrobotics.com/store/p/5839-1-2-Hex-Mount-Hub-6mm-Shaft-0-4-Wide.aspx)) soon. I believe this combo should work fine with the 6mm shafts on the gear motors I am using. I'll get either the orange or blue compound wheels. I am not sure yet which would be best for all around all surface indoor roaming.

8-Dale

[Adrenalynn]

6v won't give you much headroom. I haven't looked up the regulator, but I'd suspect that 5.5vDC would be dropout time.

[LinuxGuy]

6v won't give you much headroom. I haven't looked up the regulator, but I'd suspect that 5.5vDC would be dropout time.
I won't be running servos from the AXON. The SSC-32 works fine with 6V running servos.

8-Dale

[Adrenalynn]

Ummm. Yes. ? :)

My point still stands. That gives you 0.5v of headroom. Once the Axon and SSC-32 [logic] drain the battery 0.5v, your logic will go wonky. Crashing CPU's, garbage I/O, etc.

[lnxfergy]

Well, 6V isnt exactly 6V though.... at full charge (assuming nimh), you'd have about 1.35Vx5-cells = 6.75V, at full discharge you're at 0.9Vx5-cells = 5.4V (at least, we typically cut off high-current RC packs at 0.9V), which means you get *most* of the range.... but yes, you won't use the full range of your pack, it'll still be putting out decent current when the regulator starts to go all wonky...

-Fergs

[Adrenalynn]

The interesting thing is that it's the capacitor that's the limiting factor, not the reg, for Max Volts.

Now I'm going to toss it back to you - Sure - the battery's putting out 5.4v, but isn't the reg going to drop that at least a few hundred mV?

[sam]

Why not run logic from a separate 9 volt battery? Couldn't that work?

Sam

[Adrenalynn]

yup- but if you're talking the typical little 9v - not for very long with the Axon, especially if you had any sensors on it.

[Macro Man]

Well, 6V isnt exactly 6V though.... at full charge (assuming nimh), you'd have about 1.35Vx5-cells = 6.75V, at full discharge you're at 0.9Vx5-cells = 5.4V (at least, we typically cut off high-current RC packs at 0.9V), which means you get *most* of the range.... but yes, you won't use the full range of your pack, it'll still be putting out decent current when the regulator starts to go all wonky...

-Fergs


Some of the newer SMD low-dropout 5v regulators will stay well in regulation even under 5.5v;

(specs of MIC5209)
500mA = typ 350mV
150mA = typ 165mV
50mA = typ 115mV

[lnxfergy]

Some of the newer SMD low-dropout 5v regulators will stay well in regulation even under 5.5v;

(specs of MIC5209)
500mA = typ 350mV
150mA = typ 165mV
50mA = typ 115mV

Yeah, but most controllers geared to hobbyists today are 0.5v dropout (at a current of 250-500mA, which is controller + half a dozen sensors). The AXON and SSC-32 are both in the 450-500mV range for dropout.

-Fergs

[nagmier]

LinuxGuy I saw you mentioned in another thread about adding voice to your project at some point... I happened across this new breakout board @ Sparkfun http://www.sparkfun.com/commerce/product_info.php?products_id=8849

its an OGG Media playback with 256mb of storage on the cheap too!

[LinuxGuy]

Well, 6V isnt exactly 6V though.... at full charge (assuming nimh), you'd have about 1.35Vx5-cells = 6.75V, at full discharge you're at 0.9Vx5-cells = 5.4V (at least, we typically cut off high-current RC packs at 0.9V), which means you get *most* of the range.... but yes, you won't use the full range of your pack, it'll still be putting out decent current when the regulator starts to go all wonky...
I've been looking into the power situation more, but am not yet clear as to whether the connections I need are valid for the SSC-32. What I probably need to do is go to a two battery power setup, one powering the servos on one side of the SSC-32 (VS2), and the other powering VL and the other side (probably VS1). I'm not yet sure if having VS=VL installed (powering VL and VS1) and VS1=VS2 removed (separate VS2 power) is a valid configuration.

Since W.A.L.T.E.R. has had a dual battery setup for power from the start, having two batteries is not a problem. How that power is routed to components is what will change. This time around power will have to go from the SSC-32 in all cases, to servos and electronics as needed.

W.A.L.T.E.R. has always been a bit wonky. :)

8-Dale

[LinuxGuy]

LinuxGuy I saw you mentioned in another thread about adding voice to your project at some point... I happened across this new breakout board @ Sparkfun http://www.sparkfun.com/commerce/product_info.php?products_id=8849
Nice find!

I'll probably get one of these to tinker with, even if it doesn't end up on W.A.L.T.E.R. I must maintain the beeps and whirs, which is part of W.A.L.T.E.R.'s personality. :)

8-Dale

[LinuxGuy]

I've confirmed that I can connect all the electronics the way I need to, thanks to Jim at Lynxmotion. I missed the name of the VL=VS1 jumper, thinking it was just VL=VS. I hate when that happens! :D

My current power plan for W.A.L.T.E.R. is to power all the electronics, including motor controller and motors, from a [email protected] NiMH pack (connected to VL) and get a [email protected] NiMH pack (to be connected to VS2) just for servo power. This should give me reasonable runtime for everything.

On the SSC-32, I'll have the VS=VS1 jumper installed and the VS1=VS2 jumper removed.

The new casters look like they will work, although they are quite a bit larger than I anticipated, which could be a good thing. I may not even have to add a shim between the bottom deck and the caster. I'm thinking about just letting W.A.L.T.E.R. tilt a bit to put which ever caster needs to be on the ground down and letting the other caster ride above ground level. Actually, when I get the new slightly smaller wheels, this may not even happen since there isn't much of a difference right now.

8-Dale

[LinuxGuy]

I've completed the 3D CAD models for two new decks, but am seeing some issues with the ball casters I bought. They are definitely much larger than I thought they would be, which is creating an problem placing the mounting holes for them. In the configuration I have now, I think the casters will be too far from the rear and front points of WALTER. I need WALTER to be as stable as possible, especially at the front, because the arm will be mounted at the very front of the top or third deck.

With the caster from the original kit, I can easily mount that below the servo for the pan on the new pan/tilt sensor assembly. This caster is much smaller than the new ones I bought though, and I won't be able to mount them the same way due to their size. With his current 5" wheels, WALTER's bottom deck rides 3.75" above the floor.

I can make one of these new casters work for the rear. That is not the problem. The problem is the front caster, because of the servo mount for the pan/tilt. Hmmmm, maybe I will try using the original front caster with one of the new casters on the back. It might look a little odd having two different types of casters, but I think it would work.

Ultimately, I would like to use the same caster setup as John uses on his ERP. I really like the idea of using those omni wheels as casters and I think I can mount four of them on WALTER pretty easily. What other casters are available that would work on a small to medium sized robot? The ones I have found so far are either too small, too large, or marginal on size that would be usable.

Feedback welcome! :D

8-Dale

[Adrenalynn]

http://www.harborfreight.com search caster

[LinuxGuy]

http://www.harborfreight.com search caster
Interesting. Thanks. ;) The first two on the search results look like they might work. There is a local Harbor Freight store I can get to easily, so I will have to go check these out. Hopefully they will have some in stock.

8-Dale

[Adrenalynn]

At mine, it's like caster-heaven. Exactly the same products built on exactly the same line for like 1/8th the cost of Home Depot or Lowes too. It's kinda amusing. I've bought up most of what they've had over the years, and I still always seem to be buying more for this or that project. Naviguesser (my RoboMagellan 'bot) uses the 5" swivel trolley caster.

[LinuxGuy]

At mine, it's like caster-heaven. Exactly the same products built on exactly the same line for like 1/8th the cost of Home Depot or Lowes too. It's kinda amusing. I've bought up most of what they've had over the years, and I still always seem to be buying more for this or that project. Naviguesser (my RoboMagellan 'bot) uses the 5" swivel trolley caster.
Until you suggested it, I hadn't even considered Harbor Freight as a possible source of casters. I was looking on McMaster, but they didn't really have anything I liked. Those two casters from HF look like good possibilities though. :)

8-Dale

[DresnerRobotics]

How heavy duty are you looking for? The Pololu one (http://www.trossenrobotics.com/store/c/2726-Casters-and-Transfers.aspx)s are pretty solid for smaller, indoor bots.

[LinuxGuy]

How heavy duty are you looking for? The Pololu one (http://www.trossenrobotics.com/store/c/2726-Casters-and-Transfers.aspx)s are pretty solid for smaller, indoor bots.
WALTER is 11.5" diameter and about 10" tall, so I'm not sure those would work well.

After thinking about this quite a lot, I've decided to remove the pan/tilt from the bottom deck and remove the arm from the top deck. I think I've been trying to do way too much with WALTER, and am going to orient him only to three specific areas now. Doing this will allow me to use both of the nice ball casters I got from Trossen. :)

From now on, I will orient WALTER completely for line following, maze solving, sensor experimentation, swarm experimentation (with ASTRID), and behavior based robotics. With the AXON, I have the processing power and potential to do some really cool stuff in these areas. I think this will be the perfect fit for WALTER. :)

This will be the last build I do with WALTER, at least as far as his mechanical and basic hardware and sensor configuration goes, other than adding a wireless communication system and Blackfin camera. I'll probably add more sensors as I continue to focus WALTER's development in the new areas I've chosen for him, but this will be the last complete rebuild he gets.

8-Dale

[robologist]

Another possible is to snag the double casters from strollers (http://www.shopping.com/xPP-strollers-cheap_strollers). Doesn't seem to be a week go by without someone tossing a stroller out.

[LinuxGuy]

Another possible is to snag the double casters from strollers (http://www.shopping.com/xPP-strollers-cheap_strollers). Doesn't seem to be a week go by without someone tossing a stroller out.
I think stroller casters would be quite a bit too large for WALTER. He's only 11 1/2" diameter and about 10" high with four decks.

8-Dale

[LinuxGuy]

Since I am now setting some different goals for WALTER's development, I redesigned the new middle and top decks to relocate the pan/tilt to the middle deck. I also removed the SES holes from the rear point of the bottom deck. This allows me to add mounting holes for the two 2" ball casters I bought and get the full benefit for stability. I've also added mounting holes for a Tracker line following sensor on the front point and an IRPD on the rear point of the bottom deck.

The arm I designed and built for WALTER will now be used on ASTRID instead. Once I get the three new decks made and WALTER has been rebuilt, and all electronics mounted and tested, this will be his final mechanical configuration. I will be moving fully into software development from this point.

The only other hardware stuff I'll be adding/changing will be sensors, a camera, Wifi and Zigbee wireless communications, etc. I don't quite have the new deck designs quite finalized yet, but as soon as I do I will have to find somewhere to make them. I think I will stick with the same material WALTER's current decks are made of, which is also the same material the original kit decks are made of.

Since I am not going to mount an arm on WALTER now, I won't need the SSC-32. There will only be two servos for the pan/tilt and two servo controls for the Sabertooth motor controller. I might also try the serial control option of the motor controller.

This brings up a whole new question regarding how to power WALTER's electronics and servos. All of the battery packs I have only have the Tamiya connectors, which are not compatible with the AXON controller. Would this [email protected] (http://www.trossenrobotics.com/store/p/5917-NiMH-Rechargable-Battery-6v-3300mAh.aspx) battery pack be able to handle everything, including servo power? I don't want to over volt my servos, and will be using Hitec HS-475's for the pan/tilt. I'll still use a [email protected] battery pack to power the motor controller and motors.

8-Dale

[Adrenalynn]

Why not just splice a cut-off servo connector into your power bus?

I couldn't imagine the cost of replacing my batteries every time I needed a different connector...

[lnxfergy]

This brings up a whole new question regarding how to power WALTER's electronics and servos. All of the battery packs I have only have the Tamiya connectors, which are not compatible with the AXON controller. Would this [email protected] (http://www.trossenrobotics.com/store/p/5917-NiMH-Rechargable-Battery-6v-3300mAh.aspx) battery pack be able to handle everything, including servo power? I don't want to over volt my servos, and will be using Hitec HS-475's for the pan/tilt. I'll still use a [email protected] battery pack to power the motor controller and motors.

Make an adapter to change Tamiya to a reciever style connection. $3 . There's no such thing as incompatible (unless we're talking about voltages, and even then, there's DC-DC converters).

-Fergs

[LinuxGuy]

Why not just splice a cut-off servo connector into your power bus?
All I have is a couple of switch harnesses for power right now. They have bare wire on one side and Tamiya connectors for the battery pack on the other side. They use #16 stranded wire. The AXON doesn't have any screw terminals for connecting power, and my current battery packs only have the Tamiya connector.

I'm getting less and less motivated to tinker with the AXON for my robotic application, even though I like the over all idea. Power distribution/connection and lack of jumper selectable power for I/Os are real deal breakers for me. I'll still tinker with it because I really want to learn the AVR architecture, but I am much less inclined to actually put it on a robot now and am starting to look at alternatives.


I couldn't imagine the cost of replacing my batteries every time I needed a different connector...
I'm not replacing battery packs. I need to get additional battery packs anyway, because I will soon have a second robot (ASTRID). If companies would standardize on one type of connector, like for robotics, it would make things soooooo much easier and nicer. It seems like nobody wants to be compatible with anyone else.

8-Dale

[Adrenalynn]

yeah, exactly what I was getting at. But since the rest of my power bus is presumably already tamiya-type, I'd just splice in.

[Adrenalynn]

>> I'm getting less and less motivated to tinker with the AXON for my robotic application, even though I like the over all idea. Power distribution/connection

Oh come on, it's a freakin' thirty cent connector!

>> and lack of jumper selectable power for I/Os are real deal breakers for me.

Take the signal from the board and external power off whatever power bus you want...

I give up.

[edit to add: For those considering the Axon: There is absolutely nothing inherently wrong with the Axon for any application where a medium-large AVR is a design consideration. I'm not entirely behind that 10v cap sitting next to a regulator that can comfortably take about double that voltage, but that's just a part selection quibble and entirely personal. Other than that, the Axon is an ideal choice as an experimenters board for the larger AVRs. John's done a great job bringing a hard to solder SMT part to the robotics hobbyist market. And his code is a must-read for learning to interface with a variety of sensors on the AVR platform.]

[societyofrobots]

LinuxGuy, I recommend making a small Hitec connector to Tamiya (or whatever) connector adapter. Just get one of each connector and put a little wire in between. I have several little hand-made adapters like these that I keep around. I'm a big fan of using Hitec connectors for everything:
http://www.societyofrobots.com/electronics_wire_connector.shtml


I'm not entirely behind that 10v cap sitting next to a regulator that can comfortably take about double that voltage, but that's just a part selection quibble and entirely personal.
Agreed. If I were to go back in time before manufacturing, I would have used a smaller 16V cap there. Anyway, its easy to snip it off and put a different one of higher voltage there if needed.

[LinuxGuy]

After not working on robots at all for a year or so, due to health issues, I am back working on WALTER now. I am turning him into a 2WD/4WD rover with independent steering and control on all wheels.

I've decided to use my AXON as the main controller, since I will be using an SSC-32 for servo control, and won't need to use any of the unregulated pins. However, I will be using ALL the serial ports - one for the SSC-32, one for the motor controllers, and one for XBee wireless. I will also be using some I2C devices.

I've already got the basic structure of my code written and debugged for the AXON now. I'm using the Webbot framework, which really makes it easier to do stuff and concentrate on the application rather than doing a lot of low level coding.

Front view with a couple legs I am building.
http://i853.photobucket.com/albums/ab97/robotguy_bucket/WALTER/walter_front.jpg

Side view
http://i853.photobucket.com/albums/ab97/robotguy_bucket/WALTER/walter_side.jpg

Back view showing the independent steering of two wheels.
http://i853.photobucket.com/albums/ab97/robotguy_bucket/WALTER/walter_independent.jpg

You can see more pictures (http://s853.photobucket.com/albums/ab97/robotguy_bucket/WALTER/) of the all new WALTER too.

8-Dale

[LinuxGuy]

Below is the current code I have to make an Arduino a serial slave to any other micro.

BeagleComm.pde

/*
http://www.arduino.cc/en/Tutorial/SerialCallResponse

Created 26 Sept. 2005
by Tom Igoe
Modified 14 April 2009
by Tom Igoe and Scott Fitzgerald

Modified 31-May-2010
Dale Weber <[email protected]>

Version: 0.10
Date: 20-May-2010
Purpose: Added remote serial control commands to read sensors and send readings back through UART.

Version: 0.20
Date: 31-May-2010
Purpos: Added the remote Dump (D) command to allow dumping sensor data to a terminal.
*/
#include <Servo.h>
#include "BeagleComm.h"

int inValue = 0; // Incoming serial byte
byte ir[6]; // IR sensor data;
byte ping[8]; // Ultrasonic semsor data

Servo pan, tilt;

// Establish contact with the master controller
void establishContact() {
while (Serial.available() <= 0) {
Serial.print('!', BYTE); // Send a '!'

delay(300);
}
}

/*
http://www.arduino.cc/en/Tutorial/Ping

created 3 Nov 2008
by David A. Mellis
modified 30 Jun 2009
by Tom Igoe

This example code is in the public domain.
*/

// Read distance from a PING ultrasonic sensor
// Code taken from the Arduino Playground. Returns distance in cm.
long read_ping (byte pin) {
// establish variables for duration of the ping,
// and the distance result in inches and centimeters:
long duration, inches, cm;

// The PING))) is triggered by a HIGH pulse of 2 or more microseconds.
// Give a short LOW pulse beforehand to ensure a clean HIGH pulse:
pinMode(pin, OUTPUT);
digitalWrite(pin, LOW);
delayMicroseconds(2);
digitalWrite(pin, HIGH);
delayMicroseconds(5);
digitalWrite(pin, LOW);

// The same pin is used to read the signal from the PING))): a HIGH
// pulse whose duration is the time (in microseconds) from the sending
// of the ping to the reception of its echo off of an object.
pinMode(pin, INPUT);
duration = pulseIn(pin, HIGH);

// Convert the time into a distance
// inches = microsecondsToInches(duration);
cm = microsecondsToCentimeters(duration);

// Serial.print("\nPin ");
// Serial.print(pin, DEC);
// Serial.print(": ");
// Serial.print(cm, DEC);

return cm;
}

long microsecondsToInches(long microseconds) {
// According to Parallax's datasheet for the PING))), there are
// 73.746 microseconds per inch (i.e. sound travels at 1130 feet per
// second). This gives the distance travelled by the ping, outbound
// and return, so we divide by 2 to get the distance of the obstacle.
// See: http://www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf
return microseconds / 74 / 2;
}

long microsecondsToCentimeters(long microseconds) {
// The speed of sound is 340 m/s or 29 microseconds per centimeter.
// The ping travels out and back, so to find the distance of the
// object we take half of the distance travelled.
return microseconds / 29 / 2;
}

// Read Sharp GP2D12 IR sensor.
// Code taken from the Arduino Playground. Returns distance in cm
int read_gp2d12 (byte pin) {
int tmp;

tmp = analogRead(pin);

if (tmp < 3)
return -1; // Invalid value

tmp = (6787.0 /((float)tmp - 3.0)) - 4.0;

return tmp;
}

// Convert lower case to upper case
char toUpper (char inp) {
if ((inp >= 97) & (inp <= 122))
return inp - 32;
else
return 0xFF;
}

// blink a heartbeat LED
void do_heartbeat (void) {
digitalWrite(HEARTBEAT_PIN, HIGH);
delay(250);
digitalWrite(HEARTBEAT_PIN, LOW);
delay(250);
}

void setup() {
byte i;

pinMode(HEARTBEAT_PIN, OUTPUT);

// start serial port at 115200 bps:
Serial.begin(115200);

// Initialize sensor arrays
for (i = 0; i < IR_MAX; i++)
ir[i] = 0;

for (i = 0; i < PING_MAX; i++)
ping[i] = 0;

establishContact(); // Send a byte to establish contact until receiver responds
}

// Responds to commands from the master controller and updates sensor readings
void loop() {
byte errorNr = 0, sensorNr = 0; // Eorror number, Sensor index number
byte angle = -85, increment = 10; // Scan angle and increment
byte pin, inValue; // Pin number to read (analog or digital)
boolean scanarea = false; // Scan flag
char maincmd, seccmd; // Main and secondary command chars

errorNr = 0;

do_heartbeat(); // Blink the heartbeat LED

// Get incoming byte:
if (Serial.available() > 0) {
maincmd = toUpper(Serial.read());

// Process master controller commands
switch (maincmd) {
case 'D':
Serial.print(\nSensor Data Dump\n");

// Dump IR sensor data
for (sensorNr = 0; sensorNr < IR_MAX; sensorNr++) {
Serial.print("\nIR sensor #");
Serial.print(sensorNr, DEC);
Serial.print(": ";
Serial.print(ir[sensorNr], DEC);
Serial.print(" cm");
}

// Dump PING sensor data - Digital pins 4 through 11
for (sensorNr = 0; sensorNr < PING_MAX; sensorNr++) {
Serial.print("\nPING sensor #");
Serial.print(sensorNr, DEC);
Serial.print(": ";
Serial.print(ping[sensorNr], DEC);
Serial.print(" cm");
}

break;
case 'G':
// Get an immediate sensor reading
seccmd = toUpper(Serial.read());

sensorNr = Serial.read();
sensorNr = sensorNr - 48;

if (seccmd == 'I') {
ir[sensorNr] = read_gp2d12(sensorNr);
Serial.print(ir[sensorNr], DEC);
else if (seccmd == 'U') {
ping[sensorNr] = read_ping(sensorNr + PING_START);
Serial.print[ping[sensorNr], DEC;
}
break;
case 'R':
if (Serial.available() > 0) {
// Get the second character of the command
seccmd = toUpper(Serial.read());

switch (seccmd) {
case 'A': // RA command (Read Analog)
case 'P': // RP command (Read Pulse)
// Read an analog pin
inValue = Serial.read();
pin = inValue - 48;

if (seccmd == 'A')
inValue = analogRead(pin);
else {
pinMode(pin, OUTPUT);
digitalWrite(pin, LOW);
pinMode(pin, INPUT);
inValue = pulseIn(pin, HIGH);
}

if (seccmd == 'A')
Serial.print("\nAnalog #");
else
Serial.print("\nPulse #");

Serial.print(pin, DEC);
Serial.print(" = ");
Serial.print(inValue, DEC);

break;
case 'V': // RV command
// Send all current sensor readings
// Send header
Serial.print(IR_MAX + PING_MAX, BYTE);
Serial.print(IR_MAX, BYTE);
Serial.print(PING_MAX, BYTE);

// Send IR sensor readings
for (sensorNr = 0; sensorNr < IR_MAX; sensorNr++)
Serial.print(ir[sensorNr], BYTE);

// Send PING sensor readings
for (sensorNr = 0; sensorNr < PING_MAX; sensorNr++)
Serial.print(ping[sensorNr], BYTE);

break;
case 'I': // RI command (Read IR)
case 'U':
// Send single IR sensor reading
inValue = Serial.read(); // Get sensor number
sensorNr = inValue - 48;

if (seccmd == 'I')
Serial.print(ir[sensorNr], DEC);
else
Serial.print(ping[sensorNr], DEC);
break;
default:
break;
}
} else
errorNr = 254;
break;
case 'S': // S command (Scan area)
// Scan area using pan/tilt
scanarea = true;
break;
case 'T': // Test command
// Test command
Serial.println("\nTesting.. ");
break;
default:
break;
}
}

// Read IR sensors
for (sensorNr = 0; sensorNr < IR_MAX; sensorNr++)
ir[sensorNr] = read_gp2d12(sensorNr);

// Read PING sensors - Digital pins 4 through 11
for (sensorNr = 0; sensorNr < PING_MAX; sensorNr++)
ping[sensorNr] = read_ping(sensorNr + PING_START);

delay(50);

// Scan an area from -85 degrees to +85 degrees using a pan/tilt
if (scanarea) {
Serial.print("\nScanning..");
scanarea = false;
// Scan area using the Pan/Tilt sensors
}
}
BeagleComm.h

#ifndef BeagleComm_h
#define BeagleComm_h

#include <inttypes.h>
#define IR_MAX 2
#define PING_MAX 2
#define PING_START 4

#define HEARTBEAT_PIN 13

#endif
This isn't really anything earthshattering as far as programming goes. The entire command structure is contained in the two switch blocks, which can be applied to any C programmable micro (AXON, etc). It can easily be expanded to handle any length commands.

8-Dale

[LinuxGuy]

A minor update today. I've decided not to use my AXON on any of my robots. The power distribution issue I have with it (not able to select unregulated vs regulated for blocks of pins) is just not something I want to deal with. I'll use the AXON for Atmega experimentation and tinkering, simply because at present it is the best Atmega based controller available.

I've decided to get a Basic Micro Arc32 board as soon as Lynxmotion has them in stock. This is a nice all in one board that is programmable in either the native basic like dialect (ala expanded Atom Pro) or C, like the Atom Pro. I've dusted off my BotBoard II and Atom Pro and checked out all the I/Os, and everything seems to be working.

Below is a slightly updated version of my Arduino Serial Slave code. The code should be fine, but for some reason I am getting weird JAVA errors when I try to upload it to my Arduino or Sanguino. I have no idea what is wrong here, but the errors scroll so fast I can't read them. It appears the errors are generated in some of the Arduino IDE code, but I can't tell for sure. I'm using the Arduino 018 IDE upgraded with the Sanguino software.


/*
http://www.arduino.cc/en/Tutorial/SerialCallResponse

Created 26 Sept. 2005
by Tom Igoe
Modified 14 April 2009
by Tom Igoe and Scott Fitzgerald

Modified 20-May-2010
Dale Weber <[email protected]>

Version: 0.10
Date: 20-May-2010
Purpose: Added remote serial control commands to read sensors and send readings back through the UART.

Version: 0.20
Date: 31-May-2010
Purpos: Added the remote Dump (D) command to allow dumping sensor data to a terminal.

Version: 0.21
Date: 03-Jun-2010
Purpose: Changed all if/then statements to switch() blocks to make adding new secondary commands easier.

Version: 0.22
Date: 03-Jun-2010
Purpose: Bugs fixed. Everything compiles and uploads properly now. Works great!
*/
//#include <Servo.h>
#include "BeagleComm.h"

int inValue = 0; // Incoming serial byte
byte ir[6]; // IR sensor data;
byte ping[8]; // Ultrasonic semsor data

//Servo pan, tilt;

// Establish contact with the master controller
void establishContact() {
while (Serial.available() <= 0) {
Serial.print('!', BYTE); // Send a '!'

delay(300);
}
}

/*
http://www.arduino.cc/en/Tutorial/Ping

created 3 Nov 2008
by David A. Mellis
modified 30 Jun 2009
by Tom Igoe

This example code is in the public domain.
*/

// Read distance from a PING ultrasonic sensor
// Code taken from the Arduino Playground. Returns distance in cm.
long read_ping (byte pin) {
// establish variables for duration of the ping,
// and the distance result in inches and centimeters:
long duration, inches, cm;

// The PING))) is triggered by a HIGH pulse of 2 or more microseconds.
// Give a short LOW pulse beforehand to ensure a clean HIGH pulse:
pinMode(pin, OUTPUT);
digitalWrite(pin, LOW);
delayMicroseconds(2);
digitalWrite(pin, HIGH);
delayMicroseconds(5);
digitalWrite(pin, LOW);

// The same pin is used to read the signal from the PING))): a HIGH
// pulse whose duration is the time (in microseconds) from the sending
// of the ping to the reception of its echo off of an object.
pinMode(pin, INPUT);
duration = pulseIn(pin, HIGH);

// Convert the time into a distance
// inches = microsecondsToInches(duration);
cm = microsecondsToCentimeters(duration);

// Serial.print("\nPin ");
// Serial.print(pin, DEC);
// Serial.print(": ");
// Serial.print(cm, DEC);

return cm;
}

long microsecondsToInches(long microseconds) {
// According to Parallax's datasheet for the PING))), there are
// 73.746 microseconds per inch (i.e. sound travels at 1130 feet per
// second). This gives the distance travelled by the ping, outbound
// and return, so we divide by 2 to get the distance of the obstacle.
// See: http://www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf
return microseconds / 74 / 2;
}

long microsecondsToCentimeters(long microseconds) {
// The speed of sound is 340 m/s or 29 microseconds per centimeter.
// The ping travels out and back, so to find the distance of the
// object we take half of the distance travelled.
return microseconds / 29 / 2;
}

// Read Sharp GP2D12 IR sensor.
// Code taken from the Arduino Playground. Returns distance in cm
int read_gp2d12 (byte pin) {
int tmp;

tmp = analogRead(pin);

if (tmp < 3)
return -1; // Invalid value

tmp = (6787.0 /((float)tmp - 3.0)) - 4.0;

return tmp;
}

// Convert lower case to upper case
char toUpper (char inp) {
if ((inp >= 97) & (inp <= 122))
return inp - 32;
else
return 0xFF;
}

// blink a heartbeat LED
void do_heartbeat (void) {
digitalWrite(HEARTBEAT_PIN, HIGH);
delay(250);
digitalWrite(HEARTBEAT_PIN, LOW);
delay(250);
}

void setup() {
byte i;

pinMode(HEARTBEAT_PIN, OUTPUT);

// start serial port at 115200 bps:
Serial.begin(115200);

// Initialize sensor arrays
for (i = 0; i < IR_MAX; i++)
ir[i] = 0;

for (i = 0; i < PING_MAX; i++)
ping[i] = 0;

establishContact(); // Send a byte to establish contact until receiver responds
}

// Responds to commands from the master controller and updates sensor readings
void loop() {
byte errorNr = 0, sensorNr = 0; // Eorror number, Sensor index number
byte angle = -85, increment = 10; // Scan angle and increment
byte pin, inValue; // Pin number to read (analog or digital)
boolean scanarea = false; // Scan flag
char maincmd, seccmd; // Main and secondary command chars

errorNr = 0;

do_heartbeat(); // Blink the heartbeat LED

// Get incoming byte:
if (Serial.available() > 0) {
maincmd = toUpper(Serial.read());

// Process master controller commands
switch (maincmd) {
case 'D':
Serial.print("\nSensor Data Dump\n");

// Dump IR sensor data
for (sensorNr = 0; sensorNr < IR_MAX; sensorNr++) {
Serial.print("\nIR sensor #");
Serial.print(sensorNr, DEC);
Serial.print(": ");
Serial.print(ir[sensorNr], DEC);
Serial.print(" cm");
}

// Dump PING sensor data - Digital pins 4 through 11
for (sensorNr = 0; sensorNr < PING_MAX; sensorNr++) {
Serial.print("\nPING sensor #");
Serial.print(sensorNr, DEC);
Serial.print(": ");
Serial.print(ping[sensorNr], DEC);
Serial.print(" cm");
}

break;
case 'G':
// Get an immediate sensor reading
seccmd = toUpper(Serial.read());

sensorNr = Serial.read();
sensorNr = sensorNr - 48;

switch (seccmd) {
case 'I': // IR Sensor
ir[sensorNr] = read_gp2d12(sensorNr);
Serial.print(ir[sensorNr], BYTE);
break;
case 'U': // Ultrasonic (PING) Sensor
ping[sensorNr] = read_ping(sensorNr + PING_START);
Serial.print(ping[sensorNr], BYTE);
break;
default:
break;
}
break;
case 'R':
if (Serial.available() > 0) {
// Get the second character of the command
seccmd = toUpper(Serial.read());

switch (seccmd) {
case 'A': // RA command (Read Analog)
case 'P': // RP command (Read Pulse)
// Read an analog pin
inValue = Serial.read();
pin = inValue - 48;

switch (seccmd) {
case 'A':
inValue = analogRead(pin);
Serial.print("\nAnalog #");
break;
case 'P':
pinMode(pin, OUTPUT);
digitalWrite(pin, LOW);
pinMode(pin, INPUT);
inValue = pulseIn(pin, HIGH);
Serial.print("\nPulse #");
default:
break;
}

Serial.print(pin, DEC);
Serial.print(" = ");
Serial.print(inValue, DEC);

break;
case 'R': // RR command
// Send all current sensor readings
// Send header
Serial.print(IR_MAX + PING_MAX, BYTE);
Serial.print(IR_MAX, BYTE);
Serial.print(PING_MAX, BYTE);

// Send IR sensor readings
for (sensorNr = 0; sensorNr < IR_MAX; sensorNr++)
Serial.print(ir[sensorNr], BYTE);

// Send PING sensor readings
for (sensorNr = 0; sensorNr < PING_MAX; sensorNr++)
Serial.print(ping[sensorNr], BYTE);

break;
case 'I': // RI command (Send last IR reading)
case 'U':
// Send single IR sensor reading
inValue = Serial.read(); // RU command (Send last PING reading)
sensorNr = inValue - 48;

switch (seccmd) {
case 'I':
Serial.print(ir[sensorNr], BYTE);
break;
case 'U':
Serial.print(ping[sensorNr], BYTE);
break;
default:
break;
}

break;
default:
break;
}
}
break;
case 'S': // S command (Scan area)
// Scan area using pan/tilt
scanarea = true;
break;
case 'T': // Test command
// Test command
Serial.println("\nTesting.. ");
break;
default:
break;
}
}

// Read IR sensors
for (sensorNr = 0; sensorNr < IR_MAX; sensorNr++)
ir[sensorNr] = read_gp2d12(sensorNr);

// Read PING sensors - Digital pins 4 through 11
for (sensorNr = 0; sensorNr < PING_MAX; sensorNr++)
ping[sensorNr] = read_ping(sensorNr + PING_START);

// Scan an area from -85 degrees to +85 degrees using a pan/tilt
if (scanarea) {
Serial.print("\nScanning..");
scanarea = false;
// Scan area using the Pan/Tilt sensors
}
}
All I've done here is convert all the if/then statements to switch() blocks to keep everything consistant and make it easier to add new commands.

Edit: Updated code listing for BeagleComm.pde after fixing bugs - everything works now.

8-Dale

[societyofrobots]

I've decided not to use my AXON on any of my robots. The power distribution issue I have with it (not able to select unregulated vs regulated for blocks of pins) is just not something I want to deal with. I'll use the AXON for Atmega experimentation and tinkering, simply because at present it is the best Atmega based controller available.

thanks!

Probably not worth buying another mcu since you have a lot already, but I completely revamped the power distribution on the Axon II. I added some regulated digital pins, and you can select to use either one or two batteries (one for regulated, the other for non-regulated). Just for future ref, I guess . . .

[LinuxGuy]

Probably not worth buying another mcu since you have a lot already, but I completely revamped the power distribution on the Axon II. I added some regulated digital pins, and you can select to use either one or two batteries (one for regulated, the other for non-regulated). Just for future ref, I guess . . .
Please don't think I don't like the AXON. I do like it - just not to put on my robots. I was just hoping for a bit more flexibility in power distribution for the AXON2. I believe I have figured out what I need to do to modify my AXON to create more +5V pins on either side, so am thinking about doing that. I just need to do some more checking to be sure I won't mess anything else up on the board before modding it.

8-Dale

[societyofrobots]

I believe I have figured out what I need to do to modify my AXON to create more +5V pins on either side, so am thinking about doing that. I just need to do some more checking to be sure I won't mess anything else up on the board before modding it.
I'm guessing you plan to cut traces and splice with wires? If you want a double checker before you mod, just let me know and I'm more than willing to verify/help.

Just out of curiosity, what are you using that requires so many regulated power-bus digital output pins? :confused:

[LinuxGuy]

I'm guessing you plan to cut traces and splice with wires? If you want a double checker before you mod, just let me know and I'm more than willing to verify/help.
As soon as I am sure how I want to do the mod, I'll let you know so you can tell me if it's the right way to go or not. I still have to check what features are available on each side of the AXON before I decide which side I want to change to regulated power.


Just out of curiosity, what are you using that requires so many regulated power-bus digital output pins? :confused:
It's not that I need so many +5V digital pins, but that I want to keep the analog capable pins free for analog inputs and experimentation - accelerometers, etc. I was hoping the AXON2 would have jumperable power for blocks of pins.

8-Dale

[LinuxGuy]

Greetings, everyone!

I have returned, and am back working on W.A.L.T.E.R. 2.0 again. I'm currently using an Arduino Mega ADK board with a DFRobot Sensor Shield as the main "brain" for W.A.L.T.E.R. right now, but also plan to try out other boards in various combinations (I have two Raspberry Pi, a BeagleBoard Black, a PandaBoard ES, and two teensy3.1 boards). I also want to get an UDOO quad, which I am extremely interested in because it will give me Linux as well as Arduino Due compatibility. I'll get a real Arduino Due and test stuff out on it first though, before I move on to something like an UDOO quad. There will be some kind of Linux board on W.A.L.T.E.R. as soon as I get the basic sensor/locomotion going reliably. For instance, I also have most of the sensors (except the Gyro) working with a Raspberry Pi running a Python script.

There is a front pan/tilt with Parallax PING and Sharp IR sensors. I've let the magic smoke out of the Sabertooth 2x5 motor controller, so I have upgraded to a RoboClaw 2x5 controller because it has encoder inputs. Both of W.A.L.T.E.R.'s motors have encoders.

Here is what W.A.L.T.E.R. 2.0 looks like now:

5356

Well, this picture is already a little out of date. I'll have to transfer more pictures from my phone. That breadboard is my display/sensor board. It has an IMU (LSM303 Accelerometer/L3DG20 Gyro/BMP180 Temperature sensor), RGB Color sensor, and a heat sensor on it, as well as a DS1307 real time clock module. There are also two displays on that breadboard - a four digit seven segment display and an 8x8 matrix display. I use the 8x8 matrix display for displaying the units, or a graphic, to indicate what is on the seven segment display.

That's all for now. More later!

8-Dale

[KevinO]

Welcome back!