I like what yous guys are doing with the encoder code. These numbers are exactley what I have been working on all week
10" wheels with 9 spokes, 4 pulses per spoke is 36 pulses per rev. Oh. my that has not enough resolution... I just looked at the encoders you guys are working with and I want some. I looked at the site and you can order direct with the shaft size etc to meet your specs.
Have you any assembly prop code for +/- rpm to a servo?
I just built some home-rolled encoders (old CDs screwed to the wheel hubs with labels glued on reflecting to some angled optical detectors). The signal was ugly at first, but I added an interface board with 74ls14 Schmidt triggers for hysterises (UTP/LTP). I also added an OptoFET relay to On/Off the whole encoder board from one prop pin, because it consumed 0.150 A at 12 V (1.8 watts). Why look when the motors aren't turning?
I am running a pair of DC motors (upgraded PowerWheels) through a pair of HB25s. I don't like the fans coming on with no test of temp on the HB25s, so I want to put some temp sensors (TO92) drill into the heat-sinks, thermal epoxy etc., and only turn the fans on only when necessary. Does anyone have the temp specs for the HB25s? Any good ideas?
Guys: Love the work you're doing here. I just wanted to share that I've had excellent results with home grown encoders using this $3 Hamamatsu reflectance sensor:
It's tiny and it already has filters, Schmidt triggers and signal conditioning built in. The best $3 I've spent lately. I've been using it directly as a wheel encoder, but if you guys are sold on motor encoders I'm sure you can find a way. Pics attached.
@rpdb: You say you're screwing some old CDs on for your encoder disks. More power to ya. Be accurate, though. Your encoder disk consistency, flatness·and concentricity is·just as critical as round, true wheels are in the dangerous game of dead reckoning. That's all I'm doing these days and I'm learning a lot!
best,
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"If you build it, they will come."
I like your code, I'll try it tonight. I used it for ideas to write some changes to run my HB25s on the rev up/down section. I am so jelous of the resolution your getting with the usdigital encoders, I can probably only hope to have 72-144 ppr at the wheel for what I am working on if I machine some encoder plates. I just downloaded the specs to see if I have room to mount the usdigital units. My motor shafts are 0.128 or almost 1/8" (not 6mm) so I'll have to order the custom from usdigital (plus a cable and center tool and...). I have to check the shaft length as well. Are the encoder wheels Metal or plastic, and did they come with a set screw or just press on?
Here is some stuff I added to your code, I hope someone can use it for a prop bot
''
This Block creates a speed up/down Motor test on Pin7
or not on pin7
{remodeling or under construction, requires changes etc.
{{rpdb added this for use with a pair of HB25 controllers
'use the PWM.servo object = PWM_32_v2.spin
'PulseWidth ... 800 = 0.8ms (backward) / 1500 = 1.5 ms (stop) / 2200 = 2.2ms (forward) HB25 can go from 0.8 to 2.2 ms
'HB25 needs a 5 ms (recommended 5.25) pause between pulses, hoping spin overhead might should add 0.25ms? Ill test add 0.25ms if needed
' 'need to declare byte or long: PulseWidth, rampRate RPin = R_HB25, LPin = L_HB25
}
'PUB MotorTest(RPin) | PulseWidth, rampRate
repeat
repeat PulseWidth from 1500 to 2000 ''ramp up from stop to full fwd 1.5 to 2.0 ms 500 steps/step = ? or 0.x
Servo(RPin,PulseWidth) ''
waitCnt(ClkFreq /200 + cnt) ''minimum required 5ms between servo pulse for HB25
waitCnt(ClkFreq /rampRate + cnt) ''insert rampRate here depends on if adding a step rate
waitCnt(ClkFreq*5 + cnt) '' Hold at full forward for 5 sec
repeat PulseWidth from 2000 to 1500 ''now ramp down from full fwd to stop
Servo(RPin,PulseWidth) ''
waitCnt(ClkFreq /200 + cnt) ''5ms between servo pulse for HB25, add rampRate
waitCnt(ClkFreq*5 + cnt) '' Hold at stop for 5 sec
''now reverse
repeat PulseWidth from 1500 to 1000 ''ramp up(down?) from stop to full reverse step = ?
Servo(RPin,PulseWidth) ''
waitCnt(ClkFreq /200 + cnt) ''5ms between servo pulse for HB25, add rampRate
waitCnt(ClkFreq*5 + cnt) '' Hold at full reverse for 5 sec
repeat PulseWidth from 1000 to 1500 ''now ramp down from full reverse to stop
Servo(RPin,PulseWidth) ''
waitCnt(ClkFreq /200 + cnt) ''5ms between servo pulse for HB25, add rampRate
waitCnt(ClkFreq*5 + cnt)
}}
Next I want to work on a constant speed i.e. with PID feed back for load compensation.
rpdp
The QME-01 comes with a metal code wheel that is pressed onto the rear motor shaft and in my case at least, the electronics is attached with double sided tape. There was an earlier mention of screw attachment.
Alignment is critical as is distance from the code wheel but I easily managed to install it without an alignment tool.
There is also a plastic press on cover which keeps out stray light.
I would be interested in your PID drive when you get around to it.
Ray
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never force anything - Always get a bigger hammer.
The USDigital encoders that I got from Lynxmotion (QME-01), have aluminum encoder wheels that·press onto the·rear motor shaft. i didn't need to use the centering tool to install the encoder body. If you're careful you can do the job without it.
Although 400 ppr is nice, don't give up hope of getting good results with a lot less resolution. You need to look at·the accuracy that·"erco" is getting from his simple but effective wheel encoders on his home-grown platform. Clever coding can make up for a lot of hardware shortcomings (we landed men on the moon with computers that we would consider a joke today).
BTW, posting code as unformatted text as you did in your post destroys the indentation of your original code and makes it very difficult for someone to understand the repeat loops. Try enclosing your code using the "insert formatted code, #" symbol on the toolbar.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
The encoders I'm working on are very similar to yours. But, the tires and wheels are made in China, talk about run-out and concentricity, I am glad they are close to being what!! "round". I do have something close to a quadrature signal out though, close enough for a waitpeq at 90 or so degrees. I printed out some labels from an ACAD dxf file I created to make a CD-Stomper label with indecies(centers) for drilling the hub holes. I printed in dark blue, hoping to absorb IR (off spectrum) and use the reflective part of the disk for ON state. Works good so far.
Reflextive Sensors 4 ea $0.99 @ jameco
CDs and Print cost 2 ea $0.05
7414Schmidt and Board $5.00
The interface, my Mind and wallet still work -- priceless less $10.00
Thanks for your input erco
I love it when my kids come up to me with a zip lock bag of broken cell phone parts and say "check out this camera and lcd"
I hope that's faked! Too good to be true? Small bot, skinny wheels, constant speed, constant radius. maybe that's the secret.
I made some·progress using the USDigital encoders on my Stingray. Carpet (bumpy berber) is probably the worst thing to test on. I have to find a large, smooth, flat surface (indoors) to continue testing.
The main success I've had so far is getting the bot to go in a straight line. Encoders rule for that. Turns on carpet are much more challenging. I've attached the project in its current form. It has forward, reverse and all of the turn and spin moves. I need to borrow from Ray0665's earlier "poly" code and write a simple number of sides and length of side· polygon routine for testing (maybe this weekend).
Please take a look at what I've got so far and (gently) offer any suggestions that you might have for making it work better. If somebody tests this on a good smooth surface, please let me know how well it does as far as repeatability. It's just doing a 72" X 36" rectangle.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
I have both carpet (normal house carpet) and smooth wood tabletop surfaces. I have been doing some tests using my own code to work with the Quadrature_Encoder.spin and PWM_32_v3.spin objects. The code attempts to drive the motors at a given inches per second rate. It speeds up and slows down each motor as need to maintain the desired pulse rate from the encoders. However, it doesn't properly slow down one motor when the other is slowed (like when the wheel hits a bump). I'm going to work on that next. Even still, I get pretty good straight line movement on both surfaces. For turns I found that the carpet produced better results for spin turns across more different speeds. The wood surface works really well up to a certain (fairly slow speed) then it starts to overshoot more. I haven't tried driving in a circle yet, but I suspect that the wood surface will win.
I was hoping to post a video this week, but failed. I'll try to post one this weekend along with whatever code I have working then.
erco,
That video is impressive, but it's also moving very slowly on a smooth surface. That is about the slowest I can get my Stingray going without having the motors randomly stalling. I think I'll be able to get similarly good results eventually.
Roy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Of course an easy way to fake that circle driving video (or my straight-line video for that matter) is to cheat and have a solid axle, both wheels locked together and no electronics at all. Same size tires = perfect straight line, different size tires = perfect circle.
NOW I think of this. All my time wasted. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"If you build it, they will come."
Several people have added encoders to their Stingray robots. It appears that there are a couple different wiring schemes and pins used for how the encoders are connected to the Propeller board. To make it easier to share code between Stingray robots it would to good to identify and define what set of 4 pins will be used for the encoders and which ones are used for the left and right sides.
Since the SD cards are normally on P0 through P3 I'd rather not put the encoders on those pins. What does everyone else think should be used as the standard pins for encoders?
While I don't have a stingray (and hence my opinion probably doesn't count), I'm not a fan of "standardized" pins per se. It seems to make a LOT more sense to use constants, and define them near the top of the code. That way, if someone else has a different board (or a custom board) and/or different set of sensors, etc., the code isn't "broke", you just set the constants to whatever pins you're using.
This, and a buck will get you a bottle of pop from our machine :-)
All the Stingray robots ship with the Parallax Robot Control board which already has a few standard pins defined. (H-Bridge, EEPROM, and USB). Although we can edit the constants for odd boards (perfectly fine) it would seem to make collaborative Stingray Projects much easier to work on if there is an agreed upon standard for standard options. If there are multiple people working on a project wouldn't it be easier to drop the code down on your robot without having to edit the constants every time?
I'm mainly concerned about the pins used for a pair of quadrature encoders (which should have been an option when the robot was released) to help encourage the development of better objects for the drive system.
The ability to use pins for whatever you want is a great feature of the propeller but it is nice to have some standards and constancy too.
I was going through different threads for the Stingray today and was wondering if anyone has or had made any further progress with the Stingray using the USDigital encoders or any other obstables?
thanks
I was going through different threads for the Stingray today and was wondering if anyone has or had made any further progress with the Stingray using the USDigital encoders or any other obstables?
thanks
Roy, as a note, encoders are the next accessory being worked on for the Stingray. And yes, the US Digital encdoers were tested however they were the E4 and E4P that we tested. One mounted via double-sided sticky tape. The other via a couple of screws through the plastic on the back of the motor.
Since they stopped working on the redesign of the controller board, I would say probably not. I was really hoping Stingray would turn into a mor advanced Boe Bot, with tutorials, add-ons, etc., but that does not seem to be the case...
I was hoping exactly the same as polbit, but gave up hoping. There are no spare parts, no control board, no educational resources, and the only Stingray accessory since the roll out has been the power pack. Oh well. Ken posted a really sincere update a year ago or so suggesting that the Stingray was still alive at Parallax, but I wonder if it has been pushed out by the S2.
I am thinking that "rolling your own" is the only option for Stingray repairs and upgrades. I have been using the USDigital encoders, and have also had good luck with them. The level shifters never worked well for me on the original control board, so I replaced it with a Prop Platform and a Pololu motor driver which works great. Next step is to find suitable lower RPM motors, as wisely suggested by Erco. Can anyone suggest a source?
I've been buried with the Mystery Project and Maker Fair prep, so I can't speak with authority...
My understanding is that we're turning the Stingray into a more modular platform, with more modular controllers and processor boards (rather than a fully integrated "canned" solution - It would add a lot more flexibility to the electronic capabilities - I've already created some new "levels" designs for upper decks on the platform that may soon be available as add-ons.
But let's see what Chris has to say - I'll rattle his cage ;-)
-Matt
Since they stopped working on the redesign of the controller board, I would say probably not. I was really hoping Stingray would turn into a mor advanced Boe Bot, with tutorials, add-ons, etc., but that does not seem to be the case...
I know, I know. I assure you that we feel your pain. So many products/projects in the pipeline, and not enough time to go around. I'll see what/who I can scare up...(FYI, around here I'm the rabble-rouser-just ask anyone-especially Ken)
I've been buried with the Mystery Project and Maker Fair prep, so I can't speak with authority...
My understanding is that we're turning the Stingray into a more modular platform, with more modular controllers and processor boards (rather than a fully integrated "canned" solution - It would add a lot more flexibility to the electronic capabilities - I've already created some new "levels" designs for upper decks on the platform that may soon be available as add-ons.
But let's see what Chris has to say - I'll rattle his cage ;-)
-Matt
Matt,
I agree, I think modular is a great way to go. My wish list is something like a DIP prop board (like the Propeller Platform) so those inevitable burnouts can be inexpensively repaired; an independent motor driver, slower replaceable motors, a sensor connection board that brings out the Prop pins and 3.3 and 5V power (similar to the ProtoPlus or the Wulfden servo control board), standard interconnects,. Oh, and a BoeBot like projects book for my students, some who are past the BoeBot/BOE and want more. That could all be done in a week or less, right .
I have purchased several Stingrays in order to equip a University laboratory to support a robotics class I will be teaching in a couple of semesters. In this class, students will not modify the hardware but instead use the platform to experiment with traditional robotics algorithms. So my job so far, has been trying to add enough sensors and control algorithms on the stingray so it can be used as a low level robotics experimentation platform. Before doing so, I read as much as I could about it on the forums (still, I didn't read the thread about the voltage translators, thus losing quite a few hours, and hair, trying to figure out non-problems, anyway...) and went through a lot of the same thought process forum contributors have expressed. Here is a bit of information of where I am and what approach I have taken so far, hopefully it can help guide the future of this great platform.
To start, I liked (and still like) the stingray because it is relatively large (which allows mounting quite a few things on it), it is fast (2.4 met/sec doesn't sound fast, but boy, that thing can go!), and its structure (differential wheel drive with swedish tail/front wheel) is frequently used on robotics textbooks for kinematic analysis, thus students can readily apply concepts to the platform.
So after working with it for a while now, I can see the limitations of the current board but also its positive aspects. The architecture I ended up with involves using the existing Stingray board as a low level bot controller, and a different board for the high level functions. There are multiple reasons for this decision. After some experimentation, I realized that there is just not enough memory and speed on a prop to run some of the traditional robotics algorithms (probabilistic mapping, navigation etc.) Also, I am building a simulator that would be used before students get access to the hardware, and the actual platform has to be source code compatible with the simulator, making Spin an issue. Last, but not least, I simply run out of cogs and I/O pins in the current configuration. I have added the quadrature encoders, 5 IR sensors, 2 stationary PINGs, one PING on a servo, a rate gyro, and a magnetometer. Adding 4 pins for SPI communication to the master board that runs the high level AI, more or less has used up just about every I/O pin and all cogs, to the point where I am having to make some tough decisions on which capability to drop. One such case is use of the quadrature encoders. In my mind, to properly do odometry would require 2 maybe even 3 cogs, but I am forced to use a single cog and one of the two channels on each encoder. I would also love to add a small LCD but there is just not enough capacity to do so.
So to me, the most useful feature would be to have not one, but multiple propellers integrated into a board for the Stingray. One propeller would be dedicated to motor control and odometry calculations. Another one or two propellers would be dedicated to sensor I/O and that leaves a propeller to do AI and coordination. So 4 props minimum, but 8 would also be nice. Sharing some pins to allow prop-to-prop communcation would do wonders!
[By the way, what's the plan on the Propeller II, that would solve a lot of these problems!!!]
Anyway, these are my 2c for now. I am currently working on using the encoders to do trajectory control; hope to be able to report good progress in the new future, maybe contribute a thing or two in the process.
@ypapelis: You sir, are setting the bar quite high! Based on feedback and videos I've seen, many Stingray users are content to build as delivered, do a few fast turns in the driveway, and move around indoors with minimal baseboard damage. Good luck in teaching your course, and please keep us apprised of your robo-fleet's upgrade progress!
Oh, and a BoeBot like projects book for my students, some who are past the BoeBot/BOE and want more. That could all be done in a week or less, right .
Ha! Lev-
My wish list is something like a DIP prop board (like the Propeller Platform) so those inevitable burnouts can be inexpensively repaired; an independent motor driver, slower replaceable motors, a sensor connection board that brings out the Prop pins and 3.3 and 5V power
Yes, I agree. The only issue that we have here is lack of time, but I know that we want to head in this direction- it's simply a matter of internal resources. I'm (we're) very "pro-robot" here, as well as "pro-robot education" too!
Will keep you posted on progress here, now that Maker Fair and "mystery project" have progressed nicely.
Hi,
I'm also using the Stingray as my robot base, with the standard controller board.
I'm sad that it is not made anymore, because I wanted to use several (4) for the bot.
What I like in particular is the level shifting IO, but it seems that the IC's for that
(YE08?) are not available anywhere?
For the encoders I used the Sharp GP1A70R, normally used for printers.
It is interesting that the outputs could not drive the controller boards directly, I had to use
transistor amps. Do you have a schematich of the board? It would be interesting what the
IO interface looks like.
Friedrich
There's no computer fast enough, there's no memory big enough ...
Comments
10" wheels with 9 spokes, 4 pulses per spoke is 36 pulses per rev. Oh. my that has not enough resolution... I just looked at the encoders you guys are working with and I want some. I looked at the site and you can order direct with the shaft size etc to meet your specs.
Have you any assembly prop code for +/- rpm to a servo?
I just built some home-rolled encoders (old CDs screwed to the wheel hubs with labels glued on reflecting to some angled optical detectors). The signal was ugly at first, but I added an interface board with 74ls14 Schmidt triggers for hysterises (UTP/LTP). I also added an OptoFET relay to On/Off the whole encoder board from one prop pin, because it consumed 0.150 A at 12 V (1.8 watts). Why look when the motors aren't turning?
I am running a pair of DC motors (upgraded PowerWheels) through a pair of HB25s. I don't like the fans coming on with no test of temp on the HB25s, so I want to put some temp sensors (TO92) drill into the heat-sinks, thermal epoxy etc., and only turn the fans on only when necessary. Does anyone have the temp specs for the HB25s? Any good ideas?
Encoder sensor: http://www.junun.org/MarkIII/Info.jsp?item=48
Encoder schematic: http://www.acroname.com/robotics/parts/R64-P5587.html
It's tiny and it already has filters, Schmidt triggers and signal conditioning built in. The best $3 I've spent lately. I've been using it directly as a wheel encoder, but if you guys are sold on motor encoders I'm sure you can find a way. Pics attached.
@rpdb: You say you're screwing some old CDs on for your encoder disks. More power to ya. Be accurate, though. Your encoder disk consistency, flatness·and concentricity is·just as critical as round, true wheels are in the dangerous game of dead reckoning. That's all I'm doing these days and I'm learning a lot!
best,
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
I like your code, I'll try it tonight. I used it for ideas to write some changes to run my HB25s on the rev up/down section. I am so jelous of the resolution your getting with the usdigital encoders, I can probably only hope to have 72-144 ppr at the wheel for what I am working on if I machine some encoder plates. I just downloaded the specs to see if I have room to mount the usdigital units. My motor shafts are 0.128 or almost 1/8" (not 6mm) so I'll have to order the custom from usdigital (plus a cable and center tool and...). I have to check the shaft length as well. Are the encoder wheels Metal or plastic, and did they come with a set screw or just press on?
Here is some stuff I added to your code, I hope someone can use it for a prop bot
''
This Block creates a speed up/down Motor test on Pin7
or not on pin7
{remodeling or under construction, requires changes etc.
{{rpdb added this for use with a pair of HB25 controllers
'use the PWM.servo object = PWM_32_v2.spin
'PulseWidth ... 800 = 0.8ms (backward) / 1500 = 1.5 ms (stop) / 2200 = 2.2ms (forward) HB25 can go from 0.8 to 2.2 ms
'HB25 needs a 5 ms (recommended 5.25) pause between pulses, hoping spin overhead might should add 0.25ms? Ill test add 0.25ms if needed
' 'need to declare byte or long: PulseWidth, rampRate RPin = R_HB25, LPin = L_HB25
}
'PUB MotorTest(RPin) | PulseWidth, rampRate
repeat
repeat PulseWidth from 1500 to 2000 ''ramp up from stop to full fwd 1.5 to 2.0 ms 500 steps/step = ? or 0.x
Servo(RPin,PulseWidth) ''
waitCnt(ClkFreq /200 + cnt) ''minimum required 5ms between servo pulse for HB25
waitCnt(ClkFreq /rampRate + cnt) ''insert rampRate here depends on if adding a step rate
waitCnt(ClkFreq*5 + cnt) '' Hold at full forward for 5 sec
repeat PulseWidth from 2000 to 1500 ''now ramp down from full fwd to stop
Servo(RPin,PulseWidth) ''
waitCnt(ClkFreq /200 + cnt) ''5ms between servo pulse for HB25, add rampRate
waitCnt(ClkFreq*5 + cnt) '' Hold at stop for 5 sec
''now reverse
repeat PulseWidth from 1500 to 1000 ''ramp up(down?) from stop to full reverse step = ?
Servo(RPin,PulseWidth) ''
waitCnt(ClkFreq /200 + cnt) ''5ms between servo pulse for HB25, add rampRate
waitCnt(ClkFreq*5 + cnt) '' Hold at full reverse for 5 sec
repeat PulseWidth from 1000 to 1500 ''now ramp down from full reverse to stop
Servo(RPin,PulseWidth) ''
waitCnt(ClkFreq /200 + cnt) ''5ms between servo pulse for HB25, add rampRate
waitCnt(ClkFreq*5 + cnt)
}}
Next I want to work on a constant speed i.e. with PID feed back for load compensation.
Thanks
The QME-01 comes with a metal code wheel that is pressed onto the rear motor shaft and in my case at least, the electronics is attached with double sided tape. There was an earlier mention of screw attachment.
Alignment is critical as is distance from the code wheel but I easily managed to install it without an alignment tool.
There is also a plastic press on cover which keeps out stray light.
I would be interested in your PID drive when you get around to it.
Ray
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never force anything - Always get a bigger hammer.
The USDigital encoders that I got from Lynxmotion (QME-01), have aluminum encoder wheels that·press onto the·rear motor shaft. i didn't need to use the centering tool to install the encoder body. If you're careful you can do the job without it.
Although 400 ppr is nice, don't give up hope of getting good results with a lot less resolution. You need to look at·the accuracy that·"erco" is getting from his simple but effective wheel encoders on his home-grown platform. Clever coding can make up for a lot of hardware shortcomings (we landed men on the moon with computers that we would consider a joke today).
BTW, posting code as unformatted text as you did in your post destroys the indentation of your original code and makes it very difficult for someone to understand the repeat loops. Try enclosing your code using the "insert formatted code, #" symbol on the toolbar.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
The encoders I'm working on are very similar to yours. But, the tires and wheels are made in China, talk about run-out and concentricity, I am glad they are close to being what!! "round". I do have something close to a quadrature signal out though, close enough for a waitpeq at 90 or so degrees. I printed out some labels from an ACAD dxf file I created to make a CD-Stomper label with indecies(centers) for drilling the hub holes. I printed in dark blue, hoping to absorb IR (off spectrum) and use the reflective part of the disk for ON state. Works good so far.
Reflextive Sensors 4 ea $0.99 @ jameco
CDs and Print cost 2 ea $0.05
7414Schmidt and Board $5.00
The interface, my Mind and wallet still work -- priceless less $10.00
Thanks for your input erco
I love it when my kids come up to me with a zip lock bag of broken cell phone parts and say "check out this camera and lcd"
Unbelieveable repeatability. Anybody know who this "alsowolfman" is?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
I made some·progress using the USDigital encoders on my Stingray. Carpet (bumpy berber) is probably the worst thing to test on. I have to find a large, smooth, flat surface (indoors) to continue testing.
The main success I've had so far is getting the bot to go in a straight line. Encoders rule for that. Turns on carpet are much more challenging. I've attached the project in its current form. It has forward, reverse and all of the turn and spin moves. I need to borrow from Ray0665's earlier "poly" code and write a simple number of sides and length of side· polygon routine for testing (maybe this weekend).
Please take a look at what I've got so far and (gently) offer any suggestions that you might have for making it work better. If somebody tests this on a good smooth surface, please let me know how well it does as far as repeatability. It's just doing a 72" X 36" rectangle.
Duffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any technology, sufficiently developed, is indistinguishable from magic.· A.C. Clark(RIP)
Post Edited (Duffer) : 1/22/2010 7:38:25 AM GMT
I have both carpet (normal house carpet) and smooth wood tabletop surfaces. I have been doing some tests using my own code to work with the Quadrature_Encoder.spin and PWM_32_v3.spin objects. The code attempts to drive the motors at a given inches per second rate. It speeds up and slows down each motor as need to maintain the desired pulse rate from the encoders. However, it doesn't properly slow down one motor when the other is slowed (like when the wheel hits a bump). I'm going to work on that next. Even still, I get pretty good straight line movement on both surfaces. For turns I found that the carpet produced better results for spin turns across more different speeds. The wood surface works really well up to a certain (fairly slow speed) then it starts to overshoot more. I haven't tried driving in a circle yet, but I suspect that the wood surface will win.
I was hoping to post a video this week, but failed. I'll try to post one this weekend along with whatever code I have working then.
erco,
That video is impressive, but it's also moving very slowly on a smooth surface. That is about the slowest I can get my Stingray going without having the motors randomly stalling. I think I'll be able to get similarly good results eventually.
Roy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
NOW I think of this. All my time wasted. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Since the SD cards are normally on P0 through P3 I'd rather not put the encoders on those pins. What does everyone else think should be used as the standard pins for encoders?
Robert
This, and a buck will get you a bottle of pop from our machine :-)
John R.
I'm mainly concerned about the pins used for a pair of quadrature encoders (which should have been an option when the robot was released) to help encourage the development of better objects for the drive system.
The ability to use pins for whatever you want is a great feature of the propeller but it is nice to have some standards and constancy too.
Robert
I was going through different threads for the Stingray today and was wondering if anyone has or had made any further progress with the Stingray using the USDigital encoders or any other obstables?
thanks
Same question now: Anyone?
Chris, It seems that the Stingray isn't getting a whole lot of lovin' these days. Any news on an "official" encoder?
Does anyone know if Parallax still has any interest in encoders and other accessories for the Stingray?
I am thinking that "rolling your own" is the only option for Stingray repairs and upgrades. I have been using the USDigital encoders, and have also had good luck with them. The level shifters never worked well for me on the original control board, so I replaced it with a Prop Platform and a Pololu motor driver which works great. Next step is to find suitable lower RPM motors, as wisely suggested by Erco. Can anyone suggest a source?
Lev
My understanding is that we're turning the Stingray into a more modular platform, with more modular controllers and processor boards (rather than a fully integrated "canned" solution - It would add a lot more flexibility to the electronic capabilities - I've already created some new "levels" designs for upper decks on the platform that may soon be available as add-ons.
But let's see what Chris has to say - I'll rattle his cage ;-)
-Matt
I know, I know. I assure you that we feel your pain. So many products/projects in the pipeline, and not enough time to go around. I'll see what/who I can scare up...(FYI, around here I'm the rabble-rouser-just ask anyone-especially Ken)
-Matt
Matt,
I agree, I think modular is a great way to go. My wish list is something like a DIP prop board (like the Propeller Platform) so those inevitable burnouts can be inexpensively repaired; an independent motor driver, slower replaceable motors, a sensor connection board that brings out the Prop pins and 3.3 and 5V power (similar to the ProtoPlus or the Wulfden servo control board), standard interconnects,. Oh, and a BoeBot like projects book for my students, some who are past the BoeBot/BOE and want more. That could all be done in a week or less, right
To start, I liked (and still like) the stingray because it is relatively large (which allows mounting quite a few things on it), it is fast (2.4 met/sec doesn't sound fast, but boy, that thing can go!), and its structure (differential wheel drive with swedish tail/front wheel) is frequently used on robotics textbooks for kinematic analysis, thus students can readily apply concepts to the platform.
So after working with it for a while now, I can see the limitations of the current board but also its positive aspects. The architecture I ended up with involves using the existing Stingray board as a low level bot controller, and a different board for the high level functions. There are multiple reasons for this decision. After some experimentation, I realized that there is just not enough memory and speed on a prop to run some of the traditional robotics algorithms (probabilistic mapping, navigation etc.) Also, I am building a simulator that would be used before students get access to the hardware, and the actual platform has to be source code compatible with the simulator, making Spin an issue. Last, but not least, I simply run out of cogs and I/O pins in the current configuration. I have added the quadrature encoders, 5 IR sensors, 2 stationary PINGs, one PING on a servo, a rate gyro, and a magnetometer. Adding 4 pins for SPI communication to the master board that runs the high level AI, more or less has used up just about every I/O pin and all cogs, to the point where I am having to make some tough decisions on which capability to drop. One such case is use of the quadrature encoders. In my mind, to properly do odometry would require 2 maybe even 3 cogs, but I am forced to use a single cog and one of the two channels on each encoder. I would also love to add a small LCD but there is just not enough capacity to do so.
So to me, the most useful feature would be to have not one, but multiple propellers integrated into a board for the Stingray. One propeller would be dedicated to motor control and odometry calculations. Another one or two propellers would be dedicated to sensor I/O and that leaves a propeller to do AI and coordination. So 4 props minimum, but 8 would also be nice. Sharing some pins to allow prop-to-prop communcation would do wonders!
[By the way, what's the plan on the Propeller II, that would solve a lot of these problems!!!]
Anyway, these are my 2c for now. I am currently working on using the encoders to do trajectory control; hope to be able to report good progress in the new future, maybe contribute a thing or two in the process.
Yes, I agree. The only issue that we have here is lack of time, but I know that we want to head in this direction- it's simply a matter of internal resources. I'm (we're) very "pro-robot" here, as well as "pro-robot education" too!
Will keep you posted on progress here, now that Maker Fair and "mystery project" have progressed nicely.
It's never fast enough for me either ;-)
-Matt
Adjusted for inflation, that's a whole lot more that 2c
-Matt
I'm also using the Stingray as my robot base, with the standard controller board.
I'm sad that it is not made anymore, because I wanted to use several (4) for the bot.
What I like in particular is the level shifting IO, but it seems that the IC's for that
(YE08?) are not available anywhere?
For the encoders I used the Sharp GP1A70R, normally used for printers.
It is interesting that the outputs could not drive the controller boards directly, I had to use
transistor amps. Do you have a schematich of the board? It would be interesting what the
IO interface looks like.
Friedrich
There's no computer fast enough, there's no memory big enough ...
The schematic of the MSR1 control board can be found here.
We may have a few MSR1's laying around here in tech support or my office. Let me see what I can find...
-Matt