RFC: Stingray/MRS1 Standard 0.01 Configuration Protocol
Purpose: To set a standard wiring protocol to enhance the exchange of StingRay code.
0: Left Ping
1: Center Ping
2: Right Ping
3:Wheel_Encoder_Left_A······
4:Wheel_Encoder_Left_B
5:Wheel_Encoder_Right_A
6:Wheel_Encoder_Right_B
7:Wheel_Encoder_Circuit_Enable
8:LCD
9:MemKey
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:Left Motor +
25:Left Motor -
26:Right Motor +
27:Right Motor -
28:
29:
30:PST
31:PST
Just an attempt to throw something out for all to think about, I would appreciate any input.
rpdb
·
0: Left Ping
1: Center Ping
2: Right Ping
3:Wheel_Encoder_Left_A······
4:Wheel_Encoder_Left_B
5:Wheel_Encoder_Right_A
6:Wheel_Encoder_Right_B
7:Wheel_Encoder_Circuit_Enable
8:LCD
9:MemKey
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:Left Motor +
25:Left Motor -
26:Right Motor +
27:Right Motor -
28:
29:
30:PST
31:PST
Just an attempt to throw something out for all to think about, I would appreciate any input.
rpdb
·
Comments
Packing everything together like that seems less desirable to me. For example, I want to have 1-2 more pings on the back of my Stingray and I'd rather they were in pins 3 and 4. So that's part of why I put the encoders on 8-11, to leave room for more ping sensors and possibly ir sensors or just bumper switches in the first bank of 8 pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Also, why do you need an encoder enable? If you're going to dedicate the pins to the encoders can't you just ignore the data if you don't want it?
Finally, I don't think there can be much standardization on pin usage. What about wireless, bumpers, HID, ADCs, infrared (line sensors), camera, servos, gps, and other sensors? There are a plethora of choices that a user might choose from. What might be better is a clearly defined constants section (for demo code) or functions that take pin numbers (for objects).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Powered by enthusiasm
I think a more usefull "standard" might be developed along the lines of what SRLM just suggested by using a standard set of named constants to be used in demo code and then leave it to each user to assign pin numbers that he/she thinks are appropriate. This·was done to some degree in the "Pings on a Stingray" code for the motor·pin pairs:·LEFT_MOTOR = 24 and RIGHT_MOTOR = 26. The same could ge done for one or more PING sensors, i.e. PING1_SIG = 0, PING2_SIG = 1, PING3_SIG = 2, etc. Using constant names from that list in demo code would greatly improve the readability and consistancy of shared code.
Having said all that, I still think that the most important part of writing code that you intend to share is documentation and comments. For example, if you're using 10 PING sensors on your bot, the code·docs section should make it clear how the PINGs are referenced, i.e. "PING0_SIG is on pin zero and the PING sensors are numbered counter-clockwise relative to the front of the robot".
I would also like to second Roy's suggestion for the order of attaching quadrature encoder inputs. That arrangement greatly simplifies coding in closed loop systems (and the encoders that I use don't have an enable circuit).
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
How about including a description for documentation something like this:
''StartStop Template.spin {{ These are the I/O assignments I used in this code: 0: Left Ping 1: Center Ping 2: Right Ping 3: Wheel_Encoder_Left_A 4: Wheel_Encoder_Left_B 5: Wheel_Encoder_Right_B 6: Wheel_Encoder_Right_A 7: Wheel_Encoder_Circuit_Enable 8: LCD 9: MemKey 10: 11: 12: 13: 14: 15: 16:Back_up_Alarm 17: 18: 19:Flux_Capacitor_enable 20: 21: 22: 23: 24: Left Motor + 25: Left Motor - 26: Right Motor + 27: Right Motor - 28: EEPROM 29: EEPROM 30: PST 31: PST }} VAR long cog ' Cog flag/id long stack[noparse][[/noparse]50] ' Declare stack space PUB Start(param) : okay {{Explain what process gets launched into a new cog. Parameters: param1 - If there is one or more parameter, explain what each one represents. Returns : True (non-zero) if cog started, or False (0) if no cog is available.}} stop okay := cog := cognew(CogMethod(param), @stack) + 1 PUB Stop {{Indicate what process gets stopped; frees a cog.}} if cog cogstop(cog~ - 1) PUB CogMethod(param)  Save this file under a new name  Replace this method with yours  Then, update method call in Start methodJust another thought thrown out for discussion...
Post Edited (rpdb) : 2/7/2010 9:43:17 AM GMT
I like the declaration idea or "description for documentation" as you call it. Let me know if you get pin 19 functioning correctly...Somethng really has to be done about my friend Marty's kids.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
p0 = right_ping
p1 = center_ping
p2 = left_ping
I think what Bocephus shows is more logical, it will just depend on how the code is written. That is why I like the suggestion of the documentation up front in the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Post Edited (Whit) : 2/8/2010 5:12:10 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Powered by enthusiasm
This isn't a boat. :P
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
To use this code with other wiring arrangements, all that have to change are the constants. A well-written program will not rely upon any assumptions about pin assignments.
-Phil
'Read sensors
Left := Distance[noparse][[/noparse] 1 ] * RISK_FACTOR <# Distance[noparse][[/noparse] 2 ] * RISK_FACTOR
They use pin numbers instead of variables like Distance[noparse][[/noparse] center_ping ].
But, I guess that why I wanted to open this thread, just to throw ideas out to see what the community thinks and to see if there is a "boat" that all could agree to be "on-board" to facilitate less confusion, or if it is .
I like what Phil said about "A well-written program will not rely upon any assumptions about pin assignments". "LFT_PING = 0" makes perfect sense and makes the code that is then so self-documenting ie distance[noparse][[/noparse]LFT_PING] as opposed to distance[noparse][[/noparse]1], which requires checking the declarations again. Long descriptive var names instead of x=, just make reading the code almost intuitive.
Many members of these forums are new to this stuff, myself included, so the documentation is key to helping each other out and encouraging sharing of code samples.
Andy Lindsay gave me the start/stop template during an educators class for propellers and said it was the Parallax recommended method for an object declaration to control its own cogs methods. I added the I/O assignments for this forum to incite discussion.
How about,
CON
LFT_PING := 0
CTR_PING := 1
RGT_PING := 2
{ := 3
:= 4
}
FLUX_CAP := 5
Other_Stuff :=6 ..30
........ :=31
'End CON
Just another idea. That way I would know what other sensors I/O you have used on your bot that I dont have on mine and what to comment out.
Not a law or rule, but an agreed method of documentation then? A protocol of documentation.
There, did I beat that dead horse dead yet?????
Post Edited (rpdb) : 2/11/2010 3:32:08 AM GMT
you read my mind - the reason for the starboard and port designation is that no matter what way you are facing in the boat, the sides are still the same. It's used for aircraft too. But isn't a Stingray an animal submarine, a type of organic boat?
I digress...
For number designations I have some comments:
0) I agree that it's hard to come up with conventions for a device designed as a prototyping tool.
1) This one has been bothering me for a while. We all use the term 'pin' which is wrong. "Port" assignments and "pin" numbers do NOT line up, and they are different across the packages. On a 40 pin DIP port 15 is pin 20 and on a Q44, port 15 is pin 16. I think the term port should be more widely used and placed in the code. The CON statement "rx_pin = 1" has two possible meanings Port 4 or Port 0. The term 'pin' should be limited to circuit discussions.
2) No matter what the assignment convention, ports should all be called out in the CON section of the top object so if a port assignment changes, it only needs adjustment in one place.
my $0.02
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent!
Send $1 to CannibalRobotics.com.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
John Abshier
Regarding the PING))) demo...that demo was written by an engineer as an example for the UPEW and was never released to the public. Changes were made to hardware later and that code was not updated, however some customers requested it and got the original, unedited copy floating around. It was never intended to be that way so it wasn't typical of our release code.
Regarding pin assignments...the wheel encoders will most likely connect to the pins immediately below the ones driving the H-Bridge. This has always been my intention and if there is no other reason not to this will remain. We have bigger plans...we have only to implement them all.
Thanks for your feedback. Best regards,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
·
Who says you can't teach an old dog new tricks!
I see red and green LEDs in my Stingray's future.
@Chris - I can't wait to see what is coming!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Post Edited (Whit) : 2/12/2010 6:57:40 PM GMT
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
-Phil
John Abshier
Three cheers for a stingray forum mateys..HAZAAH...HAZAAH...HAZAAH!!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent!
Send $1 to CannibalRobotics.com.