Prop ASC+ and the Pololu Zumo = SactoRobotics Table Top Challenge
The Pololu kit looked interesting because of the track drive and form factor (impulse purchase while shopping for my StingRay II parts...). Saw the kit interface board setup for an Arduino and thought it would be perfect to mate up with the Propeller ASC+.
This Zumo Robot Kit for Arduino includes the chassis, control board with Arduino interface; no motors. I ordered the kit and the 75:1 micro motors, already have a Prop ASC+ that was looking for a fun project.
The plan is to add the Zumo IR sensor interface and use this robot in my local monthly Robot Meet-up group, SacroRobotics. We are setting up for the next round of table top challenge contest in Aug. I brought the Boe-Bot last year to the contest; looks like a few folks have various versions of the Boe-Bot this year too. I was looking for a fun form factor that I could still run the Propeller on.
Wondering how hard it would be to port the Arduino Zumo Library over to Propeller C? Could be a side project as I go along. Been wanting to get more into software side of things (I still like the building stuff part of this hobby best).
This Zumo Robot Kit for Arduino includes the chassis, control board with Arduino interface; no motors. I ordered the kit and the 75:1 micro motors, already have a Prop ASC+ that was looking for a fun project.
The plan is to add the Zumo IR sensor interface and use this robot in my local monthly Robot Meet-up group, SacroRobotics. We are setting up for the next round of table top challenge contest in Aug. I brought the Boe-Bot last year to the contest; looks like a few folks have various versions of the Boe-Bot this year too. I was looking for a fun form factor that I could still run the Propeller on.
Wondering how hard it would be to port the Arduino Zumo Library over to Propeller C? Could be a side project as I go along. Been wanting to get more into software side of things (I still like the building stuff part of this hobby best).
Comments
.
Neat project. I've had my eye on the Zumo for a while, but I have too many robots so I can't justify yet another tread-bot running around. For mini-sumo that thing looks like it would be hard to beat.
Take a look at my Propeller port of the Arduino library.
http://forums.parallax.com/showthread.php/148401-Propeller-Chip-runs-a-mostly-unmodified-Arduino-program-(video)
My guess is the port wouldn't be hard and if you need specific parts of the library I could take a stab at it.
This will be my first tread-bot. Good times!
Built the Zumo with all optional jumpers and the #1419 Zumo Reflectance Sensor Array.
Using ASC+ REV E with the header attached for the daughter board. Previously I had my ASC+ with the daughter board attached to one of my Boe-Bots. Got a half nake boe-bot now that needs some new brains (Boe-Bot shield intact)...
Have a little clearance issue around the power end of the board. The can caps are hitting each other, however the "Arduino" shield headers are seating well at about 95% full connection only lifting up a bit on that end (see picture).
Power on test is good, both the shield and ASC+ have power. Haven't done any software tests. Pololu has some can sketches, so for testing I will pop on an UNO and validate the rest of the hardware from a software perspective.
Using Hobby King rechargeable 3000ma Ni-MH AA batteries.
Can't wait to see it in action. I had just asked and learned about the ASC+ because my wife bought me some Seeedstudio shields from the Shack and I am not an Arduino user...
I went
Currently the motor PWM is 1 cog, I think the line-following/edge detection will be another cog and finally the compass in another. The button, buzzer and LED will just have PUB's associated with them.
This is a big learning project for me, so you will see a LOT of documentation in my object. I tend to have gaps between my propeller development endeavors so I forget a lot the SPIN tricks...
The line-following will be interesting because the shield sends some of the data through digital only pins and some through the A/D on the Prop ASC+ board.
Here is the video of the demo attached to the Object --> DEMO: Zumo motor test.
[video=youtube_share;q6ImhwRgRjQ]
Martin - Looking for some advice on how to mimic the Arduino's Analog PINS regarding their ability to also be GPIO. (Thinking about how Ardunio treats the A0-5 pins as either analog input or GPIO.)
The ZUMO Reflectance sensor spans across both GPIO pins and Analog pins for both out-put and input. The sensor works the same way as the Parallax QTI sensor. It's an RC circuit that would require both Output and input on the same pin. Given the ASC+ has all of the Analog pins mapped to the MCP3208, I don't see a way to remap pins without modification to the ASC+ or the ZUMO Shield. Big goal is to setup the Zump Prop object to work without hardware mods
What have other folks done when a shield requires the Arduino analog pins to be GPIO rather than analog input only?
Please PM me your address and I will swap you out for an ASC+. It has 12-bit ADC and a uSD slot.
Thanks Martin - No worries, after double checking and triple checking the schematics and the reviewing the MCP datasheet to be sure no software work around would be possible, I elected to modify the Zumo Reflectance sensor.
Pololu set it up modficiation to the sensor to be done easily (and well documented too). I had to cut the traces that tied it to the A# pins then solder in 10K resisters (Prop pin protection for a 5v device IO) and ribbon cable to connect up with the Prop ACS's daughter board connections. (I ended up cutting all 6 sensors traces so that I could keep the bytes togeather when reading the data in through the daughter board connections). Haven't tested any software yet, however there is what looks like a solid QTI object that will lend itself to being a future Zumo Reflectance sensor object. Good stuff.
Modification to the sensor vs the shield or ASC itself was pretty easy. Others that want to duplicate will have no issues doing this give the build effort already required to build the Zumo w/ shield.
I merged some code from the OctoQTI Object into the Zumo object. I need to clean up the demo program a bit before updating the OBEX. Currently it will output scaled sensor values on the serial terminal. Next step will be edge detection for this week's Sac Robotics Club meeting.
NOTE - Additional Modification Requirement (still no modifications to the ASC+ required)
Had to modify the Zumo Shield to setup the 'User button' on PIN 12 correctly. While looking at the Zumo Shield schematic for the button, I was thrown off a bit regarding how it would pull the pin low with out a pull up reference. Needless to say the simple OUTA[13] := INA[12] didn't impact the Shields LED.
After reviewing the example Ardunio code, I was reminded that ATMEL has a software switch to make any of the digital IO pins be high with an internal pull up resister.
The shield modification route I chose was not great. I wanted to mount a 10K resister on the back between +3.3 and the PIN 12 connected to the switch. This required taking Zumo apart, I should have done it on the top and saved the trouble of fixing what I broke while taking it apart... However now just looking at the shield it appears unmodified.
In the end, I now have a working button with a pull up resister. Also the shield had a 1k pull-down resister that I removed and bridged directly to groun. I didn't test if that would have been fine to leave in placed, I suspect it would have.
The Zumo Object now controls:
- Motor driver
- IR sensor array
- Yellow LED
- User button
This is enough for this's month Sac Robot's club contest, so now I have to switch gears from hardware interface development to application task development.
Thanks to Martin for helping me out with a board refresh. The extra couple of pins that make it a full UNO shield layout helps hold it really secure on to the Zumo shield. I did make one small modification to the ASC+ itself in order to make the 'reset' button top accessible. When working as a lead robot inspector for FIRST, I always talk about how the KILL SWITCH should be easy to find for anyone. So now if this thing is running off the table someone else can help quickly stop it... or pick it up.
Phase 1 objective: "Build a robot that goes from one end of a table to the other and back"
The propeller's powerful multi cog design has really come through for me given my limited programming skills. It allows me to kick off items in the background cogs and reference variables rather than worry about interrupts and exact timings.
With my Zumo Object built out, the actual SPIN program was very straight forward. The video is running at quarter speed (250 of 1000). I have it set for 800 now, however I need to dial in the sensor a bit to keep from zipping off the end of the table.
[video=youtube_share;0kegBM6dUOY]
I have a sonar sensor to add and a couple of AdaFruit RGB LED NeoPixel strips to add next.
BTW - in order to rebuild the Zumo after the button work done in prior posted, I moved the pull-up resister to the top side of the shield. In the end, taking the Zumo apart was a waste of time... bummer. However I have a better idea now for zumo 2 with wheel encoders like this.
Challenge 2 was to find a block, push it off table and not fall off (built upon prior challenge). The neat part was to see how other accomplished this. For example, my solution was brute force, another's was cartesian based (he shared his code, I am still digesting it...) and a Lego Mindstorm.
Sensors added: Maxbotix MB1010 (sonar), Sharp GP2Y0D810 (IR), 2x QTI (IR). With the exception of laser or radar I ended up with the several common non-contact object defection devices.
Why so many sensors? The problem was time to get it working -vs- brute force strategy -vs- minimum sensor distance reporting limitations. I didn't buy all of these sensors at once, more or less it was sensor creep as found the limitation of each sensor, I added another one to compensate.
The Maxbotix provides Sonar object detection with reported minimum measurement of 6in while providing distance from 6 to 200+. I could find the block and track it provided I was greater than 6 inches from it, getting closer than 6 it would appear to the block was missed (this is due in part to the angle I mounted it, is above angled down rather than straight on). Also if I had encoders and knew I was straight on I could find it then drive to it. However within 6 inches of travel, in testing depending on battery voltage the bot would head left or right and miss the block.
The Sharp sensors had an effective range down to ~.7 inches reporting True or False, no distance. When the Maxbotix reported 6 inch, the bot began tracking with the Sharp adjusting the motors to keep the object in sight. Again due to angle the object detection was clear if the bot had contact yet with the object.
The QTI sensors were downward facing just above the block. Once the bot touches the block the QTI sensors would detect it. I considered at contact sensors, given I didn't want to modify the front blade on the bot so the non-contact QTI worked well; also at this point I had QTIs already on hand, didn't have a suitable switch to use as a whisker contact.
The end result was a series of SPIN methods invoked each sensor depending on how far from the bot the block was. This worked with about 85% (WAG) reliability. Issues came up when other objects not on the table were detected - ie people.
I now have a variety of non-contact object detection sensors in my parts bin to play with in the future. Given that I found limitations while attempting to apply them, my future designs will perhaps take that into consideration...!?!