Scribbler PWM Frequency
Anybody know the PWM frequency of the original Scribbler's motor drivers? That is, the freq of the power pulses received by the motors?
I can tear one apart and measure it (and I WILL if I have to), but surely someone in these hallowed halls knows the answer!
The reason? I have a trick up my sleeve to get dynamic braking on Scribbler. The two motors always coast different amounts when you shut them off, and the robot invariably turns.
I'm happily confident that PhiPi anticipated this and fixed it on S2!
I can tear one apart and measure it (and I WILL if I have to), but surely someone in these hallowed halls knows the answer!
The reason? I have a trick up my sleeve to get dynamic braking on Scribbler. The two motors always coast different amounts when you shut them off, and the robot invariably turns.
I'm happily confident that PhiPi anticipated this and fixed it on S2!
Comments
For each motor driver channel on the S2, the inputs are Motor_DIR and Motor_PWM. Consequently, the only way to get dynamic braking on the S2 is to reverse the motor directions momentarily (a brutish technique, which the S2 object does not perform). There's no hardware mode simply for shorting the motor coils to effect braking that way. That said, there is a ramp-down at the end of every motion profile, and I've seen no evidence in my experiments with the S2 proto that post-drive drift is an issue.
As to the Scribbler I question, I have no idea. The PWM was handled by a Chinese PIC processor knock-off. You'll probably just have to get your scope out and take a look.
-Phil
I'll probably use a 556 since I need two 555s for 2 motors anyway. So I need to tune the missing pulse detector circuit to the PWM frequency.
Now it's just a matter of time before my Scribbler becomes self-a-way-uh, as the Governator would say it.
Long live old blue! Wecome new Scribbler 2!
I have several S1s and their time is nigh.
I fully intend to outdo a stock S2's dead reckoning ability with old Blue and my Pathfinder software.
Have you seen the Lost in Space episode entitled "War of the Robots"?
Here is the Lost is Space episode - http://www.hulu.com/watch/139/lost-in-space-the-war-of-the-robots I am going to watch it asap.
Edit - LOL! What a classic...I guess old blue with never be out of style.
http://www.youtube.com/watch?v=hGQEzz8CNIQ
I opted to forego my previous scheme of missing pulse detection for flexibility and retaining the coasting option. I hard-wired one DPDT braking relay to pin 1, formerly the center photocell. In this simple arrangement, both wheels are braked at the same time. My 2 wheel encoders (pardon me, Wikipedia, tach sensors) are wired in place of the left & right photocell.
To use pin 1 as an output, I had to bypass the series SMT 220-ohm resistor and clip the center photocell lead. That's one of my 17 mA Aromat relays, so no driver transistor is needed.
BTW, this is a heavily modified Scribbler. In addition to the wheel encoders & braking mods, it has lower ratio gearmotors wired backwards (for quicker response), and built-in external charging contacts and a charge indicator LED, per my article at http://www.botmag.com/articles/scribbler.shtml
And I ain't done yet!
@PhiPi: According to "Hacker's Hints" PDF on the Scribbler, it uses PCM, not PWM. Does that sound right?
"Drive Motors – Motors.bs2
The Scribbler moves when velocity instructions are sent to both the right and left DC motors.
These motors are controlled by Pulse Code Modulation (PCM) signals using the PULSOUT command.
PULSOUT Pin, Duration
Pin will be either MotorRight or MotorLeft. Duration defines the signal pulse width, in 2
microsecond units. The DC motors will accept a Period value between 1000 and 3000.
These DC motors use PCM, where hobby servos use PWM (Pulse Width Modulation). "
agfa
Demonstrating coast vs brake is one of the reasons I decided to leave the coast option in, even at the expense of one i/o pin. Most people don't understand how important braking is.
The other reason is, it was much easier and faster to implement!
Will advise progress. I think I can port my Retrobot Pathfinder software over to Scribbler in one good evening. "And I woulda got away with it too, if it weren't fer these dang kids"!
One post, two classic TV references: Seinfeld and Scooby Doo.
Stopping is one area where bots using servos have an advantage over Scribbler. When you pulsout a stop pulse you get that same quick stop which prevents over steering and allows for accurate turns.
But Scribbler's motor controller means you don't need to tend the motor which has other advantages. So this mod allows for both advantages.
I know the S2 will be a big improvement over the original Scribbler, but this mod might be helpful (or necessary) to get useful dead reckoning out of that platform, too. I mean, 480 PPR is impressive, but that microscopic knowledge without fine motor control is not bringing much to the party.
While I'm on a rant, it appears that the motors & mechanicals of the S2 are pretty similar to the S1. There is room for improvement in the bushings and wheel couplings to eliminate backlash and better support the wheels, especially once we start adding arms & weight to the basic chassis.
That said, I can't wait to start hacking the new S2!
@erco, I was aware of this, but thought I didn't really understand your initial question. There is more good info in Writing Programs for the Scribbler Robot - http://www.parallax.com/Portals/0/Downloads/docs/prod/robo/scribbler/SPPG-WritingPrograms-v1.2.pdf
Edit -Great video and use of ancient quotations...you are truly a dad now!
Also, I recently found out that technically servos use pulse position modulation (PPM) which is similar, but not quite the same as PWM. I made this discovery because that other brand of microcontroller has dedicated PWM pins, but can do PPM on any pin.
So far, my best results have been to "set & forget" one motor at an intermediate speed, and switch the other motor into one of three states: faster, slower, or equal (open loop) speed. This is done by counting and comparing both wheel encoder pulses and knowing when the controlled wheel is ahead of, behind, or synced with the other mid-speed wheel. Using this technique, my bot is driving perfectly straight and stopping at exact, repeatable distances.
The dynamic braking relay activates instantly and stops the robot very quickly, as my previous video shows. This eliminates delays and coasting inaccuracies using the motor controllers to stop the bot. All my initial tests using one-wheel control and braking are very encouraging, even using one main drive speed without any ramping. Even with my higher ratio gearmotors with more torque, there is little chance of skidding the tires during acceleration or deceleration.
Long story short, I'm confident that I can modify my Pathfinder software to work properly, although it needs more tweaking than I originally thought. Will advise.
When I tried PID with a BS2, doing nothing but controlling the motor, it struggled just to keep up with one motor using a 34 pulse per rev encoder. That was the point I decided to try the propeller. It sure is nice, I set up one cog take care of encoder feedback, one to create PWM, and another coordinating the two.
I'm confident you can still rise to the challange of outdoing the S2. I know you'll keep us posted. Keep it up! I do enjoy reading your posts.
agfa
PULSOUT 12,2000' 2000 uS pulse stops right motor
PULSOUT 13,2000' 2000 uS pulse stops left motor
This has 2 problems. Mainly, it takes over 4 ms to execute this code; sending two 2 ms pulses plus overhead. That's a long time to ingnore my wheel encoders, I could miss a pulse and ruin my odometry efforts. Also, the wheels may start slightly out of sync since the commands are at least 2 ms apart. Now examine this code, which solves both problems:
HIGH 12:HIGH 13
PULSOUT 9,1730' 1700 fwd 1760 rvs
LOW 12:LOW 13
High & Low comands execute very quickly compared to a Pulsout. This sends nearly synchronous Pulses to Pins 12 and 13. First, both pins go high, I send a calibrated PULSOUT to an unused pin, then drive both motor controller pins low. I experimentally determined the PULSOUT value 1730 which stops both wheels, equivalent to two seperate 2000 PULSOUTs. 1730 is right between values 1700 and 1760, which I found barely began to turn the wheels in opposite directions. This new code executes in half the time (just one pulsout) and syncs the wheels better.
Using similar chicanery, I think I'll be able to speed up all motor commands to regain active control of both motors instead of fixing one and controlling the other, per my previous post.
And I gotta say, I really like your robot's girlfriend. She is a cutey, but unless mr big bot is being chivalrous and carrying her over a very big mud puddle, she may have to cut back on the cosmos!
The arm/claw and death ray should add half a pound, and I can use that traction.
But truthfully, bump switches would be more useful than the stall sensor, which may go. Another thing on my "to do" list.
I think you'll be much happier with the stall sensor on the S2. It's basically an encoder on the idler wheel.
-Phil
I knew I read something about that. This is what it says on the list of S2 features - "Improved stall sensor on rear wheel." Thanks for the confirmation that this is one of the improvements.