I've looked at both of those programs and they are similar, but the "Stingray Demo" is an extinsive modification of a program written to control Ken's hybrid machine, was written in 2006 and contains a lot of code "left over' from the original project.
The "Pings on a Stingray" code·appears to be a cleanup/rewrite of the above code with much, but not all,·of the unneeded/unused code removed. The fact remains though, that the code to move the bot forward depends on a single motor control procedure, "SetMotor" that assumes that the first pin of each pair will move the bot forward on the motor side passed to the routine, i.e. LeftMotor or RightMotor. RightMotor and LeftMotor are defined as constants representing the lower of a pair of pins (24 and 26 in this case) and treats the first pin as the pin that gets PWM'd to cause forward movement on that motor side. Because the procedure only uses one pin, the lower of the pair as the value of "Motor" passed to the procedure, and references the other using Motor+1, the wiring·of the motors must be reversed in order for the code to work as·intended for both motors.·See the table in the Stingray documentation to see that wiring the motors as described therein results in the pin pairs being a mirror image instead of the same order/function. 24,25,26,27 is LRev,LFwd,RFwd,RRev. In order for the SetMotor procedure to be used to control both motors, the pins must behave as 24,25,26,27 being·LFwd,LRev,RFwd,RRev.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
Duffer,
Are you sure you are looking at the right files? Perhaps you have some older version on your machine that it's picking up? I say this because I am not seeing what you are seeing.
This is the SetMotor function in the StingrayDemo.spin.spin file·inside the StingrayDemo.zip that I just downloaded from the parallax site on the Stingray page in the store. It was labeled "Pings on a Stingray - Archive", but the file it downloads is called StingrayDemo.zip.
BASE_PIN is defined as 24 at the top of the file. It drives the first pair of pins with the opposite logic to the second pair of pins. This matches how the documentation describes the motors being wired and also the table.
For motor 0 it drives pin 25 (BASE_PIN + 1)·when going forward and pin 24 (BASE_PIN)·when going in reverse, and for motor 1 it drives pin 26 (BASE_PIN + 2)·when going forward and pin 27 (BASE_PIN + 3)·when going in reverse.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Just downloaded the software archive on the Stingray's product page and discovered it is quite different than the one I downloaded some time ago.
Old one is titled "PingsOnStingray - Archive"
The new one on Stingray Product page is titled "Stingray Demo"
I have attached both for you and others to compare.· It looks quite interesting.·
Hey everone,
Okay! Now we are getting somewhere! I started with PingsOnStingray - I wired my Stingray accordly. It says "Connect the rightmost Ping to I/O zero, the center Ping to I/O one, and the leftmost Ping to I/O three. I didn't even catch the Ping to I/O three and connected it to two.
But note that this is different from the Instructions for Pings on a Stingray, which says, "Left PING))) to I/O pin 0, Center PING))) to I/O pin 1, Right PING))) to I/O pin 2. I figured this out by reading the RFC: Stingray/MRS1 Standard 0.01 Configuration Protocol thread here -http://forums.parallax.com/showthread.php?p=879261
Anyway the PingsOnStingray is the one that made my left motor rotate the wrong direction. (and I think the Pings were working backwards because they were wired backwards). I later found the Stingray Demo code. If I remember correctly, the motors worked correctly but the turning to avoid obstacles seemed backwards. This was, of course, because the Pings were wired incorrectly.
I don't have time to check this now, but will later. I think the·mystery is solved. It is a shame, because the PingsOnStingray code is cleaner as Duffer said(with the exception of the Ping wiring being labeled incorrectly).
I would like to develope some really clean code for this - heavily described with comments - so that new Stingray owners can easliy figure out how it works.
Thanks for the help!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The code that Roy Eltham sites does work for a Stingray wired according to the assembly instructions and conforms to the "movement tables" in the Stingray docs. The problem comes when the other version of Pings on a Stingray is used because it assumes a different wiring scheme for the left motor.
The code from Roy's post illustrates the point I made about increasing the complexity and size of the code if the motors are wired the same (colored wires to POS terminals). The "if Motor" statement tests whether the call is for·0 (left motor)·or·1 (right motor), then branches to different code for each motor. The code used in the other version that assumes that the left motor is wired with the white wire to the POS terminal uses a single routine for both motors and still·requires that only the motor and speed be passed.
While both techniques work, it does cause some confusion for new users and as one adds additional motor control code for such things as quadrature encoders, speed compensation, etc., having to·write seperate·but opposite code for each motor becomes considerably more complex and effectively doubles the code size for motor control if the wiring scheme follows·the Stingray assembly docs.
Having said all that, again, I suspect that because there is a working demo program that follows the published documentation,·that will have to be the standard·that·we have·to code to·if·our intention is to share·code with other Stingray users. I know that Parallax has said that the Stingray is meant for the more experienced user, but I'm dissapointed that a simple design choice in the motor wiring causes such an increase in code complexity and size for the platform.
I guess we'll have to wait and see how the·motor encoders are wired·and how the code is written for them by Parallax.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
Maybe it'll end up like the·wedges on the PGA Tour. There will be conforming and non-conforming Stingray robots and everybody will decide which they wish to code to. · Just make sure that you make it clear in the program docs whether the code is for a conforming Stingray or not if you share your code. We don't want any bruised ankles, traumatized pets·or scarred furniture do to runaway Stingrays.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
I'm happy to conform... to a degree anyhow. I know my code depends on the three pings being on pins 0-2. I reckon I could easily adjust or rewrite it if we start adding rear pings. My code is more raw, and likely less precise, than the original anyhow so may be of no use to others.
Speaking of breaking ankles. I would like a bit more power out of the motors. I think there is no fear currently of even harming the chihuahua!
The wiring of multiple PINGs is less problematic than the question of motor wiring. With PINGs, pick your pins and off you go. With the motor wiring and the difference between using one code element (for direction, speed, etc) vs different code elements for each wheel, it becomes a lot more complex and difficult to change unless you install a cross-over switch for the left wheel cable to the connector so that you can run code for conforming and non-conforming Stingrays without having to take the bot apart to rewire the motor.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
Mine is working now running perfectly now on the Stingray Demo code and now that I have the Pings on the correct pins.
I am trying to clean up the code and annotate it now and will post it later for comment. Thanke everyone. I almost never figured out the Ping and pins thing - since I got started wrong!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The Counter variable doesn't seem to be needed. IMO, unless I'm missing something, there still could be some confusion using the Distance[noparse][[/noparse] 2 ] and similar. Some stuff could be eliminated in the CON section, but I may be too new to this to realize it might be useful later, such as the IN1A,B,2A etc. I had in mind something like below, but others may disagree.
CON
_clkmode = xtal1 + pll16x
_clkfreq = 80_000_000
MAXDELTA = 800 ' Maximum ramping speed, higher = faster ramping
RISK_FACTOR = 2 ' How close robot gets to an obstacle before it slows down
Freq = 23000 ' for PWM
BASE_PIN = 24 ' motor base pin
right_ping = 0 ' set ping pins
center_ping = 1
left_ping = 2
ROTATE = _clkfreq / 150
CUTOFF = 8192 ' farthest distance from robot we care to detect
VAR
long Distance[noparse][[/noparse] 3 ] ' distances returned by pings
long Stack[noparse][[/noparse] 15 ] ' stack for ping object
OBJ
Pwm : "PWMx8"
Ping : "Ping"
PUB main | Left, Right, OldLeft, OldRight
pwm.start(BASE_PIN, %00001111, Freq) ' see PWMx8 for explanation of parameters
cognew(pings, @Stack)
OldLeft := OldRight := 0 ' defaults for variables used in main loop
repeat
'Read sensors
' Since RISK_FACTOR in this code is defined as 2 the following translates to:
' Left equals the distance returned by the center ping times 4. This result is
' further limited to a maximum of the distance returned by the right ping times 4.
Left := Distance[noparse][[/noparse]center_ping] << RISK_FACTOR <# Distance[noparse][[/noparse]right_ping] << RISK_FACTOR
' same as above
Right := Distance[noparse][[/noparse]center_ping] << RISK_FACTOR <# Distance[noparse][[/noparse]left_ping] << RISK_FACTOR
'Ramp motor speeds
' OldLeft equals OldLeft plus (Left minus OldLeft) limited to the minimum of
' -MAXDELTA and a maximum of MAXDELTA (-800 to 800 in this code)
OldLeft += (Left - OldLeft) <# MAXDELTA #> (-MAXDELTA)
' same as above
OldRight += (Right - OldRight) <# MAXDELTA #> (-MAXDELTA)
if ||OldLeft + ||OldRight < CUTOFF ' don't care about far away objects
if OldLeft < OldRight ' closest object on right, turn left
TurnLeft
else ' else closest object on left, turn right
TurnRight
else
'Output to motors ' no objects, move forward
SetMotor(0, OldLeft >> 7)
SetMotor(1, OldRight >> 7)
I had also replaced all instances of $80_00_00_00 to _clkfreq, and I changed the pings to the code below. I'm not sure why there is a division by 104? In my asm version I think I just used a shr 7. Division is slow but I suppose it doesn't really matter here. I tend to code for speed, as best as I can anyhow.
PUB pings | i, ticks
'' runs in a seperate cog
'continuously read in PING))) distances
repeat
repeat i from right_ping to left_ping ' 0 to 2
ticks := Ping.ticks(i)
Distance[noparse][[/noparse] i ] := ticks
ticks /= 104
ticks <#= 96
I apologize for all the issues you've had with the PING))) code. I recently learned that code was distributed without being updated for changes made to the MSR1 board after the code had been written. I am compiling feedback for possible changes to the documentation and even the hardware to make things easier and better for our customers. Please don't hesitate to let me know about changes that you think would make the Stingray a better robot. E-Mail me if you like. Best Regards,
No apology neccessary! I figured you were busy. I actually had a lot of fun figuring out the problem. These guys helped a lot and learned so much! I do look forward to seeing what you come up with though...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Chris, I agree with Whit no apology neccessary. I'm glad to have the help and support that Parallax gives its customers!
Whit,
In looking at the code I noticed in the header documentation note there is no information on determining the left ping. Is the left ping the left ping when looking at the Stingray head on or when viewing the Stingray from the rear (tail wheel) looking in the direction of forward movement? I think this is one of the issues that has caused confusion. It sure did for me when I first ran the code with the robot on the test stand (talking about my version haven’t had time to run your new code). I would put my hand in front of what I thought was the left ping and the wheels reacted by turning the robot towards my hand when they should have turned away. Sorry I forgot to mention this fact much earlier in the post.
So I can get this straight I have attached a diagram. Does it show the standard for left side, front, right side, and rear we are going to use as we share code?
Looking through the rest of the code it looks good. I hope to run it tonight. Thanks for your work.
Your diagram is correct. I have always understood the left and right as if you are facing the same direction as the robot. That is the standard. It would go for the motors, Pings))), IR emitters and detectors, etc.
The problem I had was that my Ping))) were wired per an older code (that is, Left Ping - pin 2, Center Ping - pin 1 and Right Ping - pin 0 - this is logical, but it didn't match the code which ran the motors correctly). The Stingray Demo code had Left Ping - pin 0, Center Ping - pin 1 and Right Ping - pin 2. (this issue you mentioned above about turning the wrong way was caused - for me - by this exactly! I got it wired·one way using Pings on a Stingray, and when I went to Stingray Demo, it was set up for the opposite wiring of the Pings)
As Phil Pilgrim said on another thread - we probably need pin assignments spelled out at the front-end of the code so that it clear what we are doing to others. Slight adjustment could then be made if someone's Stingray (or really cool handmade Stingray ) is wired a bit differently. Motors would be standard, but if we listed that the Left Ping was pin X up front, users could adjust the code accordingly - though I imagine most of us will get into some standards for these things.
Sorry we got you thread a bit high-jacked. I really have learned a lot though. I may add a display of some sort on my Stingray next. Seems like Chris Savage did a Bar Graph sort of deal with the Ping))) distance readings. That might be fun.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Thanks for the confirmation. I too have always considered this the standard for cars, tractors, robots and any other vehicle.
I hope my Homemade Stingray just keeps getting cooler with every add-on. With you and others help I'm sure it will.
No apology necessary. I have to have learned a lot, have enjoyed the problem solving, and very glad we're working on some sort of standards. This is what I wanted to happen. Can't wait to see how our Stingrays grow and improve.
I'm working on a homemade encoder system that will be easy to make and use with the 7.2v wheel kits. Erco inspired me on this one too.
I took my robot "Banshee" to my son's Fourth Grade class today as a treat for their good behavior and hard work during a science unit on electricity.· The children loved watching it come up to them, turn, and go towards someone else.· The robot worked great!· Just wish I knew of some way to make it go up to each child. · It was a great teaching experience and renewed my desire to start a robotics club in our area like Whit does. · I've also attached a picture of the modified Ping mounts with the wire notch cut into the bases. · Looks like I'll be able to get back to further development of this robot and will post results and code as I get them completed. · I am going to switch over to PropBASIC as my primary programming language.· I have had much success in just one week of using it and have been greatly encouraged by the help recieved from the developers namely Bean and JonnyMac.· You can find it at this forum http://forums.parallax.com/showthread.php?p=867134 · Tony
My robot Banshee met his big brother, Stingray, today.· I purchased the Stingray to develop code in PropBASIC in response to Whit's Stingray Challenge http://forums.parallax.com/showthread.php?p=894698· I also purchased the Stingray so I would have the same components that others would have as I develop code for the Stingray and have the ability to take pictures that would allow others to·reproduce the same thing on their Stingray.· Of course you know I love scratch building and I have a·couple of ideas for accessories for the·Stingray, so I needed one to work with.·Whit, can you guess what the first one will be?
I will be starting a new forum post that I will begin posting my PropBASIC code for the Stingray in this section of theforums.· I will first write code in PropBASIC that matches the test code in the Stingray manual and then move on from there.· Note if you are building or have built Banshee the code will work for it as well since it uses the same components and the motors can be wired to match the Stingray.· I consider my Stingray to be an indoor or flat surface robot because of the low ground clearance.· Banshee with its bigger footprint and high ground clearance is for outdoor running.· I guess I have the best for both worlds.
· Of course you know I love scratch building and I have a·couple of ideas for accessories for the·Stingray, so I needed one to work with.·Whit, can you guess what the first one will be?
DING DING DING We Have a winner folks! Whit you are correct. I already have it drawn up and will put it in my CAD program tonight so I can share it. Hope to build it tomorrow.
More than happy to help with the challenge and add to the forum resources.
Tony B. said...
DING DING DING We Have a winner folks! Whit you are correct. I already have it drawn up and will put it in my CAD program tonight so I can share it. Hope to build it tomorrow.
Tony B.
I'd love to see the plans to the new Stingray work stand·and pics·of the completed project.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Well I believe I am on to a much faster way to handle reading a Ping sensor, and in this case 3, and processing the data for controlling a robot's movements and object avoidance in PropBASIC.
Sure took me a long time to get out of the box and thinking fresh.
Code writing and testing begin tomorrow. I will post about my attempts whether good or bad.
I was very shocked to learn it has been just a few days over one year since my last update post.
With this update I have removed the three solid mount Pings and replaced them with two pings mounted on Parallax’s Ping Bracket mount #570-28015. This change reflects my change on my Stingray that I posted some time ago. As far as I know I was the first to do it. You can see it here http://forums.parallax.com/showthread.php?123541-New-Take-on-Pings-for-the-Stingray I will be writing the code and posting it hopefully by the end of the week. Although in the past I was using PropBASIC I have been working in Spin for some time. I made the change because I hope to sell my designs some day with basic working code and felt I should use Parallax’s official language.
As always, I hope Banshee inspires you to build your own Banshee (plans on first page post) or your own creation with the great Parallax products.
Tony
P.S. Although the hardware on Banshee is identical to a Stingray I consider Banshee to be my outdoor robot (because of the high ground clearance and tail wheel) and my Stingray to be an indoor robot. Thus, code developed on one will work on the other. How’s that for efficiency?
Banshee gets its next upgrade, REAL BRAKES! As many know working with motor controllers like the one on the Robot controller Board from Parallax (old Stingray board) or with HB-25s they have no effective braking and go into what I would call neutral. That is, the robot will continue to roll after the power has been shut off. For my robots, Banshee and 4 Paws, that was a real problem. And believe me I have the bruises and dents in the wall and furniture to prove it. What I wanted and needed was a way to stop them on command. So after much thought and rejection of many ideas I have come up with this simple solution. (see video http://www.youtube.com/watch?v=JDGgaHLj3W8&feature=youtu.be) Using the plans above you can build your own Banshee and while at it build this braking system.
NOTE: In the video the brake is stopping the wheel while it is set to run at full power. Not the recommended way to use the motor and brake. For demonstration of power of brake.
What you need:
2 ¾ X ¾ X 1 ½ Pine base blocks
1 Standard Servo with standard horn(#900-00005)
2 L-Brackets (#720-00011)
4 4-40 X ½ bolts
4 4-40 nuts
8 - #4 machine screws
1 ¼ X 1 ½ X 2 ½ stop block of wood (I glued to pieces of ¼ plywood together)
Instructions:
Make up and cut blocks of wood and/or ply to size
Glue base blocks to Banshee chassis (note location in pictures)
Attach L-Brackets to servo with bolts coming through from the back. Makes it a lot easier to get mounting holes in L-Bracket
Drill 19/64 hole 3/4 from one end and side.
Mount stop block to servo horn with four screws in the second hole from the center on each arm of the servo horn. Best to drill the holes out to an appropriate size for the screws.
Temporarily slide horn and stop block on to servo. Position servo assembly over wheel and base blocks. Align stop block with center of wheel and mark L-Bracket holes on base blocks
Remove servo assembly and drill pilot holes and mount servo without stop block
Using your controller board center the servo.
Attach stop block with servo screw slightly above wheel.
Program the needed movement for efficient braking, but not so much as to break the servo.
Comments
The "Pings on a Stingray" code·appears to be a cleanup/rewrite of the above code with much, but not all,·of the unneeded/unused code removed. The fact remains though, that the code to move the bot forward depends on a single motor control procedure, "SetMotor" that assumes that the first pin of each pair will move the bot forward on the motor side passed to the routine, i.e. LeftMotor or RightMotor. RightMotor and LeftMotor are defined as constants representing the lower of a pair of pins (24 and 26 in this case) and treats the first pin as the pin that gets PWM'd to cause forward movement on that motor side. Because the procedure only uses one pin, the lower of the pair as the value of "Motor" passed to the procedure, and references the other using Motor+1, the wiring·of the motors must be reversed in order for the code to work as·intended for both motors.·See the table in the Stingray documentation to see that wiring the motors as described therein results in the pin pairs being a mirror image instead of the same order/function. 24,25,26,27 is LRev,LFwd,RFwd,RRev. In order for the SetMotor procedure to be used to control both motors, the pins must behave as 24,25,26,27 being·LFwd,LRev,RFwd,RRev.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
Are you sure you are looking at the right files? Perhaps you have some older version on your machine that it's picking up? I say this because I am not seeing what you are seeing.
This is the SetMotor function in the StingrayDemo.spin.spin file·inside the StingrayDemo.zip that I just downloaded from the parallax site on the Stingray page in the store. It was labeled "Pings on a Stingray - Archive", but the file it downloads is called StingrayDemo.zip.
Pub SetMotor(Motor, Speed) Speed := -255 #> Speed <# 255 if Motor ifnot Speed & $80_00_00_00 Pwm.Duty(BASE_PIN + 2, Speed & $FF) Pwm.Duty(BASE_PIN + 3, 0) else Pwm.Duty(BASE_PIN + 2, 0) Pwm.Duty(BASE_PIN + 3, (0 - Speed) & $FF) else ifnot Speed & $80_00_00_00 Pwm.Duty(BASE_PIN + 1, Speed & $FF) Pwm.Duty(BASE_PIN, 0) else Pwm.Duty(BASE_PIN + 1, 0) Pwm.Duty(BASE_PIN, (0 - Speed) & $FF)BASE_PIN is defined as 24 at the top of the file. It drives the first pair of pins with the opposite logic to the second pair of pins. This matches how the documentation describes the motors being wired and also the table.
For motor 0 it drives pin 25 (BASE_PIN + 1)·when going forward and pin 24 (BASE_PIN)·when going in reverse, and for motor 1 it drives pin 26 (BASE_PIN + 2)·when going forward and pin 27 (BASE_PIN + 3)·when going in reverse.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Okay! Now we are getting somewhere! I started with PingsOnStingray - I wired my Stingray accordly. It says "Connect the rightmost Ping to I/O zero, the center Ping to I/O one, and the leftmost Ping to I/O three. I didn't even catch the Ping to I/O three and connected it to two.
But note that this is different from the Instructions for Pings on a Stingray, which says, "Left PING))) to I/O pin 0, Center PING))) to I/O pin 1, Right PING))) to I/O pin 2. I figured this out by reading the RFC: Stingray/MRS1 Standard 0.01 Configuration Protocol thread here -http://forums.parallax.com/showthread.php?p=879261
Anyway the PingsOnStingray is the one that made my left motor rotate the wrong direction. (and I think the Pings were working backwards because they were wired backwards). I later found the Stingray Demo code. If I remember correctly, the motors worked correctly but the turning to avoid obstacles seemed backwards. This was, of course, because the Pings were wired incorrectly.
I don't have time to check this now, but will later. I think the·mystery is solved. It is a shame, because the PingsOnStingray code is cleaner as Duffer said(with the exception of the Ping wiring being labeled incorrectly).
I would like to develope some really clean code for this - heavily described with comments - so that new Stingray owners can easliy figure out how it works.
Thanks for the help!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/7/2010 2:00:37 PM GMT
The code from Roy's post illustrates the point I made about increasing the complexity and size of the code if the motors are wired the same (colored wires to POS terminals). The "if Motor" statement tests whether the call is for·0 (left motor)·or·1 (right motor), then branches to different code for each motor. The code used in the other version that assumes that the left motor is wired with the white wire to the POS terminal uses a single routine for both motors and still·requires that only the motor and speed be passed.
While both techniques work, it does cause some confusion for new users and as one adds additional motor control code for such things as quadrature encoders, speed compensation, etc., having to·write seperate·but opposite code for each motor becomes considerably more complex and effectively doubles the code size for motor control if the wiring scheme follows·the Stingray assembly docs.
Having said all that, again, I suspect that because there is a working demo program that follows the published documentation,·that will have to be the standard·that·we have·to code to·if·our intention is to share·code with other Stingray users. I know that Parallax has said that the Stingray is meant for the more experienced user, but I'm dissapointed that a simple design choice in the motor wiring causes such an increase in code complexity and size for the platform.
I guess we'll have to wait and see how the·motor encoders are wired·and how the code is written for them by Parallax.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
Remember I am a beginner but from the back of the robot I view the pins.
p2 - p1 - p0
Although I have mine wired differently than everyone, I am willing to change it. For me it makes sense to have the following:
Lp = Left Ping
p2 - p1 - p0
Lp - Cp - Rp
Code for reading sensors is
Left := Distance[noparse][[/noparse]center_ping] << RISK_FACTOR <# Distance[noparse][[/noparse]right_ping] << RISK_FACTOR
Right := Distance[noparse][[/noparse]center_ping] << RISK_FACTOR <# Distance[noparse][[/noparse]left_ping] << RISK_FACTOR
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
I'm happy to conform... to a degree anyhow. I know my code depends on the three pings being on pins 0-2. I reckon I could easily adjust or rewrite it if we start adding rear pings. My code is more raw, and likely less precise, than the original anyhow so may be of no use to others.
Speaking of breaking ankles. I would like a bit more power out of the motors. I think there is no fear currently of even harming the chihuahua!
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
Post Edited (Duffer) : 2/8/2010 3:33:42 AM GMT
Mine is working now running perfectly now on the Stingray Demo code and now that I have the Pings on the correct pins.
I am trying to clean up the code and annotate it now and will post it later for comment. Thanke everyone. I almost never figured out the Ping and pins thing - since I got started wrong!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The Counter variable doesn't seem to be needed. IMO, unless I'm missing something, there still could be some confusion using the Distance[noparse][[/noparse] 2 ] and similar. Some stuff could be eliminated in the CON section, but I may be too new to this to realize it might be useful later, such as the IN1A,B,2A etc. I had in mind something like below, but others may disagree.
CON _clkmode = xtal1 + pll16x _clkfreq = 80_000_000 MAXDELTA = 800 ' Maximum ramping speed, higher = faster ramping RISK_FACTOR = 2 ' How close robot gets to an obstacle before it slows down Freq = 23000 ' for PWM BASE_PIN = 24 ' motor base pin right_ping = 0 ' set ping pins center_ping = 1 left_ping = 2 ROTATE = _clkfreq / 150 CUTOFF = 8192 ' farthest distance from robot we care to detect VAR long Distance[noparse][[/noparse] 3 ] ' distances returned by pings long Stack[noparse][[/noparse] 15 ] ' stack for ping object OBJ Pwm : "PWMx8" Ping : "Ping" PUB main | Left, Right, OldLeft, OldRight pwm.start(BASE_PIN, %00001111, Freq) ' see PWMx8 for explanation of parameters cognew(pings, @Stack) OldLeft := OldRight := 0 ' defaults for variables used in main loop repeat 'Read sensors ' Since RISK_FACTOR in this code is defined as 2 the following translates to: ' Left equals the distance returned by the center ping times 4. This result is ' further limited to a maximum of the distance returned by the right ping times 4. Left := Distance[noparse][[/noparse]center_ping] << RISK_FACTOR <# Distance[noparse][[/noparse]right_ping] << RISK_FACTOR ' same as above Right := Distance[noparse][[/noparse]center_ping] << RISK_FACTOR <# Distance[noparse][[/noparse]left_ping] << RISK_FACTOR 'Ramp motor speeds ' OldLeft equals OldLeft plus (Left minus OldLeft) limited to the minimum of ' -MAXDELTA and a maximum of MAXDELTA (-800 to 800 in this code) OldLeft += (Left - OldLeft) <# MAXDELTA #> (-MAXDELTA) ' same as above OldRight += (Right - OldRight) <# MAXDELTA #> (-MAXDELTA) if ||OldLeft + ||OldRight < CUTOFF ' don't care about far away objects if OldLeft < OldRight ' closest object on right, turn left TurnLeft else ' else closest object on left, turn right TurnRight else 'Output to motors ' no objects, move forward SetMotor(0, OldLeft >> 7) SetMotor(1, OldRight >> 7)Edit: Forum was eating my brackets.
Post Edited (Bocephus) : 2/8/2010 10:34:54 PM GMT
PUB pings | i, ticks '' runs in a seperate cog 'continuously read in PING))) distances repeat repeat i from right_ping to left_ping ' 0 to 2 ticks := Ping.ticks(i) Distance[noparse][[/noparse] i ] := ticks ticks /= 104 ticks <#= 96I am eager to look over the code later tonight.
Thanks to all for working to get this resolved and improving the code. It will be nice to have stable platforms to begin adding too.
Tony
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
Check out the new Savage Circuits TV!
·
No apology neccessary! I figured you were busy. I actually had a lot of fun figuring out the problem. These guys helped a lot and learned so much! I do look forward to seeing what you come up with though...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Whit,
In looking at the code I noticed in the header documentation note there is no information on determining the left ping. Is the left ping the left ping when looking at the Stingray head on or when viewing the Stingray from the rear (tail wheel) looking in the direction of forward movement? I think this is one of the issues that has caused confusion. It sure did for me when I first ran the code with the robot on the test stand (talking about my version haven’t had time to run your new code). I would put my hand in front of what I thought was the left ping and the wheels reacted by turning the robot towards my hand when they should have turned away. Sorry I forgot to mention this fact much earlier in the post.
So I can get this straight I have attached a diagram. Does it show the standard for left side, front, right side, and rear we are going to use as we share code?
Looking through the rest of the code it looks good. I hope to run it tonight. Thanks for your work.
Tony
Post Edited (T Bill) : 2/10/2010 5:03:26 PM GMT
Your diagram is correct. I have always understood the left and right as if you are facing the same direction as the robot. That is the standard. It would go for the motors, Pings))), IR emitters and detectors, etc.
The problem I had was that my Ping))) were wired per an older code (that is, Left Ping - pin 2, Center Ping - pin 1 and Right Ping - pin 0 - this is logical, but it didn't match the code which ran the motors correctly). The Stingray Demo code had Left Ping - pin 0, Center Ping - pin 1 and Right Ping - pin 2. (this issue you mentioned above about turning the wrong way was caused - for me - by this exactly! I got it wired·one way using Pings on a Stingray, and when I went to Stingray Demo, it was set up for the opposite wiring of the Pings)
As Phil Pilgrim said on another thread - we probably need pin assignments spelled out at the front-end of the code so that it clear what we are doing to others. Slight adjustment could then be made if someone's Stingray (or really cool handmade Stingray
Sorry we got you thread a bit high-jacked. I really have learned a lot though. I may add a display of some sort on my Stingray next. Seems like Chris Savage did a Bar Graph sort of deal with the Ping))) distance readings. That might be fun.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/10/2010 5:33:06 PM GMT
Thanks for the confirmation. I too have always considered this the standard for cars, tractors, robots and any other vehicle.
I hope my Homemade Stingray just keeps getting cooler with every add-on. With you and others help I'm sure it will.
No apology necessary. I have to have learned a lot, have enjoyed the problem solving, and very glad we're working on some sort of standards. This is what I wanted to happen. Can't wait to see how our Stingrays grow and improve.
I'm working on a homemade encoder system that will be easy to make and use with the 7.2v wheel kits. Erco inspired me on this one too.
Tony
·
It was a great teaching experience and renewed my desire to start a robotics club in our area like Whit does.
·
I've also attached a picture of the modified Ping mounts with the wire notch cut into the bases.
·
Looks like I'll be able to get back to further development of this robot and will post results and code as I get them completed.
·
I am going to switch over to PropBASIC as my primary programming language.· I have had much success in just one week of using it and have been greatly encouraged by the help recieved from the developers namely Bean and JonnyMac.· You can find it at this forum http://forums.parallax.com/showthread.php?p=867134
·
Tony
Post Edited (T Bill) : 2/22/2010 9:44:12 PM GMT
Thanks for the update and especially the link to your work with PropBasic. I haven't played with it yet, but is seems like a cool idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I also encourage you to look at Whit's Stingray Forum Resources http://forums.parallax.com/showthread.php?p=896905·
I will be starting a new forum post that I will begin posting my PropBASIC code for the Stingray in this section of theforums.· I will first write code in PropBASIC that matches the test code in the Stingray manual and then move on from there.· Note if you are building or have built Banshee the code will work for it as well since it uses the same components and the motors can be wired to match the Stingray.· I consider my Stingray to be an indoor or flat surface robot because of the low ground clearance.· Banshee with its bigger footprint and high ground clearance is for outdoor running.· I guess I have the best for both worlds.
Tony
I don't have a stringray, but if you get stuck please let me know. I'll be more than happy to help. Anything to promote PropBasic.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
I am guessing a Stingray work stand. Thanks for the Plug about the Stingray Challenge and the Forum Resources. Can't wait to see your PropBASIC 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
More than happy to help with the challenge and add to the forum resources.
Thanks,
Tpony
I'd love to see the plans to the new Stingray work stand·and pics·of the completed project.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Sure took me a long time to get out of the box and thinking fresh.
Code writing and testing begin tomorrow. I will post about my attempts whether good or bad.
Tony
Look forward to seeing this! I am currently snowed under with end of school stuff - Summer is coming...
Whit+
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
With this update I have removed the three solid mount Pings and replaced them with two pings mounted on Parallax’s Ping Bracket mount #570-28015. This change reflects my change on my Stingray that I posted some time ago. As far as I know I was the first to do it. You can see it here http://forums.parallax.com/showthread.php?123541-New-Take-on-Pings-for-the-Stingray I will be writing the code and posting it hopefully by the end of the week. Although in the past I was using PropBASIC I have been working in Spin for some time. I made the change because I hope to sell my designs some day with basic working code and felt I should use Parallax’s official language.
As always, I hope Banshee inspires you to build your own Banshee (plans on first page post) or your own creation with the great Parallax products.
Tony
P.S. Although the hardware on Banshee is identical to a Stingray I consider Banshee to be my outdoor robot (because of the high ground clearance and tail wheel) and my Stingray to be an indoor robot. Thus, code developed on one will work on the other. How’s that for efficiency?
NOTE: In the video the brake is stopping the wheel while it is set to run at full power. Not the recommended way to use the motor and brake. For demonstration of power of brake.
What you need:
2 ¾ X ¾ X 1 ½ Pine base blocks
1 Standard Servo with standard horn(#900-00005)
2 L-Brackets (#720-00011)
4 4-40 X ½ bolts
4 4-40 nuts
8 - #4 machine screws
1 ¼ X 1 ½ X 2 ½ stop block of wood (I glued to pieces of ¼ plywood together)
Instructions: