I just noticed that I neglected to put pull-up resistors on the S3 hacker port digital IO's (P5-P0). I removed the logic level convertor on the new design and put a straight connection to the Propeller through a 330 ohm resistor with a 3.0V zener clamp. The S2 had the I2C style bidirectional logic level convertors which required a pull-up on the output.
What do you guys think, are the pull-up's needed? I would probably put something pretty weak, maybe 47K if I were to include them.
-Ben
BTW I was pretty pleased that one of the built-in self test routines caught the error automatically.
I believe that Phil Pilgrim had found a fix for the Ping problem but it was part of the reason we decided to remove the logic level convertors from the S3. -Ben
I believe that Phil Pilgrim had found a fix for the Ping problem but it was part of the reason we decided to remove the logic level convertors from the S3. -Ben
This is want I recall also. I had damaged my Ping so I haven't tried Phil's fix myself.
I think I'd prefer no pull-up resistors on the hacker port but I don't have a strong opinion about this.
@Mikhail, You probably should start a new thread with the S2 GUI issues. Phil Pilgrim wrote the S2 GUI and he is usually quick to respond to S2 issues. I'm not sure how closely he is following this thread.
This is want I recall also. I had damaged my Ping so I haven't tried Phil's fix myself.
I think I'd prefer no pull-up resistors on the hacker port but I don't have a strong opinion about this.
@Mikhail, You probably should start a new thread with the S2 GUI issues. Phil Pilgrim wrote the S2 GUI and he is usually quick to respond to S2 issues. I'm not sure how closely he is following this thread.
I believe that Phil Pilgrim had found a fix for the Ping problem but it was part of the reason we decided to remove the logic level convertors from the S3. -Ben
Are there plans to have hacker port functionality built directly into whatever the new "S3 GUI" ends up being? In other words, in the drag and drop GUI, will there be things like a PWM block that can be sent to one of the IO pins on the hacker port?
I'm not the GUI guy but I can't think of any reason why this wouldn't be possible but it's definitely not easy either. An alternative idea would be rather than trying to make a bunch of different generic IO blocks we could try to make a container block which would be linked to an external spin object file. This way the GUI would just have include the SPIN object and call it appropriately. I'm sure users would quickly write objects for the various hardware such as the Ping and servos. It's still non-trival but at least this would a scalable approach.
Are there plans to have hacker port functionality built directly into whatever the new "S3 GUI" ends up being? In other words, in the drag and drop GUI, will there be things like a PWM block that can be sent to one of the IO pins on the hacker port?
I tested a dozen different 18650 and 26650 cells during the S3 development since we were initially looking at these as a battery option. None of the 18650 cells had more than a 2200 mAhr capacity despite being rated at 3 times that in some cases and most had closer to 1800 mAhr. I believe the 26650's are just a 18650 in a a larger package since they had almost the same rating as the 18650. You are right to be skeptical -Ben
I'm not the GUI guy but I can't think of any reason why this wouldn't be possible but it's definitely not easy either. An alternative idea would be rather than trying to make a bunch of different generic IO blocks we could try to make a container block which would be linked to an external spin object file. This way the GUI would just have include the SPIN object and call it appropriately. I'm sure users would quickly write objects for the various hardware such as the Ping and servos. It's still non-trival but at least this would a scalable approach.
-Ben
@Ben - If I understand what you are saying, you are suggesting a (or set of) user definable tiles in the GUI that would insert a user written spin object into the GUI program. Per Andrew's comment above - the user could write a PWM tile (maybe even labeled graphically on the tile in a section of user written tiles), drag it into the program for instance.
The biggest issue I see is that the GUI keeps starting programmers from doing things that are not logical or out of order programming wise. If a user could define a tile that could be inserted, I don't know how this would work. Maybe I don't understand well enough. I think the idea would be great and I love the idea!
It would be a great transition to writing bits of code in spin and would make a great lesson/tutorial to use with the GUI and perhaps with the GUI becoming more like an app - the feature could be developed later.
Am I understanding the basic idea you are talking about?
Here's the rough idea. There would be a pair of sub-directories in which a user could place custom spin objects and optionally a *.png file with the same root name as the spin object. The spin objects would fall into one of two very narrowly defined classes, custom conditionals and custom actions. Conditional objects either return a true or false and have an optional parameter. Actions also have an optional parameter and return nothing.
The current yellow conditional blocks would be expanded to include selection of the custom conditional objects. If conditional objects exists in the directory, the GUI would let the user pick one of them. If the *.png exists, it would be displayed as an icon if not a default icon like a question mark would be displayed. The name of the spin input object is shown as well. The GUI would insert the custom spin code in the same way that it does for the existing blocks. If object has an input parameter, then a unit-less slider is displayed. For example, a ping object would allow the user to set the range with the slider and would then branch depending on whether an obstacle was detected within that range.
A custom green action block would be added to support the custom action objects. It would have an optional slider to allow the user to set the PWM duty cycle or the position of a servo connected to the hacker port.
If a teacher didn't want to introduce this additonal complexity to their classes, they could just delete all of the custom conditional and custom action objects from the directory and they wouldn't be available to the students. This is very expandable and as you point out Whit could also possibly help users transition to spin. Of course we could make this much more complex but I would advocate for keeping it as simple as possible since even the simple version is very powerful. We would also impose restrictions on the custom object like they aren't allowed to drive the motor IO pins directly, only through calls to the S2 object. I'm sure there are additional complexities which I haven't considered but its seems like a neat idea on the surface to me. With the exposed hacker port on the S3, I think there would be quite a bit of interest.
@Ben - If I understand what you are saying, you are suggesting a (or set of) user definable tiles in the GUI that would insert a user written spin object into the GUI program. Per Andrew's comment above - the user could write a PWM tile (maybe even labeled graphically on the tile in a section of user written tiles), drag it into the program for instance.
The biggest issue I see is that the GUI keeps starting programmers from doing things that are not logical or out of order programming wise. If a user could define a tile that could be inserted, I don't know how this would work. Maybe I don't understand well enough. I think the idea would be great and I love the idea!
It would be a great transition to writing bits of code in spin and would make a great lesson/tutorial to use with the GUI and perhaps with the GUI becoming more like an app - the feature could be developed later.
Am I understanding the basic idea you are talking about?
@Ben - Thanks for the detailed response Ben! Sounds really fun to me and a great way for a student to dip their toe in the water! Especially if a few detailed lessons were written that could be followed mechanically.
@Mikhail - Parallel processes are going on under the GUI, they just happen in a sort of hidden way - Less experienced users just aren't made aware of what is going on. (Hope I am understanding what you are saying...)
@Mikhail - Parallel processes are going on under the GUI, they just happen in a sort of hidden way - Less experienced users just aren't made aware of what is going on. (Hope I am understanding what you are saying...)
I meant about the following (see figure): the robot moves 5 seconds with a sound. After that stops, the sound stops.
One of the new features of the S3 is the ability for the robot to turn itself off so I added a fun little routine to the S3 default program. After the battery is fully discharged, it plays Taps as it powers off.
One of the new features of the S3 is the ability for the robot to turn itself off so I added a fun little routine to the S3 default program. After the battery is fully discharged, it plays Taps as it powers off.
Cool Ben!
Edit - @Ben - Is that a 3D printed S3 body? How accurate is the color?
Edit 2 - Went back and saw that this was most likely done on a SLA printer... Is the other case opening just for your use at the moment?
Yes, the top half is an SLA print as you guessed and the bottom half is a painted S2. The color isn't representative, it's just what I had on the shelf in the shop. I'm pretty sure that we have settled on Pantone Q510-1-1 as the color reference chip for the molder. That hole is a temporary one to make room for the ribbon connector which was interfering, I've moved it forward for the next PCB rev to fix that.
I also finished my testing on the new big battery and I measured a run time at over 7 hours with the S3 randomly driving on the tread mill with an Xbee installed. I'm pretty happy with those results. It's probably a couple of days of use in practice. Program downloading via WiFi is also a real pleasure. RAM programming is nearly instantaneous. I actually didn't believe it could be that fast the first time I saw it
Comments
@Ken - and what a fine robot the S2 has been. I look forward the learning and loving the S3!
As you know, I thought it would be hard to beat old blue!
What do you guys think, are the pull-up's needed? I would probably put something pretty weak, maybe 47K if I were to include them.
-Ben
BTW I was pretty pleased that one of the built-in self test routines caught the error automatically.
This is want I recall also. I had damaged my Ping so I haven't tried Phil's fix myself.
I think I'd prefer no pull-up resistors on the hacker port but I don't have a strong opinion about this.
@Mikhail, You probably should start a new thread with the S2 GUI issues. Phil Pilgrim wrote the S2 GUI and he is usually quick to respond to S2 issues. I'm not sure how closely he is following this thread.
Here's Phil's work on that:
http://forums.parallax.com/showthread.php/141850-S2-Ping)))-Object-and-a-FREE-Offer
Sorry to derail the thread, but I think it's pertinent as to using translator or not.
The Qty 9, 330 Ohm resistors add 9 to the total.
-Ben
Hint - the total is somewhat less than the often quoted 6 million components in a Boeing 747.
Ben,
Do we have to count the total number of transistors in the Propeller?
-Ben
Then check this Ebay listing for 5800 mA out of a cheap Li-Ion 18650! I'm highly skeptical...
http://www.ebay.com/itm/5800-mAh-3-7V-2-BATTERY-1-CHARGER-USA-18650-Mechanical-Vape-Mechanical-MOD-/391051135796
@Ben - If I understand what you are saying, you are suggesting a (or set of) user definable tiles in the GUI that would insert a user written spin object into the GUI program. Per Andrew's comment above - the user could write a PWM tile (maybe even labeled graphically on the tile in a section of user written tiles), drag it into the program for instance.
The biggest issue I see is that the GUI keeps starting programmers from doing things that are not logical or out of order programming wise. If a user could define a tile that could be inserted, I don't know how this would work. Maybe I don't understand well enough. I think the idea would be great and I love the idea!
It would be a great transition to writing bits of code in spin and would make a great lesson/tutorial to use with the GUI and perhaps with the GUI becoming more like an app - the feature could be developed later.
Am I understanding the basic idea you are talking about?
Here's the rough idea. There would be a pair of sub-directories in which a user could place custom spin objects and optionally a *.png file with the same root name as the spin object. The spin objects would fall into one of two very narrowly defined classes, custom conditionals and custom actions. Conditional objects either return a true or false and have an optional parameter. Actions also have an optional parameter and return nothing.
The current yellow conditional blocks would be expanded to include selection of the custom conditional objects. If conditional objects exists in the directory, the GUI would let the user pick one of them. If the *.png exists, it would be displayed as an icon if not a default icon like a question mark would be displayed. The name of the spin input object is shown as well. The GUI would insert the custom spin code in the same way that it does for the existing blocks. If object has an input parameter, then a unit-less slider is displayed. For example, a ping object would allow the user to set the range with the slider and would then branch depending on whether an obstacle was detected within that range.
A custom green action block would be added to support the custom action objects. It would have an optional slider to allow the user to set the PWM duty cycle or the position of a servo connected to the hacker port.
If a teacher didn't want to introduce this additonal complexity to their classes, they could just delete all of the custom conditional and custom action objects from the directory and they wouldn't be available to the students. This is very expandable and as you point out Whit could also possibly help users transition to spin. Of course we could make this much more complex but I would advocate for keeping it as simple as possible since even the simple version is very powerful. We would also impose restrictions on the custom object like they aren't allowed to drive the motor IO pins directly, only through calls to the S2 object. I'm sure there are additional complexities which I haven't considered but its seems like a neat idea on the surface to me. With the exposed hacker port on the S3, I think there would be quite a bit of interest.
-Ben
@Mikhail - Parallel processes are going on under the GUI, they just happen in a sort of hidden way - Less experienced users just aren't made aware of what is going on. (Hope I am understanding what you are saying...)
I meant about the following (see figure): the robot moves 5 seconds with a sound. After that stops, the sound stops.
The S2 is doing things in a parallel way - using multiple cogs - even though the GUI may not make that know in a visual manner - as I understand it.
https://www.youtube.com/watch?v=6cmyQqTFHhI
-Ben
Cool Ben!
Edit - @Ben - Is that a 3D printed S3 body? How accurate is the color?
Edit 2 - Went back and saw that this was most likely done on a SLA printer... Is the other case opening just for your use at the moment?
Yes, the top half is an SLA print as you guessed and the bottom half is a painted S2. The color isn't representative, it's just what I had on the shelf in the shop. I'm pretty sure that we have settled on Pantone Q510-1-1 as the color reference chip for the molder. That hole is a temporary one to make room for the ribbon connector which was interfering, I've moved it forward for the next PCB rev to fix that.
I also finished my testing on the new big battery and I measured a run time at over 7 hours with the S3 randomly driving on the tread mill with an Xbee installed. I'm pretty happy with those results. It's probably a couple of days of use in practice. Program downloading via WiFi is also a real pleasure. RAM programming is nearly instantaneous. I actually didn't believe it could be that fast the first time I saw it
-Ben
I tried to look up the Pantone Color, but could not find it. Will look more later.
I appreciate all that you and Parallax are sharing about the new S3 and the process by which it is being created. Can't wait for a test drive!