Stingray Plans - question for Ken

Lev

Hi Ken:

I am posing this question in a new thread because I didn't want to hijack the new PropBOE thread (which sounds awesome, BTW).

I appreciate the sincere open spirit that you express in the new Prop BOE thread. In the same spirit, can you share the future plans for the Stingray with all of us loyal users? There has been a shortage of accessories and information over the past year, and apparently many of us (me for sure) purchased the Stingray in anticipation of future accessories and support. Is anything happening? I am getting the feeling that the Stingray is being put into the back of a closet or on a high shelf at Parallax, so to speak.

I love mine, and hope the delay is just because you guys are so busy with other pressing projects.

Sincerely,
Lev

Oldbitcollector (Jeff)

This sounds like a wonderful opportunity to "open source" the spec for the Stingray. Then those who have the passion will press forward with it as it happening with the Spinneret.

Some cut specs on the panels would be excellent. (so that those of us who have one can cut additional matching panels. (plastics or wood) Also why not go ahead and "open source" the board as well? Most of the electronics are straightforward enough, but it shouldn't hurt sales as Parallax can have these made much cheaper than the hobbiest can build them at home. (At least at the high quality we expect from Parallax.)


oBC

Ken Gracey

Hey guys,

Just a quick post to let you know I'm not avoiding [well, a delay might as well be the same thing] a reply to the thread - I saw it the minute Lev made the post. Today the first two pallets of S2 robots arrive via 747 air cargo, so we need to welcome them to our family. After that's done I'll be back here to post our Stingray plan.

Indeed, we have a plan for the Stingray and we expect to raise it like the other robo-children at Parallax.

Will return shortly.

Thanks,

Ken Gracey

Oldbitcollector (Jeff)

OT - (sorry)

Ken

Any chance we could get a picture of all those S2s?

OBC

Ken Gracey

Oldbitcollector wrote: »

OT - (sorry)

Ken

Any chance we could get a picture of all those S2s?

OBC

They arrive in cardboard boxes, 4/box so it looks pretty boring at first glance. However, it could be more interesting when the 40' truck arrives with the remaining 20 pallets of S2s. I'll be sure to document whatever I can along the way.

Ken Gracey

Hanno

Hi Lev,
Thanks to the good work by Dave E., 12Blocks now supports Stingray.
Version 1.5.1 is here:
http://forums.hannoware.com/viewtopic.php?f=11&t=179&sid=02b9754636dd3fa1891be265f6104c76

12Blocks lets you program your Stingray with drag-n-drop ease. You can also monitor sensors with realtime graphs and change your program while it's running.
This Sunday I'm taking 2 teams to Robocup Jr Nationals- they did all their work with 12Blocks!
Hanno

Lev

@Ken - I look forward to hearing more when you get a chance. I figured you had a Stingray plan!

@Hanno - Thanks for the 12Blocks tip. I'll check it out in more detail. I am thinking it might make Stingray Prop programming a possibility for the freshmen/sophomores and those with less programming experience at my high school. What do you think? Are your teams HS or college level?

Lev

Hanno

Hi Lev,
12Blocks is being used by industry professionals, robot clubs, university classes, high schools and even primary schools. The robocup jr teams I mentor happen to be at the young end of the scale- six to fourteen years old.

My goal for 12Blocks is to lower the floor AND raise the ceiling for Propeller programming.

12Blocks makes it dramatically easier to program the Propeller:
- just drag blocks from library to worksheet- instead of remember arcane syntax like ~, := and !- or learning to spell things like clkfreq...
- objects, clock configuration, ports, stack is all handled for you
- tutorial mode that guides you through your first programs with "show me" function
- easily debug program by watching variables, graphing values, or using terminal
- drag-n-drop schematic editor/photo manager to share your project with others

You can take Propeller programming further with 12Blocks:
- advanced built in programming concepts: state machines, events
- build "front panel" interface for embedded devices
- api/dev kit
- inheritance/recursion/refactoring
- import/reuse existing spin/12b files
Hanno

Ken Gracey

Lev wrote: »

Hi Ken:

I am posing this question in a new thread because I didn't want to hijack the new PropBOE thread (which sounds awesome, BTW).

I appreciate the sincere open spirit that you express in the new Prop BOE thread. In the same spirit, can you share the future plans for the Stingray with all of us loyal users? There has been a shortage of accessories and information over the past year, and apparently many of us (me for sure) purchased the Stingray in anticipation of future accessories and support. Is anything happening? I am getting the feeling that the Stingray is being put into the back of a closet or on a high shelf at Parallax, so to speak.

I love mine, and hope the delay is just because you guys are so busy with other pressing projects.

Sincerely,
Lev

Hello Lev,

I truly thank you for your patience - today was the first opportunity I had to reply to the forum post. We have a small team to manage the Stingray in Parallax, and I asked them for our internal planning notes. We have changes and improvements underway for the Stingray, including hardware improvements and examples. Keep in mind that the following notes are for internal use only (er, then why share them on the forums?). There's no secret about this, really, and all of the input received is from our customers. We're putting this input to use to provide examples and add-on hardware. The first thing you'll see is a line-follower add-on which has been approved for production.

What if you already have a Stingray and you feel like your hardware is going to be obsolete by our improvements? We'll either discount the hardware or find another way to make sure you remain happy - just trust us on that for now until we're a bit closer.

Shown below is user feedback collected from the forums. This is exactly what we'll be using to plan our improvements.

These are the improvements you can expect from us most immediately:

(a) Lithium Ion battery upgrade with charging circuitry (proto done, in PCB design)
(b) Line follower product (approved for production)
(c) Documentation improvements (ongoing)
(d) Upgraded control board (being sketched out)

================================

FEEDBACK
• Motors too fast / geared too high. [Mechanical]

o The robot moves too fast to be practical and some motors have been damaged by sudden changes in speed, such as when the robot crashes.

• The current hole / slot pattern places the controller and bread board right on the center line. [Metal]

o Put slots or add holes for more board configurations and bring them in a bit for the handles.

• Phillips screws preferred over the hex screws currently used. [Mechanical]

o Customers don’t want to have to use special tools to assemble hardware. They’ve grown used to using the Parallax screwdriver included with the BOE-Bot.
o Some customers prefer thumbscrews that don’t require tools at all due to the prototyping nature of the robot.

• The battery pack is inaccessible inside the chassis. [Mechanical / Electrical]

o The most frequently accessed component should be more accessible. Many have moved the battery pack to the top deck or removed / modified sensor plates to make the batteries more accessible.

• AA Batteries not widely accepted on a robotic platform, especially due to the odd number required (charging). [Electrical]

o Most customers prefer standard R/C Battery packs instead of AA batteries.
o Do we provide the battery / charger or let the customer purchase this?

• Level Translators cause issues with some servos and interfacing of many standard circuits such as those in the PEK. [Electrical]

o The translators have several known issues and prevent customers from using the control board for general interfacing.
o The facilities for bypassing the translators are not populated making them useless to some customers.
o Too many I/O pins are run through the translators.
o Some pins that should be brought out are not, such as I2C bus.

• Lack of sample code / demos. [Documentation / Software]

o Current sample programs not on product page.
o Inconsistent naming between documentation and actual code filename.
o No demo code for any other peripherals (none exist).

• Request for standardization of use of the I/O pins for various hardware so that future accessories or code changes are compatible. [Documentation / Software]

o Objects need to be written in a manner such that, should a replacement object or third party object become available simply changing to the new object would be required. No code or wiring changes should be required.

• Suggestion for smaller wheels and / or to have the motors lower in the chassis raising the belly of the robot. [Metal / Mechanical]

o The robot sits low enough that it could get easily hung up on rough terrain of plush carpets.
o The original wheels were an inch smaller in diameter.

• Rename the Motor Connectors to L & R instead of A & B. Clarify polarity as well. [Electrical / Documentation]
o Customers aren’t sure of the polarity of the connectors nor which is left / right.
• Provide polarity indication for the DC Barrel Jack / Power Connector. [Electrical / Documentation]

o N/A

• Voltage Input Range is not clear / consistent. [Electrical / Documentation]

o The voltage range is listed as 6 to 15VDC, however it should be 6.5 to 10V.
o The voltage could be too high for the motors.
o The voltage range could be too high for the input capacitors.

• The pins / logic used to drive the motors should be changed to simply the code. [Software / Documentation]

o Currently the binary patterns driving the left / right motors are inconsistent.
o The same patterns should be used per motor / pin combination to simplify code.

• Power is still available on the VIN pins on the control board even when power is off. [Electrical]

o This is due to not using the power switch to switch the actual battery supply, but rather to enable / disable the switching regulator and H-Bridge.
o This also causes quiescent current draw which can drain the batteries even when the control board is OFF.

• There are no rubber grommets for the top plate or front sensor plates where the wires pass through the metal. [BOM / Documentation]

o The metal edges are sharper than the prototypes and some customers have expressed concern about this. Education also commented on this.

• No consistency between I/O and power headers. [Electrical]

o The I/O pins and power connections on those headers are male, however the independent power taps are female sockets.
o The power connectors do not include a ground connection.

• Write a book, “Robotics with the Stingray” but do not follow the BOE-Bot format. [Documentation]

o The documentation is fragmented at best and there should be enough content for a book.

• Charging circuit for the Stingray. [Electrical]

o A few people have asked about a charging circuit for the Stingray.
o I feel this is due to the odd number of batteries used and the need to charge in two steps.
o This problem could be solved by using a standard R/C battery since there are very inexpensive chargers sometimes packaged with the battery.

• Include some basic sensors with the Stingray so that it can do something useful out for the box without having to buy additional accessories. [BOM]

o Currently there are no sensors included that can do anything useful based on the speed of the Stingray.
• Remove the Molex connectors and replace them with Terminal Blocks. [Electrical]
o The Molex connectors are making it difficult for customers to use the control board by itself especially when connecting a custom power source.

• Make the Stingray platform available to BASIC Stamp customers. [BOM]

o Some customers want to use the BASIC Stamp rather than the Propeller.
o Using the BASIC Stamp instead of the Propeller would require any included sensors to be compatible with both platforms.
o Using the BASIC Stamp would require two HB-25 motor controllers since the BASIC Stamp boards do not have the facilities to drive the motors directly.

• Expansion connector for control board. [Electrical]

o Customers have requested a kind of expansion board for the control board so that additional circuits could be added directly to the Propeller circuitry. Think AppMod!
o A well thought-out design could make the board more powerful.
• Line following sensor for the Stingray. [Electrical / BOM]
o Customers are asking for an analog line following sensor like the one included on the 3Pi robot. Analog sensors have several advantages over their digital counterparts.

• The ratings for the current H-Bridge on the control board mean we’re operating it below its typical minimum voltage. [Electrical]

o A part from ROHM could be used in place, but of course would require a re-design of that entire section of the control board.

• There is no true specification / datasheet for the Stingray motors. [BOM]

o Some specifications provided don’t match what we have. It seems the real mechanical specifications are included in the SolidWorks data.
o Electrical specifications are sketchy.

• Include PING))) sensors with the Stingray. [BOM]

o Many customers feel the PING))) is an ideal sensor and should be included in the kit.
o Demo code would have to be included / supported.

• Include some servo cables for connecting accessories. [BOM]

o I think the cables should come with the accessories, but then the PING))) doesn’t come with a cable by default.

• Add video output to the Stingray. [Electrical]

o A few people have asked for this. I’m not sure how practical it would be.

• Add Sharp IR sensors to the kit. [BOM]

o This was looked into once before and the cost of the Sharp sensors was considerable. More than our BOM cost on the PING))) I believe.

• Practical Applications and Demos for the Stingray. [Resources]

o Several forum members and customers have asked for examples of various accessories such as GPS, Line Following, etc. including videos.
o This is simply a matter of lack of resources currently.
o Some of these items could and should be covered by the book if we decide to produce one.

• Wheel Encoders are required for the Stingray to go straight. [Electrical / BOM]

o Wheel encoders should have been provided before we released the Stingray.
o Samples from US Digital have already been tested with our motors.
o To do this cost effectively we will need our own PCB and encoder wheel.

• Adapter Board Ideas. [Electrical / BOM]

o Battery Charger / Monitor
o I2C Memory expander / accessory board.
o GPS / Compass board.
o LCD / uOLED

• Snap-Rings in the documentation referred to as O-Rings. [Documentation]

o This may have been corrected, but the documentation needs to be rewritten anyway.

Lev

Ken:

Thanks for the detailed review of the status. That answers all of my questions, then some. From my point of view, the list of 4 priorities is on the mark. Better documentation with some sensor interfacing examples would be great! I hope that the control board upgrade will fix the level shifter problems (with documentation), add a ground connection, and add an appmod connection. Personally, I don't care about grommets and screws, which are easily and inexpensively obtained hardware items, and I like the Molex connectors. The cables are easy to make. The Li battery upgrade sounds great.

I am most relieved to konw that the Stingray is an ongoing project at Parallax.

Sincerely,
Lev

jim N8RHQ

Power is still available on the VIN pins on the control board even when power is off. [Electrical]

o This is due to not using the power switch to switch the actual battery supply, but rather to enable / disable the switching regulator and H-Bridge.
o This also causes quiescent current draw which can drain the batteries even when the control board is OFF

Thank you Ken for explaining why my batteries went dead after sitting for a while with the power off.

Charging circuit for the Stingray.
o A few people have asked about a charging circuit for the Stingray.
o This problem could be solved by using a standard R/C battery since there are very inexpensive chargers sometimes packaged with the battery

AA Batteries not widely accepted on a robotic platform, especially due to the odd number required (charging).
o Most customers prefer standard R/C Battery packs instead of AA batteries.
o Do we provide the battery / charger or let the customer purchase this?

Stopped at Radio Shack on the way home tonight. Picked up the RS 23-322 RC Battery/Charger Combo Pack which includes 2000 mAh Ni-Cd battery. Also bought RS 23-319 3300 mAh Ni-MH battery for extended play er development time. Bought the RS 23-444 Connector repair kit to connect to the original power connector. Walked out $60 lighter and very happy.

jim

Ken Gracey

Hey Jim, these must be the 7.2V battery packs - the center of much discussion among our engineering staff. The other option we're pursuing is a Lithium Ion battery pack with a built-in charger circuit. This will be available as a 3x4 board and will provide similar capacity 2-3 amp-hours of power at 7.4V (I don't remember the exact specs). Your solution is also very appropriate.

Ken Gracey
Parallax Inc.

ratronic

Ken I am using a 5000mah 7.4V LiPo that retails for 24.70 from HobbyPartz. I also think the ping setup shown by Tony B. in this thread http://forums.parallax.com/showthread.php?123541-New-Take-on-Pings-for-the-Stingray is easy to install with parts you guys already sell and provides for easy obstacle detection.

Roy Eltham

If the MSR1 was modified to have screw terminals instead of the funky molex connection for the battery, you could ship one of these (standard female Tamiya connector) with the Stingray pretty cheaply, and it would let people use any standard R/C 7.2v battery pack (I have a dozen of them, and I'm sure most robot enthusiasts have at least one.).

Several Stingray owners (myself included) have made their own adapters from Tamiya to the molex connector or the barrel jack that are on the MSR1 board. There are posts about it around the forums here.

You could offer the Lithium battery with charger board as an add on or just a stand alone product. If it connected via the barrel jack, then it could be used to power other boards you sell as well, such as the Prop Proto Board or BASIC Stamp Super Carrier board.

Phil Pilgrim (PhiPi)

Ken,

An additional note regarding the MSR1 board, if it's to be modified: The power input and the motor driver and terminals are on opposite sides of the board. The way the board is laid out, the motor currents have to return across the entire board through the logic ground plane. In certain circumstances, this could really raise havoc with the logic operation of the board, and I would be surprised if certain mysterious transient issues have not already surfaced as a consequence. My recommendation would be either to move the power input terminals to the other side of the board and/or to provide a separate ground return for the motor currents, so they don't disrupt the logic stuff.

-Phil

Ken Gracey

Phil Pilgrim (PhiPi) wrote: »

Ken,

An additional note regarding the MSR1 board, if it's to be modified: The power input and the motor driver and terminals are on opposite sides of the board. The way the board is laid out, the motor currents have to return across the entire board through the logic ground plane. In certain circumstances, this could really raise havoc with the logic operation of the board, and I would be surprised if certain mysterious transient issues have not already surfaced as a consequence. My recommendation would be either to move the power input terminals to the other side of the board and/or to provide a separate ground return for the motor currents, so they don't disrupt the logic stuff.

-Phil

Thanks Phil - I've copied this thread to Chris Savage so we can update our MSR1 notes on the internal engineering planning web site. - Ken

sfs

It has been a while since this thread was last active, so I'm wondering about the status of the MSR1 board. I apparently purchased one of the very last ones last month and planned to use it with the Madeusa robot (I realize the motor outputs aren't needed unless I were to add additional non-drive motors). I'm interested in determining an appropriate battery/charger, which sounds like is in the works. I currently have a 12V 7Ah battery for running the motors, which sounds like may be too much voltage for the MSR1 (even though the specs for that board claim to handle up to 15V). Any suggestions or updates on the battery/charger circuit mentioned in this thread?

Matt Gilliland

Hey sfs and everybody else -


The Stingray is undergoing a re-vamp as we speak. New parts, accessories, it's in no danger of being discontinued.

See this post for Chris' explanation on the MSR1 controller.

It looks like it'll be available as a buffet, rather than a single entree. I'm working on some parts of it, but Chris S. is doing some stuff as well (see the above thread).

-Matt

sfs

jim N8RHQ wrote: »

Thank you Ken for explaining why my batteries went dead after sitting for a while with the power off.



Stopped at Radio Shack on the way home tonight. Picked up the RS 23-322 RC Battery/Charger Combo Pack which includes 2000 mAh Ni-Cd battery. Also bought RS 23-319 3300 mAh Ni-MH battery for extended play er development time. Bought the RS 23-444 Connector repair kit to connect to the original power connector. Walked out $60 lighter and very happy.

jim

Thanks for the advice! I've done the same ($21 7.2V 2000mAh Ni-Cd battery/charger, and $5 connector repair kit, and $1 molex connector/contacts from Mouser). I don't have much to report on beyond that, as I'm just getting started with the MSR1 controller (which was discontinued shortly after I got it!).