The sweet spot for Fall season school buying is between now and June (at least in the U.S.), so there is probably immediacy in getting the product ready...
If pin availability is a problem, why not use a shift register to expand it? This would allow more controllable LEDs and more inputs for encoders and buttons/bumpers.
The LEDs already use a shift register. In fact, it's not even a shift-and-store register; there wasn't even a spare pin for the store clock!
Anyway, I shouldn't be mentioning practicalities in an "envision" thread. It's just the engineer in me over-functioning! So keep on dreaming up new features; the cold slap of reality and the resulting triage can happen later.
The coordinate system is integer only, so a quadrature encoder would increase the resolution by four. That should mean more accurate circles due to lessening the effect of rounding.
IMO the resolution of the existing S2 is fine, the limiter is lots of backlash and wobble in the wheels. All that play must be tightened up before any encoder improvement will be noticed.
IMO the resolution of the existing S2 is fine, the limiter is lots of backlash and wobble in the wheels. All that play must be tightened up before any encoder improvement will be noticed.
There was an issue discussed a long time ago where the resolution was a limiting factor in getting arcs or circles to line up - moot point if the play is not removed from the wheels, but that is solvable.
GUI would need to be rewritten to accommodate a wider range of operating systems and hardware. We have strong interest in using MIT’s Scratch, Blocky, or Google's Chrome (which one is TBD based on many factors).
Where do you start improving an already outstanding S2 robot... (it is not that easy)
Just some Brainstorm ideas :-
(1) Keep the general original Chassis, Yellow is perfect.
(2) Make separate high riser circa 3cm Skirts (like NikosG mentioned) to sandwich in-between top/bottom half chassis with pushouts for display / Ping sensor. etc . Then even current S2 owners can upgrade. If this were to be made of clear_ish plastic then lighting effects possibilities
(3) Hacker port Hatch is a must. (With raw 3.3V signalling without pullUp/Down resistors)
(4) Some modification to the bottom chassis to secure the motors in place when the top lid is off (otherwise the motors just crash in when any internal work is being carried out) - I am always afraid that I will break the motor encoders, or crush wires each time I mod (which is often).
(5) Replace the AA batteries with Lipo/Lion giving possibility to charge off USB port. (I have already hacked my S2 to use the Laptop type 18650)
(6) Attach mounting points to top chassis to allow for stand-offs for platforms on top (ie. breadboard, display , arms etc)
(7) Wheels are Perfect ... maybe a consideration to use Steppers instead of GM motors.
(8) USB programming port, retire the Serial port.
(9) Why not have a USB host port ready for inserting a Bluetooth dongle (ie the cheap mini ones) ... I have done this effectively before using scanlimes system.
(10) Equipping it with a P2 is essential.
It be really nice if S3 had a display, 3-Axis Accelerometer, and 3-Axis Magnetometer. The servo mounted ping and grabber would require redoing the plastic significantly, which Ken said wasn't an option right now, but maybe for S4?
I backed them on kickstarter and should have mine in the next couple days.
The Sparki looks interesting. I went to their website and they are local to me. The robot uses the eBay steppers we've been playing with, so its similar to the Tiny Robot that Prof_Braino has been working on. Those motors are precise, but their torque is really low compared to the GM8 style motor the S2 has. I think their electronics are the more interesting part of their project because they might be reusable with a better drive train.
Update: I've been looking through the Sparki software and man is it crude. They're not even close to using the steppers up to their potential.
I suggest Parallax does some testing to see if the existing S2 body works any better upside down. It worked out well for this guy! Maybe the S3 could follow lines on the ceiling.
[[*]GUI would need to be rewritten to accommodate a wider range of operating systems and hardware. We have strong interest in using MITs Scratch, Blocky, or Google's Chrome (which one is TBD based on many factors). We could also delay the GUI re-design for a year.
Scratch seems like it would be nice. I haven't heard of Blocky. Guess I should look it up. Why would you want to delay the GUI re-design for a year? Wouldn't want it to be available when the S3 is introduced?
[
[*]GUI would need to be rewritten to accommodate a wider range of operating systems and hardware. We have strong interest in using MITs Scratch, Blocky, or Google's Chrome (which one is TBD based on many factors). We could also delay the GUI re-design for a year.
Scratch seems like it would be nice. I haven't heard of Blocky. Guess I should look it up. Why would you want to delay the GUI re-design for a year? Wouldn't want it to be available when the S3 is introduced?
There's this from Ken's original post:
With all of this in mind, design revisions must be determined and incorporated a year before we expect a new model.
But I don't see how you can't start development of a new GUI as soon as you get the hardware changes settled. This is even more true if you change to Scratch. Blocky or some other language base. This work will take a considerable amount of time and you want the new robot, GUI and documentation and tutorials all to be ready at the same time.
But I don't see how you can't start development of a new GUI as soon as you get the hardware changes settled. This is even more true if you change to Scratch. Blocky or some other language base. This work will take a considerable amount of time and you want the new robot, GUI and documentation and tutorials all to be ready at the same time.
[/FONT]
Also, couldn't a new GUI be used with the S2 robot as well? No need to wait for the S3.
Scratch seems like it would be nice. I haven't heard of Blocky. Guess I should look it up. Why would you want to delay the GUI re-design for a year? Wouldn't want it to be available when the S3 is introduced?
Scratch requires Adobe Flash.
I'm the one who suggested waiting a year. The reason is simple: there's so much new happening in the HTML5/Javascript world right now that better tools are surely on the very near horizon. I'm not convinced that any of the currently available tools are optimal. IMO, Google's Chrome Apps come closest, but they're semi-proprietary.
I'm the one who suggested waiting a year. The reason is simple: there's so much new happening in the HTML5/Javascript world right now that better tools are surely on the very near horizon. I'm not convinced that any of the currently available tools are optimal. IMO, Google's Chrome Apps come closest, but they're semi-proprietary.
-Phil
Having to drag in Adobe Flash does seem like a bit of a disadvantage. I can understand why you'd want to wait for a better solution. What about just porting the existing S2 IDE to Mac and Linux? Both have Perl available. Or do you want a browser-hosted solution?
What about just porting the existing S2 IDE to Mac and Linux? Both have Perl available. Or do you want a browser-hosted solution?
The GUI uses Perl/Tk. The original Scribbler GUI actually was ported to Linux running under X Windows (not by me), and I assume the S2 GUI could be as well. OS/X -- the more important target -- is a problem, because Perl/Tk will not run natively under OS/X; it requires an X Windows shell, which no longer comes pre-installed on Macs. There was an attempt to rewrite Per/Tk to link with the OS/X-native Tcl/Tk API, but it is incomplete and somewhat buggy -- not ready for primetime. Moreover, there are Windows-specific Perl modules involved for sound and serial I/O that have to be rewritten. My attempt a year ago to overcome these obstacles got hopelessly bogged down, and I gave it up for the time being.
For all input received I have noted below whether or not it would be required, considered or not likely by Parallax. Of course, this should be looked at in conjunction with this forum thread, which provides excellent technical contributions.
The next steps for Parallax with this effort are:
Take it to Ben Wirz (Element) for discussion, financial consideration, and timing
Return on Investment analysis, which would be an update of prior efforts (Ive tracked this project well since inception)
Decision by end of March (Q1, according to internal schedule)
It is possible that we continue ordering the S2, too, and upgrade the GUI using Scratch 2.0 Extensions or some other tool with out hardware improvements. Phil Pilgrim has bowed out of all future GUI work so this effort would become an open opportunity for a qualified developer.
I hope to report back with our next steps by the end of March, after I get a feeling for the price of the key improvements, with consideration to customer need, non-recurring engineering costs, bill of material costs, and time. Because each feature has tradeoffs with these variables it's not going to be clear until we know about the actual cost of each one.
Any input? Please share, of any type though I think Ive uncovered every possibility around this robot.
Thank you very much for all of your contributions.
Ken Gracey
Parallax Inc
Comment Required Possible Not Likely
Physical/Mechanical
Yellow body color
x
Graphite / black body color
x
x
Higher speed
x
Quadrature encoders
x
Removable hatch for I/O access
x
Mounting holes for Ping))) or other external sensors
x
Pen lifter accessory (or support for quick upgrade)
x
Sleeve or expansion deck
x
Electronics
Remove microphone
x
Add breadboard area
x
Redesign shifter-level circuitry for Ping/sensor support
x
Add power jack for charging
x
x
USB support
x
x
Propeller 2
x
Graphical User Interface
Mac, Windows Linux compatibility (open source)
x
Volume control
x
Toggle between C and GUI code
x
Retain current style of GUI
x
Provide support for microphone
x
MIT Scratch 2.0 Extension support
x
Add pen up/down control
x
Programming Interface
Bluetooth LE or WiFi [or]
x
USB
x
Xbee connector for WiFi or RF comms/programming
x
Power Supply
Rechargeable battery supply (Li-on cells with capacity)
x
x
Curriculum
Finalize and expand the Neil Rosenberg curriculum
x
Pen lifter, microphone, improved sound support
x
Additional
Properly release all files
x
Speak with educators who are using the S2
x
Keep cost down, maybe even lower than it is
x
x
Use Fluke or other add-ons for modularity that costs
x
x
Great work, Mr. President! (Talkin' 'bout the Red White & Blue-Tooth... I just love that Honda commercial.)
May be too late, but one more request: Add 4-8 screw bosses on top. Minor tooling mods, make them flush on top so only a 3/32" hole is visible from the outside, a bit more meat inside. That way, future boards or add-ons could be designed around the defined hole pattern.
Just for a lateral idea ..... here is a skirt i am making for my S2 details here "Mini Skirts"
Basic idea to make the division between the top and bottom S3 chassis "Hacker Friendly" the S2 is almost hacker friendly .
I am using Magnetic mounts to attach the shell together :-
Comments
Or just use the P2!
EDIT: Err, um, for 'next year'...
dgately
Anyway, I shouldn't be mentioning practicalities in an "envision" thread. It's just the engineer in me over-functioning!
I don't think we want this, though.
But, saaay! Fire engine chartreuse!
-Phil
IMO the resolution of the existing S2 is fine, the limiter is lots of backlash and wobble in the wheels. All that play must be tightened up before any encoder improvement will be noticed.
http://forums.parallax.com/showthread.php/153652-S2-Parallax-Scribbler-UV-series...-Part-3-of-5-Chinese-Brush-Strokes-quot-Eternity-quot
There was an issue discussed a long time ago where the resolution was a limiting factor in getting arcs or circles to line up - moot point if the play is not removed from the wheels, but that is solvable.
-Phil
Just some Brainstorm ideas :-
(1) Keep the general original Chassis, Yellow is perfect.
(2) Make separate high riser circa 3cm Skirts (like NikosG mentioned) to sandwich in-between top/bottom half chassis with pushouts for display / Ping sensor. etc . Then even current S2 owners can upgrade. If this were to be made of clear_ish plastic then lighting effects possibilities
(3) Hacker port Hatch is a must. (With raw 3.3V signalling without pullUp/Down resistors)
(4) Some modification to the bottom chassis to secure the motors in place when the top lid is off (otherwise the motors just crash in when any internal work is being carried out) - I am always afraid that I will break the motor encoders, or crush wires each time I mod (which is often).
(5) Replace the AA batteries with Lipo/Lion giving possibility to charge off USB port. (I have already hacked my S2 to use the Laptop type 18650)
(6) Attach mounting points to top chassis to allow for stand-offs for platforms on top (ie. breadboard, display , arms etc)
(7) Wheels are Perfect ... maybe a consideration to use Steppers instead of GM motors.
(8) USB programming port, retire the Serial port.
(9) Why not have a USB host port ready for inserting a Bluetooth dongle (ie the cheap mini ones) ... I have done this effectively before using scanlimes system.
(10) Equipping it with a P2 is essential.
Ciao Gareth
The yellow/black thing comes up once in a while on other threads. How can Dewalt tradmark that?
See bottom of this page:
http://www.dewalt.com/tools/Power-Tools.aspx
-Phil
Note the feature list and price.
It be really nice if S3 had a display, 3-Axis Accelerometer, and 3-Axis Magnetometer. The servo mounted ping and grabber would require redoing the plastic significantly, which Ken said wasn't an option right now, but maybe for S4?
I backed them on kickstarter and should have mine in the next couple days.
The Sparki looks interesting. I went to their website and they are local to me. The robot uses the eBay steppers we've been playing with, so its similar to the Tiny Robot that Prof_Braino has been working on. Those motors are precise, but their torque is really low compared to the GM8 style motor the S2 has. I think their electronics are the more interesting part of their project because they might be reusable with a better drive train.
Update: I've been looking through the Sparki software and man is it crude. They're not even close to using the steppers up to their potential.
John Abshier
There's this from Ken's original post:
But I don't see how you can't start development of a new GUI as soon as you get the hardware changes settled. This is even more true if you change to Scratch. Blocky or some other language base. This work will take a considerable amount of time and you want the new robot, GUI and documentation and tutorials all to be ready at the same time.
You would think, just don't 'hard code' the color value!
I'm the one who suggested waiting a year. The reason is simple: there's so much new happening in the HTML5/Javascript world right now that better tools are surely on the very near horizon. I'm not convinced that any of the currently available tools are optimal. IMO, Google's Chrome Apps come closest, but they're semi-proprietary.
-Phil
-Phil
That right there gets my vote for "wait a year"!!
Well, there are 'some' great tools already. Perhaps Hype could help in developing a GUI.
http://www.macworld.com/article/2097421/hype-2-5-review-tumults-love-letter-update-to-its-users-is-a-triumph.html
The developer is very interested in how Hype is used and the needs of developers...
dgately
-Phil
For all input received I have noted below whether or not it would be required, considered or not likely by Parallax. Of course, this should be looked at in conjunction with this forum thread, which provides excellent technical contributions.
The next steps for Parallax with this effort are:
- Take it to Ben Wirz (Element) for discussion, financial consideration, and timing
- Return on Investment analysis, which would be an update of prior efforts (Ive tracked this project well since inception)
- Decision by end of March (Q1, according to internal schedule)
It is possible that we continue ordering the S2, too, and upgrade the GUI using Scratch 2.0 Extensions or some other tool with out hardware improvements. Phil Pilgrim has bowed out of all future GUI work so this effort would become an open opportunity for a qualified developer.I hope to report back with our next steps by the end of March, after I get a feeling for the price of the key improvements, with consideration to customer need, non-recurring engineering costs, bill of material costs, and time. Because each feature has tradeoffs with these variables it's not going to be clear until we know about the actual cost of each one.
Any input? Please share, of any type though I think Ive uncovered every possibility around this robot.
Thank you very much for all of your contributions.
Ken Gracey
Parallax Inc
Comment
Required
Possible
Not Likely
Physical/Mechanical
Yellow body color
x
Graphite / black body color
x
x
Higher speed
x
Quadrature encoders
x
Removable hatch for I/O access
x
Mounting holes for Ping))) or other external sensors
x
Pen lifter accessory (or support for quick upgrade)
x
Sleeve or expansion deck
x
Electronics
Remove microphone
x
Add breadboard area
x
Redesign shifter-level circuitry for Ping/sensor support
x
Add power jack for charging
x
x
USB support
x
x
Propeller 2
x
Graphical User Interface
Mac, Windows Linux compatibility (open source)
x
Volume control
x
Toggle between C and GUI code
x
Retain current style of GUI
x
Provide support for microphone
x
MIT Scratch 2.0 Extension support
x
Add pen up/down control
x
Programming Interface
Bluetooth LE or WiFi [or]
x
USB
x
Xbee connector for WiFi or RF comms/programming
x
Power Supply
Rechargeable battery supply (Li-on cells with capacity)
x
x
Curriculum
Finalize and expand the Neil Rosenberg curriculum
x
Pen lifter, microphone, improved sound support
x
Additional
Properly release all files
x
Speak with educators who are using the S2
x
Keep cost down, maybe even lower than it is
x
x
Use Fluke or other add-ons for modularity that costs
x
x
May be too late, but one more request: Add 4-8 screw bosses on top. Minor tooling mods, make them flush on top so only a 3/32" hole is visible from the outside, a bit more meat inside. That way, future boards or add-ons could be designed around the defined hole pattern.
Basic idea to make the division between the top and bottom S3 chassis "Hacker Friendly" the S2 is almost hacker friendly .
I am using Magnetic mounts to attach the shell together :-