Protobot (My first robot)
Copper
Posts: 48
I've finally started designing/building my first robot. For now, I'm using a Propeller Activity board for its brain. I like the idea of building my own all in one board; but the activity board seems like a good solution in the interim.
The end goal: a robot that can autonomously "wander" a table without falling off, locate a 1.5" block, pick up the block, locate a 3" red paper circle (taped to the table), and set the block on the circle. (The "game" is based on a competition a local robotics club I go to is having; my robot won't be ready in time for the competition, but that's fine).
Naturally, I'm having a little trouble staying on top of the project. I have some specific questions, but I think I'll ask them below. Like it says in the title, this is my first robot, so I'm sure there are lots of questions I haven't thought to ask, so I would really appreciate any general suggestions/advice as well. Thanks in advance.
Before this goes any further, this is very much a work in progress. For one thing, I intend to replace the majority of the metal hardware with nylon. I expect that will cut the weight between 1/4 to 1/3. It's also likely I end up with clear plex, instead of smoked (it's smoked in the model because I had some sitting around the office; and it looks better in my CAD system (Solid Edge ST6)).
Now for the good stuff: pictures. I'll point out "relevant design decisions" I made as they occur to me.
The blue box is my "dummy activity board" (it'd be awesome if somebody knows of a model for the activity board. Also, if anybody wants any of my models, let me know and I'll make them available; I intend to post the whole model on grabcad or something when it's done).
Everything in the same grey as the claw was or will be 3D printed. I used a Uprint (first gen) for everything but the claw and gears which I had run on an Objet printer (polyjet 3D printer; very impressive). The resolution on the Objet is amazing. I think my claw was printed at 32 microns; but the machine can go down to 12 microns. Ultimately, I'll have all the plex pieces laser cut (does anybody have a laser cutting service for 1/4 plex theyd recommend?). I cut and drilled a piece of plexiglass I stole from the office for a temporary "brain shelf."
Parallax high speed servos and servo wheels for the drive wheels
"actuating motors": http://www.pololu.com/catalog/product/1570
battery is a cheapo I got on sale at radioshack: 8.7volts , 1800mAh if I recall.
Color pal to detect the circle.
QTI sensors for edge detection.
omni wheel : http://www.microrobo.com/48mm-lego-compatible-omni-wheel-w108.html
Block Sensor -> TBD
I have a small pressure sensor I could put in the claw, but I'm hoping I can "see the current draw change" quickly enough to "detect claw shut" (my primary concern is that the motors current draw is not as linear as I need it to be for this application, and that the motor would damage the claw before I detected a change in current). I wont really have any means of detecting the claw is open; but if it always starts out open with nothing in it (which it should), and closes, detects closed, and then opens a set period of time without detecting a current increase (which would indicate it had opened too far somehow). At that point, Im in a known open state. Then, when the robot attempts to pick up the block, Ill measure how long it takes before it detects a current increase. If it takes less time than was spent opening the claw, the claw has grasped something; otherwise, it has just closed all the way and should open back up and try again. As long as it's open enough, I don't care; and since the claw opens considerably wider than necessary, I have a good range of "acceptable openness.
Or, I thought about putting holes in the gears in the claw, and essentially building in an encoder. I would still try to use the current draw to detect when the claw has grasped something; but again, if thats not a safe/reliable way to detect the limits, I could use the pressure sensor. I would love some advice on reading current flow, and whether it can be a reliable method for sensing the claw has closed.
By the way, none of the 3D printed parts are threaded in the model. FDM 3D printers generally have a slightly lower resolution on the Z axis than the X and Y (has to do with the size of the bead of plastic (sort of like the curf of a sawblade) vs. the resolution of the stepper motors). As a result, for small scale parts, its not uncommon (in my limited experience) for holes in the Z planes to come out a little oblong. With holes above 1/4 its not generally noticeable (plus, holes in the X Y planes arent affected). At any rate I decided to play it safe, and instead of fighting with the printer getting it to print perfect parts, I just left the holes a hair undersized and then ran them through with a bolt (I didnt have a tap). So everything fits nice and snug. I should probably shrink the holes some more and drill them out so theyd be perfectly round too (and buy a tap).
Also, the grippers are black on the claw, because when I have the rest of the robot done, I want to try and get the claw re-printed on a Connex printer, which is basically an Objet that can combine multiple build materials into a single print job. So ultimately, what looks like they should be rubbery gripper tongs, should sort of be rubbery gripper tongs. The first claw will just be plastic.
Here's what I have so far:
Like I said before, I'm going to replace all the metal hardware with nylon hardware. Also, I haven't ordered the laser cut parts yet. I have files prepared to send off. I'm guestimating $60 - $80 dollars, which is enough money, that I figure I should finish designing everything before I order it. Mostly I need to flush out my block sensor and verify it will fit in the space allotted.
There's an IR receiver on top for Remote control (I wrote a little assembly driver for decoding Philips RC6 and RC6A signals (mostly as a learning exercise); I was going to share all my code when its finished, but if that sounds useful to anybody, Id be happy to share it now. Im sure it can be considerably improved, but it works).
The robot in the back is Protobots lego predecessor. I was using it to write some code for Protobot while Im still building it. But one of the wheels broke and I haven't gotten around to fixing it. I have the wandering with edge detection working, nothing else (except remote control, but thats sort of an aside to the main project).
I decided to use zip ties to mount the battery just save material.
I only have one size of 4/40 screws right now. When I order the nylon hardware, Ill get more appropriately sized screws.
Shaft collar for the D-shaft that holds the claw. With a little 4/40 brass threaded insert.
I cant mount the claw until I order stuff.
Just a little sloppy. I could probably cut the tolerances another 0.01 or 0.005
But hopefully it will prove out the concept.
Originally, I planned on buying metal worm gears, the same size and pitch as the ones I printed (different bore; Id have to print a little bushing so I could center them on the gearbox shafts), but after looking at what the Objet can do, I decided to print some that would just press fit onto the shaft. Unfortunately, that material (the Objet does a variety of materials) might not work for a worm gear. Too sticky. It might work with some lube. I havent really decided what my next move is. I could look into different materials on the Objet, and try to find a lower coefficient of friction. I would like to stick with plastic. It feels right. I figure the only reason not to use a metal worm gear, is it assures the claw teeth will fail first; but I suspect given the geometry involved with a worm gear, regardless of material, its pinion always fails first (spur gear, not sure Im using pinion correctly). Which in this case is unfortunate. Printing another worm gear after 5-10 hours of run time (which would be like 50-100 hours of robot time, given the claw won't be continuously running) is no big deal. If the teeth on the claw fail, I have to print an entire replacement claw.
Like I mentioned earlier, I need to finish designing my block sensor before I can/will order my laser cut parts. Above, I have a Ping sensor standing in for my block sensor; but I dont think I want to use a Ping sensor for this. I really only want to sense a small area (1-2) in front of the robot; that way I dont have to worry about the robot detecting the walls in the room or a chair 2 from the table or whatever. I saw a video of a boe bot object following with IR sensors (http://www.youtube.com/watch?v=T0WVKffg-ns). I would like to use IR for my block sensor; but Im not sure how to best approach it. To experiment, I set up two IR leds on either side of a single demodulating receiver (38khz; I got the receivers with a PE Labs kit) and it sort of works. However, it seems to lose track of stationary objects. When the receiver is moving, or the object is moving, the prop chip sees it; but if you set the block in front of the receiver, after a second, the prop chip loses sight of it[the block]. If you look at the receiver signal line with an oscilloscope, when everything is stationary, there are recurrent periods of detection. So one idea I had for improving performance, was to sample the receiver for 1ms periods or so, so I can catch at least one period of detection. But Im wondering if I need two receivers. It looks like most of the BOE bots doing IR object avoidance use two receivers; and Im not sure why. Also, for aligning the robot with the block, the PE labs talk about sweeping the IR Led from a 100% duty signal to a 0% duty signal to get a distance reading. Couldnt I use a single receiver, and sweep the IRs, then when both IRs are detected at the same duty cycle (whether its 80%, 50%, or 100%) then Ive triangulated the block? Keep in mind there will be nothing else on the table to interfere with the sensor, so it can afford to be a little rudimentary.
This post is stupidly long.
In short:
Does anybody have a laser cutting service for 1/4 plex theyd recommend?
(I found these guys, and went through their tutorial http://www.customlasercutting.com/info/tutorials; but they dont carry smoked plex in 1/4 ; I didnt do any price comparrisons either.)
Does anybody know where I could get a model for the activity board (to lazy to model it for this project)?
I would love some advice on reading current flow, and whether it can be a reliable method for sensing the claw has closed.
Does anybody have experience making / 3D printing worm gears?
I have virtually no experience with IR object detection. Is this a reasonable approach to detecting a 1.5 block (there will be no obstacles)? How should I approach aligning the robot with the block?
Again, thanks in advance for any suggestions/advice; and Id be happy to answer any questions.
First steps.
<span style="background-color: transparent; vertical-align: baseline;">
The end goal: a robot that can autonomously "wander" a table without falling off, locate a 1.5" block, pick up the block, locate a 3" red paper circle (taped to the table), and set the block on the circle. (The "game" is based on a competition a local robotics club I go to is having; my robot won't be ready in time for the competition, but that's fine).
Naturally, I'm having a little trouble staying on top of the project. I have some specific questions, but I think I'll ask them below. Like it says in the title, this is my first robot, so I'm sure there are lots of questions I haven't thought to ask, so I would really appreciate any general suggestions/advice as well. Thanks in advance.
Before this goes any further, this is very much a work in progress. For one thing, I intend to replace the majority of the metal hardware with nylon. I expect that will cut the weight between 1/4 to 1/3. It's also likely I end up with clear plex, instead of smoked (it's smoked in the model because I had some sitting around the office; and it looks better in my CAD system (Solid Edge ST6)).
Now for the good stuff: pictures. I'll point out "relevant design decisions" I made as they occur to me.
The blue box is my "dummy activity board" (it'd be awesome if somebody knows of a model for the activity board. Also, if anybody wants any of my models, let me know and I'll make them available; I intend to post the whole model on grabcad or something when it's done).
Everything in the same grey as the claw was or will be 3D printed. I used a Uprint (first gen) for everything but the claw and gears which I had run on an Objet printer (polyjet 3D printer; very impressive). The resolution on the Objet is amazing. I think my claw was printed at 32 microns; but the machine can go down to 12 microns. Ultimately, I'll have all the plex pieces laser cut (does anybody have a laser cutting service for 1/4 plex theyd recommend?). I cut and drilled a piece of plexiglass I stole from the office for a temporary "brain shelf."
Parallax high speed servos and servo wheels for the drive wheels
"actuating motors": http://www.pololu.com/catalog/product/1570
battery is a cheapo I got on sale at radioshack: 8.7volts , 1800mAh if I recall.
Color pal to detect the circle.
QTI sensors for edge detection.
omni wheel : http://www.microrobo.com/48mm-lego-compatible-omni-wheel-w108.html
Block Sensor -> TBD
I have a small pressure sensor I could put in the claw, but I'm hoping I can "see the current draw change" quickly enough to "detect claw shut" (my primary concern is that the motors current draw is not as linear as I need it to be for this application, and that the motor would damage the claw before I detected a change in current). I wont really have any means of detecting the claw is open; but if it always starts out open with nothing in it (which it should), and closes, detects closed, and then opens a set period of time without detecting a current increase (which would indicate it had opened too far somehow). At that point, Im in a known open state. Then, when the robot attempts to pick up the block, Ill measure how long it takes before it detects a current increase. If it takes less time than was spent opening the claw, the claw has grasped something; otherwise, it has just closed all the way and should open back up and try again. As long as it's open enough, I don't care; and since the claw opens considerably wider than necessary, I have a good range of "acceptable openness.
Or, I thought about putting holes in the gears in the claw, and essentially building in an encoder. I would still try to use the current draw to detect when the claw has grasped something; but again, if thats not a safe/reliable way to detect the limits, I could use the pressure sensor. I would love some advice on reading current flow, and whether it can be a reliable method for sensing the claw has closed.
By the way, none of the 3D printed parts are threaded in the model. FDM 3D printers generally have a slightly lower resolution on the Z axis than the X and Y (has to do with the size of the bead of plastic (sort of like the curf of a sawblade) vs. the resolution of the stepper motors). As a result, for small scale parts, its not uncommon (in my limited experience) for holes in the Z planes to come out a little oblong. With holes above 1/4 its not generally noticeable (plus, holes in the X Y planes arent affected). At any rate I decided to play it safe, and instead of fighting with the printer getting it to print perfect parts, I just left the holes a hair undersized and then ran them through with a bolt (I didnt have a tap). So everything fits nice and snug. I should probably shrink the holes some more and drill them out so theyd be perfectly round too (and buy a tap).
Also, the grippers are black on the claw, because when I have the rest of the robot done, I want to try and get the claw re-printed on a Connex printer, which is basically an Objet that can combine multiple build materials into a single print job. So ultimately, what looks like they should be rubbery gripper tongs, should sort of be rubbery gripper tongs. The first claw will just be plastic.
Here's what I have so far:
Like I said before, I'm going to replace all the metal hardware with nylon hardware. Also, I haven't ordered the laser cut parts yet. I have files prepared to send off. I'm guestimating $60 - $80 dollars, which is enough money, that I figure I should finish designing everything before I order it. Mostly I need to flush out my block sensor and verify it will fit in the space allotted.
There's an IR receiver on top for Remote control (I wrote a little assembly driver for decoding Philips RC6 and RC6A signals (mostly as a learning exercise); I was going to share all my code when its finished, but if that sounds useful to anybody, Id be happy to share it now. Im sure it can be considerably improved, but it works).
The robot in the back is Protobots lego predecessor. I was using it to write some code for Protobot while Im still building it. But one of the wheels broke and I haven't gotten around to fixing it. I have the wandering with edge detection working, nothing else (except remote control, but thats sort of an aside to the main project).
I decided to use zip ties to mount the battery just save material.
I only have one size of 4/40 screws right now. When I order the nylon hardware, Ill get more appropriately sized screws.
Shaft collar for the D-shaft that holds the claw. With a little 4/40 brass threaded insert.
I cant mount the claw until I order stuff.
Just a little sloppy. I could probably cut the tolerances another 0.01 or 0.005But hopefully it will prove out the concept.
Originally, I planned on buying metal worm gears, the same size and pitch as the ones I printed (different bore; Id have to print a little bushing so I could center them on the gearbox shafts), but after looking at what the Objet can do, I decided to print some that would just press fit onto the shaft. Unfortunately, that material (the Objet does a variety of materials) might not work for a worm gear. Too sticky. It might work with some lube. I havent really decided what my next move is. I could look into different materials on the Objet, and try to find a lower coefficient of friction. I would like to stick with plastic. It feels right. I figure the only reason not to use a metal worm gear, is it assures the claw teeth will fail first; but I suspect given the geometry involved with a worm gear, regardless of material, its pinion always fails first (spur gear, not sure Im using pinion correctly). Which in this case is unfortunate. Printing another worm gear after 5-10 hours of run time (which would be like 50-100 hours of robot time, given the claw won't be continuously running) is no big deal. If the teeth on the claw fail, I have to print an entire replacement claw.
Like I mentioned earlier, I need to finish designing my block sensor before I can/will order my laser cut parts. Above, I have a Ping sensor standing in for my block sensor; but I dont think I want to use a Ping sensor for this. I really only want to sense a small area (1-2) in front of the robot; that way I dont have to worry about the robot detecting the walls in the room or a chair 2 from the table or whatever. I saw a video of a boe bot object following with IR sensors (http://www.youtube.com/watch?v=T0WVKffg-ns). I would like to use IR for my block sensor; but Im not sure how to best approach it. To experiment, I set up two IR leds on either side of a single demodulating receiver (38khz; I got the receivers with a PE Labs kit) and it sort of works. However, it seems to lose track of stationary objects. When the receiver is moving, or the object is moving, the prop chip sees it; but if you set the block in front of the receiver, after a second, the prop chip loses sight of it[the block]. If you look at the receiver signal line with an oscilloscope, when everything is stationary, there are recurrent periods of detection. So one idea I had for improving performance, was to sample the receiver for 1ms periods or so, so I can catch at least one period of detection. But Im wondering if I need two receivers. It looks like most of the BOE bots doing IR object avoidance use two receivers; and Im not sure why. Also, for aligning the robot with the block, the PE labs talk about sweeping the IR Led from a 100% duty signal to a 0% duty signal to get a distance reading. Couldnt I use a single receiver, and sweep the IRs, then when both IRs are detected at the same duty cycle (whether its 80%, 50%, or 100%) then Ive triangulated the block? Keep in mind there will be nothing else on the table to interfere with the sensor, so it can afford to be a little rudimentary.
This post is stupidly long.
In short:
Does anybody have a laser cutting service for 1/4 plex theyd recommend?
(I found these guys, and went through their tutorial http://www.customlasercutting.com/info/tutorials; but they dont carry smoked plex in 1/4 ; I didnt do any price comparrisons either.)
Does anybody know where I could get a model for the activity board (to lazy to model it for this project)?
I would love some advice on reading current flow, and whether it can be a reliable method for sensing the claw has closed.
Does anybody have experience making / 3D printing worm gears?
I have virtually no experience with IR object detection. Is this a reasonable approach to detecting a 1.5 block (there will be no obstacles)? How should I approach aligning the robot with the block?
Again, thanks in advance for any suggestions/advice; and Id be happy to answer any questions.
First steps.
<span style="background-color: transparent; vertical-align: baseline;">
Comments
I really like the 3D printed parts.
Chris Wardell
My only comment is in regards to dead reckoning, or navigation by odometry and counting wheel revolutions, if that interests you at all. You want to avoid skidding your wheels to retain accuracy. Your bot is fast and long. Long, in that your battery CG appears to be a ways behind your front drive wheel axle centerline, so there is more weight on your tail omniwheel than a robot with center-mounted wheels, like a Scribbler, S2 or Eddie. That pendulum effect works against a differentially-steered robot on fast turns and bumps (more weight on your omniwheel means a bump on your omniwheel may steer your bot in an unintended direction). To "mitigate risk" you can slow down and/or shift some weight off your omniwheel and forward toward your drive wheels.
Other than that, it looks fantastic and I also look forward to seeing where this and your future bots take you!
This video explains a lot about the CG position stuff erco mentioned. I thought it well worth the watch.
What about Lego worm gears? They're probably not the right pitch but it might be worth using the same pitch as Lego gears in your robot in order to take advantage of some of the Lego parts. I use Lego gears and turntables in lots of my robots.
If you don't already know about it (and even if you do), Bricklink is a great place to buy Lego gears and parts. Here's link to some of their worm gears.
-Phil
I watched David Andersons robot presentation (Very informative. Thanks Duane. PS: Im also a big fan of legos, but was afraid of trying to manufacturer teeth that small).
I had thought some about dead reckoning. I started this project before parallax released their ActivityBot Encoder Kit http://parallax.com/product/32501; but I could simply buy that kit (and wheels I expect), and attatch the encoders to the underside of my servos. Given their profile (mainly being so close to the wheels) I dont see a huge downside. Thats probably what Ill do when I decide to start experimenting with that stuff. Or I could redesign my servo mounts to make room for the encoders on top.
Also, has anybody tried to use a spare cog to monitor servo pwm channels, and try to estimate position from that? I dont know that even purpose built continuous rotation servos will reliably rotate the same number of degrees given a particular pulse width, but in a perfect world they would, right? If thats the case, then you could just experimentally determine how many degrees of rotation you get for each different pulsewidth you will ever send the servo (unless it appeared to be a fairly linear relationship, then you could use a formula; also, you would have to determine your degrees for each pulsewidth at the last second so you account for that particular robots weight with that particular battery running on that particular surface, etc.), and then how far you have gone based on total degrees rotation (positive or negative) and the diameter of the wheels.
It would probably only work on smooth level terrain. It its possible at all. Just a thought I had...
At any rate, there was also a section in that video where he discussed IR object avoidance. Curiously, he had yet another configuration of LEDs and Receivers. He had two central LEDs with two receivers, a couple inches away, on the outside. From what Ive seen, It looks like most of the boe bots have two separate emitter + receiver pairs facing forward but away from each other. I did some more reading this morning, and finally came up with the right google search: IR object following (I had been searching for IR object detection, which was less relevant to this application) and finally found some good stuff.
In case anybody else might be interested:
http://www.mycontraption.com/desktop-robot-object-tracking-with-infrared/
http://letsmakerobots.com/node/4428
both of those links describe using basic IR detectors (as opposed to demodulating IR receivers) for basic IR object following.
Neat looking product, and a video demo
http://www.robotshop.com/en/dagu-compound-infrared-sensor.html
http://www.youtube.com/watch?v=PYDctJ_Ouw0
also uses basic IR detectors, meaning I would have to accommodate for the ambient IR light, in addition to needing the appropriate circuitry for reading analog inputs with the propeller (I would use RC circuits; is there a better/different way for the prop chip to read analog inputs?)
Back to emitter/receiver configurations, I think I would like to use a single receiver, with two emitters set to either side. I suppose using two receivers might maximize my sensor range, but it seems like I should be able to do it very nearly if not just as well with one receiver. Unfortunately, I havent had much time to experiment with it yet. Any thoughts?
(I refuse to cut leads until the last second; you only get to cut them once)
For whatever configuration I go with, Im going to want to move things over to a little custom built perf board sensor module with female headers so I can just jump it to the Activity Boards bread board. I have done some soldering (and desoldering), but Ive never worked with perf board before. Does anybody have any tips or links I should read?
As for the claw, I think Ill just go with what I have, and find some appropriate lubricant if I have too; and plan on reprinting the worm gear (and maybe the claw) in a less sticky material.
Also, I discovered today the robotics club I go to has access to a laser; so next Monday, Im going to go look at getting some parts cut.
Another horrendously long post.
Again, thanks for the feedback.
I've purchased the new ActivityBot wheels and the high speed servos but I couldn't bring myself to pay $38 for the encoders. I'm pretty sure I can make my own encoders for a couple of dollars.
I've tried to add encoders to the inside of servos a couple of times. One attempt used magnetic encoders and another attempt was using a P5587 encoder erco gave me. It may be possible to get either of these methods to work well but just adding encoders wheels is a lot easier.
Something like this may be possible if you were willing to spend the required time to come up with a good calibration table but again, adding encoder to the wheels would be so much easier.
I learned the CR servo that came with the BOE-Bot are pretty consistent with their speed for any given servo pulse. Once again following erco's lead I attempted to record the path my robot took. I drove my robot by remote around a (very lumpy) figure 8 path while the robot recorded the pulses to the servos on a SD card. I was surprised at how well the recorded path matched the original path.
If you're not using encoders to monitor speed, then you want to make sure your servos have a well regulated power supply. If you power your servos directly from the batteries, the speed of the servos will change as the voltage of the battery pack drops.
Phil wrote a good article about using encodes for odometry. I thought I had a link to it in my index but I was wrong. Hopefully someone will provide a link to it.
The Scribbler 2 uses two IR emitter and a single receiver.
The Let's Make Robots link above is to a post by "OddBot". OddBot works for Dagu and I'm pretty sure he's the one who designed the compound IR sensor you also linked to.
IMO, neither IR sensor or ultrasound sensors are reliable enough to use alone. I was very pleased to see how well the two sensors complimented each other when I added a ultrasound sensor to my S2. Objects not seen by one sensor were usually seen by the other. The only exception was our couch. The IR sensors were too low to see it and the ultrasound was absorbed by the couch. The robot didn't detect the couch until the ultrasound sensor was pushed up against the couch. When the padding of the couch was compressed, the ultrasound appeared to be able to see the inside frame of the couch.
I use perf board a lot in my projects. While I still occasionally use the cheap stuff with a little circle of copper around the holes on one side of the board, I usually use the more expensive perf board with through hole plating. Parallax sells some nice perf board which has a ground plane in between the holes and pads. The Parallax perf board has a couple vdd and vss buses. While these buses can be useful, I think they are more frequently in the way. SparkFun's perf board doesn't have these buses so I probably use SparkFun perf board more than I use the perf board from Parallax.
One reason I don't like the cheap perf board is the little copper rings can easily come off when a part is being soldered.
I don't know if you've ever used DipTrace or other PCB layout software but once you get used to laying out boards with the software, it becomes faster to design the board with the software and then have the boards made by OSH Park. The main problem with having a custom PCB made is waiting the three weeks for the boards to come in. Since I often have multiple projects going at once, I'll work on one of my other projects while I wait for the PCBs to be made.
Using a custom PCB is faster than having to make lots of point to point solder connections when using perf board.
Wow, that's amazing precognition you have there. How did you know this was going to be horrendously long?
It's always fun to see other people's robot projects. Thanks for sharing your progress with us.
Maybe I could color half the ridges with white-out or something, but it seems worth considering (and of course I could just order the activity bot wheels). Or I could use DC motors. Then I would have lots of encoder options to explore.
Also, all this dead reckoning talk reminded me I currently dont have any way to detect the claws wrist angle.
So much to keep track of.
I thought about building an encoder for the D-shaft (I think of it as the wrist), but given it shouldnt be rotating much more than 90 degrees, I think Im leaning towards just using a nice potentiometer. I have a pretty nice one I rescued from an old sony 5 disc changer; I might just mount it underneath the wrist shaft and model up some little gears for it.
Thats sort what I figured. Good to know though.
Also good to know. Im actually pretty impressed.
That would explain why theyre so similar. Definitely an approach to keep in mind.
Youre in good company. Parallax has a nice PING/IR kit http://parallax.com/product/725-28998, but I already have a coulple ping sensors, so I would probably just 3D print a mount that would incorparate an IR emitter and reciever.
However, for this project, given the only thing Im going to try and detect is a wooden block, I think I might try and get away with IR alone. I could always add a ping sensor later.
Hearing the S2 uses a single receiver and two emitters was enough to get me back on that project. I moved my sensor over to my development board and started writing a little PASM driver for monitoring the block sensor. I have a spin method that works okay, and could maybe be improved; but I want the speed for when I incorporate a duty signal sweep on the LEDs. I also just like the practice.
It sort of works. Unfortunately, Ive got my left and right readings tangled up somehow. Even when you remove one of the leds, if one detection is made, both are reported as having detected an object.
I think the problem is in there somewhere; Ill attach the whole code too (just didnt want to make a mess).
sample mov :Ldetect, #1 'reset "detection registers" mov :Rdetect, #1 mov ctra, L_cntr 'L_IR -> ON mov :time, cnt 'set up loop :rollover_1 add :time, _space wc if_c jmp #:rollover_1 :check_left and S_PINmask, ina wz, nr 'start loop if_z mov :Ldetect, #0 'if detected, set to 0 cmp :time, cnt wc if_nc jmp #:check_left 'loop mov ctra, R_cntr 'L_IR -> OFF ; R_IR -> ON mov :time, cnt 'set up loop :rollover_2 add :time, _space wc if_c jmp #:rollover_2 :check_right and S_PINmask, ina wz, nr 'start loop if_z mov :Rdetect, #2 cmp :time, cnt wc if_nc jmp #:check_right wrlong :Ldetect, left_addr wrlong :Rdetect, right_addr jmp #cmd_done :time long 0 :Ldetect long 0 :Rdetect long 0I will absolutely be looking into getting some custom PCB boards made. I need to choose and start learning a PCB layout solution. I have access to some software that integrates with my CAD system. I should probably check that out first.Again, thanks for the great response.
Ill definitely try to keep this thread updated. Tomorrow Im going to order the nylon hardware for the final assembly, and then Ill be working on incorporating a potentiometer into the "wrist."
I decided to go back to smoked plex. The laser cutting service I was looking at didn't offer smoked plex in 1/4", so I was considering "clear," but I think I like smoked better.
My block sensor will (hopefully) mount on the four screws on the top side of the bumper.
As for the "wrist sensor" (for detecting wrist angle), I came across this:
http://www.robotshop.com/en/softpot-rotary-potentiometer.html
I'm going to have to look at it more carefully tomorrow, but I'm thinking I can print a modified version of the shaft collar I printed for the D shaft (one with a little bump to line up with the soft pot's contact surface) and sandwich the soft pot between it and the plex on the "left" side of the robot (the left side of the robot being on the right side of the picture above; the side without the spur gear).
I needed some special size 1.1" x 1/16 round lenses made for a new product sample run ASAP. They had some similar, but too small, on E-Bay so I messaged them on Friday evening what I needed. They posted a custom listing for me Saturday night (after he understood just what I wanted) and then cut them on Sunday and mailed them out for me on Monday. I was amazed.
Great job on the robot design! It will make an excellent topic of robot design engineering for my son.
I have one of those softpots but I haven't used it enough to have much of an opinion about how well they work but they do seem like kind of an awkward way to add position feedback. As I mentioned earlier, I've been experimenting with magnetic encoders for position feedback. What's nice about the magnetic encoders is they don't wear out the way potentiometers do. Phil used some refrigerator magnet tape and a hall-effect sensor as a position feedback device. Phil's method is nice since you don't need access to the center pivot point.
hmm...
The magnetic encoder I linked a couple of times gives a 12-bit position as feedback. Post #15 of the software thread shows the numeric feedback from the encoder.
I'd be very hesitant to rely on a gap. What's the difference between a gap and very slow movement? IMO, some sort of limit switch would be a better alternative.
Somehow I missed this thread. Very nice robot! What CAD software do you use?
I am happy to do laser cutting for robotics projects. Keep me in mind if you need to do hundreds or thousands, or for those that do not have access to a laser and need small quantities I can help there too.
Also, hopefully I'm going to get my parts cut on monday at one of the local colleges. I'm only building one Protobot, and all my parts fit in a 6.5"x10" rectangle (if you open the drawing pic in a separate tab, the original image is to scale). But thanks for the offer. I'll keep it in mind.
Second:
Encoders. I need to spend a little more time reading about encoders. At some point I read a little about incremental encoders; but today is the first I've ever heard of absolute position encoders. I think the magnetic encoder Duane Degn linked earlier (I have to read more about that too) would be considered some sort of absolute position encoder. For anyone who might not know, there are "magnetic encoders" that measure the angle a magnetic field intersects a "sensor" to determine the encoder's absolute position. Go figure. BTW: for anybody who might be wondering how non magnetic absolute position encoders might work (like I was all morning) they utilize an "encoded element" (like a wheel or a strip; similar to incremental encoders) with each identifiable position uniquely "labeled"
like that.
So, the question is, how best to translate the rotation of the wrist to exactly what kind of absolute position encoder?
PS: If I didn't want to use an encoder, I could probably build a potentiometer into my wrist joint pretty easily. I would just need to mount some sort of C shaped ring around the d-shaft on the exposed side of the plex, and then mount a wiper off the d-shaft. But I should become familiar with encoders regardless.
http://botscene.net/2012/10/18/make-a-low-cost-absolute-encoder/
The idea is to use an IR emitter and detector to determine the position of the gray scale wheel. (the approach above actually takes two detectors; but given I don't need more than 90 degrees of rotation, I'm thinking about trying it with one sensor, and a simpler wheel
"that" wrapped around a 150 degree arc or something)
Besides being dirt cheap to build (I already have everything I need) it only takes two lines on the propeller. 1 for the LED and 1 for the detector. So long as I accommodate for ambient IR, it seems like it should be good enough for my robot (if I wanted to try and eliminate ambient IR (enclose the sensor some how) then it would only take one line on the propeller; since I could just run the emitter off the rail).
...
I'll probably end up using limit switches in place of, or at least in addition to whatever simple position sensor I go with. I probably need to put a bump sensor on the front of the robot too, to detect the block. I just like to do things the hard way.
I got my laser cut bumper assembly laser cut.
The idea is to use two IR LEDs set on either side of a receiver, and sweep the intensity of the light emitted by each LED to determine which LED is closer to the target.
I have both LEDs running into P6; the duty signal pin. I can get the LEDs to light with little blinky spin programs, so I know the pins and LEDs are good. I also have a little spin program for IR distance detection I took out of the PEkitlabs and it works.
If I run my code with the LEDs running into ground, I get lights, so I think the object detection routine is being called and executed. But If I run the LEDs into P6, I do not get lights. Which would lead me to beleive I have improperly configured ctrb for generating duty signals, or P6 is not an input somehow, or for some reason I'm unaware of, I can't run both LEDs into P6 (they alternate so only one is on at a time (I did wonder if I need some diodes protecting the LEDs from each other, but they seem to still work just as well as when I started)) or something else I either don't know or haven't thought of.
I tried breaking out only the necessary code for running the LEDs and duty signal, so it would be easier to trouble shoot.
CON _clkmode = xtal1 + pll16x ' System clock → 80 MHz _xinfreq = 5_000_000 PUB main cognew(@align, 0) DAT org 0 align mov temp, #1 'config pins shl temp, #9 ' ... muxnz dira, temp mov temp, #1 shl temp, #7 muxnz dira, temp mov temp, #1 shl temp, #6 muxnz dira, temp mov temp, #1 shl temp, #2 muxnz dira, temp muxnz outa, temp mov S_PINmask, #1 shl S_PINmask, #8 muxz dira, S_PINmask 'verify sensor set to input (presumes Z==0) :start mov ctrb, G_cntr 'set ctrb for duty signal mov :duty, top mov :minLduty, top mov :minRduty, top :loop sub :duty, :dinc 'dinc :duty mov frqb, :duty 'config ctrb for new duty call #sampleCALL 'scan for block cmp left, #0 wz 'check left if_z mov :minLduty, :duty 'if detected, store current :duty cmp right, #0 wz 'check right if_z mov :minRduty, :duty 'if detected, store current :duty cmp :dinc, :duty wc 'check :duty if_nc jmp #:loop 'if :dinc < :duty, loop andn outa, temp 'turn debug light off jmp #:start :duty long 0 :minLduty long 0 :minRduty long 0 :dinc long 1000 DAT sampleCALL sample mov Ldetect, #1 'reset "detection registers" mov Rdetect, #1 'L_IR mov ctra, L_cntr 'L_IR -> ON mov time, cnt 'set up loop :rollover_1 add time, _space wc if_c jmp #:rollover_1 :check_left and S_PINmask, ina wz, nr 'start loop if_z mov Ldetect, #0 'if detected, set to 0 cmp time, cnt wc if_nc jmp #:check_left 'loop 'rest mov ctra, #0 'L_IR -> OFF mov time, cnt 'rest add time, _space waitcnt time, #0 'R_IR mov ctra, R_cntr 'R_IR -> ON mov time, cnt 'set up loop :rollover_2 add time, _space wc if_c jmp #:rollover_2 :check_right and S_PINmask, ina wz, nr 'start loop if_z mov Rdetect, #0 cmp time, cnt wc if_nc jmp #:check_right mov ctra, #0 'R_IR -> OFF 'report wrlong Ldetect, left_addr wrlong Rdetect, right_addr ' rdlong temp, PAR ' cmp temp, one wz 'check sample or sampleCALL ' if_z jmp #cmd_done sampleCALL_ret ret DAT 'SPIN <-> PASM addr's cmd long 0 left long 0 right long 0 sensor long 0 gnd long 0 'PASM -> SPIN cmd_status values zero long 0 one long 1 'BS values FReQA long 2040109 '2040109.4656 == (frequency*2^32)/clkfreq top long 4294967000 '(round to nearest :dinc) (could +:dinc for max range) ' 2³²== 4294967296 _space long 160000 '2ms L_cntr long ((100 << 26)|9) R_cntr long ((100 << 26)|7) G_cntr long ((110 << 26)|6) S_PINmask long 0 Ldetect long 0 Rdetect long 0 time long 0 temp long 0 cog byte 0 mem_addr res 1 left_addr res 1 right_addr res 1 sensor_addr res 1 gnd_addr res 1 L_IR res 1 R_IR res 1 S_PIN res 1 G_PIN res 1I got the QTI sensors, and the color PAL hooked up (hopefully I have enough IO on the activity board to get everything connected at the same time; at the moment, I don't even know what everything is...).
Anyhow, with all the QTI sensors hooked up, I could start working on a simple random walk routine. It's fairly random. It just uses the ? random operator. So technically It's only sudo random. Plus I limit the spin duration (.25sec min, 3sec max (direction is random)), and it has a simple escape routine it goes into when it gets stuck.
The idea is to have the robot just randomly run around the table until it detects an object, then exit the random walk while it aligns with and picks up the block, then re-enter the random walk; but this time instead or searching for an object, it will sample the surface color until it finds the circle where it's supposed to set the block.
Unfortunately, I have not made any progress with the block sensor. I may have some time to work on that today.
I also haven't even started working on the wrist position sensor, or the grip sensor.
Things are moving along, but I've got a ways to go.
Welcome to the real world of robotics!
The state of the system clock "cnt" is pretty random if the chip has even been powered up before. The clock doesn't reset when the Propeller is turned off. You can use it as a "seed" for the pseudo random number generator to get something which is pretty darn close to random.
There's also a real random generator with uses some internal noise to generate real random numbers.
It's good to see your robot moving. How about a figure 8? (I figure it's my turn to ask since erco just asked another roboticist about entering the challenge.)
That's awesome. I will definitely do that. It's a particularly good Idea in this case, since the random walk doesn't start until I hit a button on my TV remote.
As for the block sensor, I'm totally stuck. I've checked everything I can think to check, and everything looks correct; but no lights. If I comment out the line that sets ctrb to duty mode (00011000000000000000000000000110 specifically) I get lights; but of course, no duty signal.
To check the circuit, I modified the PElabs example spin program, and it effectively does what I want, just really slowly (and it's not as granular as the PASM code should/will be).
pekittest.spin
(assumes the object is centered between LEDs)
The only difference between it and my PASM code (besides the way the frqa value is managed) is that the spin code used ctra for the duty signal, and ctrb for the 38khz signal, where the PASM code uses ctra for the 38khz signal, and ctrb for the duty signal.
align mov ctrb, G_cntr 'set ctrb for duty signal mov frqb, #0 mov phsb, #0 mov temp, #1 shl temp, G_PIN muxnz dira, temp mov :duty, top mov :minLduty, top mov :minRduty, top :loop sub :duty, :dinc 'dinc :duty mov frqb, :duty 'config ctrb for new duty call #sampleCALL 'scan for block cmp left, #0 wz 'check left if_z mov :minLduty, :duty 'if detected, store current :duty cmp right, #0 wz 'check right if_z mov :minRduty, :duty 'if detected, store current :duty cmp :dinc, :duty wc 'check :duty if_nc jmp #:loop 'if :dinc < :duty, loop 'report wrlong :minLduty, left_addr wrlong :minRduty, right_addr jmp #cmd_done :duty long 0 :minLduty long 0 :minRduty long 0 :dinc long 100002_BlockSensor_PASM.spin(I'm pretty sure I've verified everything outside of "align" is working; there are no hangups or anything, just no lights)
I'll probably spend some time with my oscilloscope tomorrow.
I don't see any code to set the z flag.
Wouldn't be easier to just use the following?
In the Spin example, there were two pins set as outputs. Are you sure you're setting the needed pins to output?
Well, first, I assumed (correctly I think) the Z flag initializes to 0, and operated off that assumption. I'm fairly confident the pins are properly configured given the lights come on if I comment out the instruction that sets the duty counter. I've also used this method successfully before.
That being said, I decided to switch all my mux's to or's and andn's anyways. Having the flag in there is an unnecessary complication. Not only is this my first robot. This is my first micro-controller. I have some programmer friends who help me out from time to time; but for the most part I've just been making it up as I go along.
In addition to getting rid of my mux commands, I also switched the counter modules around to match the spin code (to no avail; I'm pretty sure both counters are identical, and it shouldn't matter which is the duty mode counter), and then I took a look at things on my oscilloscope.
(I also tried adding the 128th second delay after setting the duty signal that's in the spin code I somehow missed earlier, and presuming I did it right, no desirable change (it is slower now))
I was surprised. According to my oscilloscope, with the duty mode counter activated in either the non-functional pasm code, or the spin code, the peak voltage was ~4.3v (probe on the left LED(P9) anode). In the spin code, the voltage sort of swept down to ~3v, then just dropped to zero (the lights appear to dim correctly, but I could never get the distance output to be less than ~170/256). I could probably smooth out the sweep with capacitors. But I am very confused to see more than 3.3v coming out of the propeller. My understanding was that by using the counter to control what percentage of the time P6 is an output (all in one cog; I realize different cogs can have the same pin configured as an input and an output), I was effectively controlling what percentage of the time P9 and P7 had a ground to go to (and that outa[6]==0 so no output (I could add a diode to P6 just to make sure it's never an output)). I'm flummoxed. Why doesn't it sweep all the way down? Even if P6 is outputting, wouldn't it have no where to go and therefore 0v? First it would have to go the wrong way through my IR LEDs, and they still work so I don't think that's happening. Then it would have to go into p9 and p7 which are outputs, and outputting. Then besides all that, wouldn't my oscilloscope register one of the two signals as a negative voltage, not just add them together? I'm thoroughly confused.
02_BlockSensor_PASM.spin
Later, I'll see if I have an appropriate diode to protect the LEDs from the prop chip (if I have two appropriate diodes, I may put one on each LED so they're protected from each other as well). That should circumvent any misunderstanding I may have about how the pins are being manged. It could be that duty mode on the counter (%00110) controls outa[APIN], and not dira[APIN]. It does make some sense that instead of each cog verifying both outa and dira are high in that cog, one cog could set dira high, and another could set outa high. Maybe that makes more sense. But that would not explain a voltage level > 3.3v to me.
Time for lunch.
I spent some more time with my oscilloscope this morning. Before I bothered looking at adding to the circuit, I decided I should make sure there is nothing more to learn from what I have. I decided to get rid of the second LED, and hook things up just like the PE labs example. Then I ran the pekittest code I linked earlier with the second LED stuff commented out.
The receiver is on channel two, which is disabled above. The distance output is telling, as you move your hand closer, it the prop (usually) sees it getting closer until around 170/256, any closer and it still detects it, but indicates it's farther away than it is. (hard to see in a picture, but the LED appears bright, then dims out)
Just to see it, I ran the basic detection routine from my pasm code.
Notice, without the duty mode counter enabled (still grounded at P6) the oscilloscope only sees a little more than a volt at the LED.
With the duty mode counter enabled:
No light, no detection, plenty of volts.
Out of curiosity, I decided to run the pekittest again, and this time take a look at it with my multimeter. It saw a peak voltage of 1.6 volts, and a minimum voltage of 0.6 volts.
Clearly my high school education is not cutting it here. Does anybody have any reading they'd recommend for some general electrical background? Am I using my oscilloscope incorrectly? I have both my probes grounded to the big "ground pin" in the corner of my development board. The readings are the same with only one and either probe; both of which are set to 1X "impedance" (I think that's what that is).
PS: I think the duty mode must modify outa, not dira. So it doesn't toggle from input to output; it just toggles the output on and off, and all pins are always inputs except while they are high and will complete a circuit despite having been set as an output. I wouldn't be terribly surprised if I was wrong; but that's my current thinking.
I was looking over the PEkitLabs example for IR distance detection, and noticed I had miss read the resistor value. I had a 10k ohm resistor between the prop and LED (the object detection lab uses a 10K ohm resistor), and it should be a 100 ohm resistor. I switched in the right resistor, and now the minimum distance reading I get from the example code is 148/256; as apposed to the ~170/256 I was getting earlier. I experimented with this exact code and setup shortly after I first got the propeller, and I'm pretty sure it worked all the way down to single digits. Maybe I have damaged the LEDs; so they don't work as well at low voltages. Maybe.
PEKitLabs-v1.2.pdf (duty mode is detailed on page 135, and the IR distance lab starts on page 156)
I also found this AN001-P8X32ACounters-v2.0_2.pdf which details the counters.
I looked through the propeller manual for counter details too. However, nowhere did it clearly state whether the APIN is being toggled on off by modifying outa or dira. I'm pretty confident it modifies outa, but it would be nice to have a definitive answer on that (I suppose I could write some code to figure it out, but that seems like something worth noting somewhere).
I discovered yesterday that if I switch the duty signal from the p6 "the ground pin" and connect the APIN to an LED, the LED lights and dims. So clearly it generates an output voltage. So I don't understand how the PEkitlab works.
To test my next assumption, I hooked up pin 25 to an LED and had it turn on. Then I added pin 24 as an input, and tried grounding the LED to it. No light. But the oscilloscope sees the voltage jump from a little over a volt to a little over 4 when I try to ground the LED with a prop pin.
{ p25 ────┐ p24 ────────┘ } pub main dira[25]~~ 'p25 set to output outa[25]~~ 'p25 set high dira[24]~ 'p24 set to input repeat 'repeat forever nextNow I'm really lost. I'm not sure if I'm missing something about how the pins work. Or if I just need to spend some time reading about electricity. I definitely don't understand the readings I'm getting on the oscilloscope. Or what the multimeter is telling me.
I could just bail on trying to understand how this works, and add a second pin to the circuit for the second LED. Then I could run them both like the other doesn't exist. Or I could try experimenting with adding some diodes to the circuit just to see what happens. I should probably look for some good background reading on electricity and circuits and stuff.
I was feeling the need to educate myself a little, and stumbled across this site: http://www.ibiblio.org/kuphaldt/electricCircuits/
which has 6 free textbooks, and decided I would read the first one.
As far as textbooks go, it was great.
For the exercise, I decided I would make myself some sort of note sheet, and ended up just writing stuff down
in a .spin file so I could use the circuit "characters" instead of having to draw circuits somehow.
ElectricityNotes_DC.spin
I'm sure it's full of spelling errors, but I thought I would share anyways.
While an enlightening and worthwhile project, I'm still totally lost on my block sensor.
Rather than dive back into my original code, I decided I would try to write some bare bones PASM just to demo the main theory of operation. Unfortunately, It's not quite working either.
{{ BLOCK SENSOR Notes PELab circuit LED CTRB ─────┐ 100Ω │ CTRA ─────────┘ Theory of Operation: Config CTRB to generate 38KHz signal Config CTRA to generate sweeping duty signal When CTRB is high, and CTRA is high, there is no current through the LED When CTRB is high, and CTRA is low, there is current through the LED and it should light. When CTRB is low, and CTRA is low, there is no current anywhere When CTRB is low, and CTRA is high, there will be voltage potential through the led backwards, but only a small amount of current (irrelevant) and no light. -------------------------------------------------------------------------------------------------------- Block sensor circuit 100Ω LEDs Left ─────┐ Right ─────┤ CTRA ─────────┘ Theory of Operation: CTRB to generate 38KHz signal, alternating pins: Left for 2ms -> rest period -> Right for 2ms CTRA to generate duty signal, starting at 99.9% and stepping down after each Left, Right CTRA pin cycle }} CON _clkmode = xtal1 + pll16x ' System clock → 80 MHz _xinfreq = 5_000_000 PUB main cognew(@start, 0) DAT org 0 start mov temp, #1 shl temp, #9 or dira, temp 'set p9 to output shr temp, #2 or dira, temp 'set p7 to output 'config duty signal shr temp, #1 'set temp to P6 pin mask mov frqa, #0 'clear frqa mov phsa, #0 'clear phsa mov ctra, G_cntr 'config CTRA for duty signal or dira, temp 'set p6 to output 'LEDs mov frqb, FReQB 'load frqb reset mov duty, top 'set/reset duty signal loop sub duty, dinc 'dinc duty signal cmp duty, #0 wz 'is duty signal 0% if_z jmp #reset 'if Z, reset duty signal mov frqa, duty 'set duty cycle mov ctrb, Left 'left LED on 'jmp #loop '<- works up to here mov time, cnt add time, delay waitcnt time, delay '<-wtf? jmp #loop '<- doesn't work { mov ctrb, #0 'off waitcnt time, delay mov ctrb, Right 'right LED on waitcnt time, delay mov ctrb, #0 'off waitcnt time, delay jmp #loop } Left long ((%00100 << 26) | 9) Right long ((%00100 << 26) | 7) G_cntr long ((%00110 << 26) | 6) top long 4294967000 FReQB long 2040109 dinc long 1000 delay long 16000 temp res 1 time res 1 duty res 1It just hangs up on the first waitcnt. So to experiment, I wrote this[below] code. But to my surprise, it works as expected.
CON _clkmode = xtal1 + pll16x ' System clock → 80 MHz _xinfreq = 5_000_000 PUB main cognew(@start, 0) DAT org 0 start mov temp, #1 shl temp, #9 or dira, temp 'set p9 to output shr temp, #2 or dira, temp 'set p7 to output or outa, temp 'right light on or outa, left_pin loop xor outa, temp mov time, cnt add time, delay waitcnt time, delay xor outa, left_pin jmp #loop left_pin long |< 9 Left long ((%00100 << 26) | 9) Right long ((%00100 << 26) | 7) G_cntr long ((%00110 << 26) | 6) top long 4294967000 FReQB long 2040109 dinc long 1000 delay long 80000000 temp res 1 time res 1 duty res 1What gives?
If I run the code up to where it says "<- works up to here" I get one dimming light. So I'm fairly confident the circuit is okay as is.
Also, I'm a little confused about the "dira" register. Why is there a "dira" register? It seems like you could get away with just "ina" and "outa" registers.
If you set outa[pin]:=1, pin==output and ina[pin] always == pin state (isn't that how "ina" works anyways?)
Blarg.
This code, does not work as intended (LEDs alternate, but duty cycle never changes [stuck at 99.9%]):
CON _clkmode = xtal1 + pll16x ' System clock → 80 MHz _xinfreq = 5_000_000 PUB main cognew(@start, 0) DAT org 0 start mov temp, #1 shl temp, #9 or dira, temp 'set p9 to output shr temp, #2 or dira, temp 'set p7 to output 'config duty signal shr temp, #1 'set temp to P6 pin mask mov frqa, #0 'clear frqa mov phsa, #0 'clear phsa mov ctra, G_cntr 'config CTRA for duty signal or dira, temp 'set p6 to output 'LEDs mov frqb, FReQB 'load frqb reset mov duty, top 'set/reset duty signal loop sub duty, dinc 'dinc duty signal cmp duty, #0 wz 'is duty signal 0% if_z jmp #reset 'if Z, reset duty signal mov frqa, duty 'set duty cycle mov ctrb, Left 'left LED on mov time, cnt 'set up time delay add time, delay ' " " waitcnt time, delay 'delay mov ctrb, #0 'off waitcnt time, delay 'delay mov ctrb, Right 'right LED on waitcnt time, delay 'delay mov ctrb, #0 'off waitcnt time, delay 'delay jmp #loop 'loop Left long ((%00100 << 26) | 9) Right long ((%00100 << 26) | 7) G_cntr long ((%00110 << 26) | 6) top long 4294967000 FReQB long 2040109 dinc long 1000 delay long 80000000 temp res 1 time res 1 duty res 1However, If I comment out all the waitcnt commands, my sweeping duty signal comes back.
Wow, as I was writing this, it occurred to me to try shrinking my delay periods down closer to where I expect them to be in the final code, which is around 2ms (vs the 1s in the test code), and it appears to be working. If only I knew why.
update:
I know why. I still had the waitcnts commented out :nerd:.
So never mind basically.
With waitcnts, I have control of LED timing, but no sweeping duty signal. With no waitcnts, I get a sweeping duty signal, but I "lose control" of the LEDs.