« Last post by apexstag on April 05, 2016, 09:22:05 AM »
hey I am helping my kid design a small tech project for school, and he is making something to show how robots can do repeatable tasks really easily and don't suffer from boredom or breaks as humans do.
He wanted to show this with something similar to this - sad I know using this to play a game but this is the principle we want to get across. can anyone tell me what that unit might be called/where I could buy one from? I don't want to spend shed loads on full robotic arm! we are going to build it up with lego into a person https://www.youtube.com/watch?v=Pxn9p_Yqg2U
« Last post by FIFO on April 04, 2016, 06:49:31 PM »
I have finally identified and fixed the problem. Both the manual and automatic programmers put the 8085 into reset when they are being used to write to the 8155s. When 8085 processor is in reset, it tri-states the data/address bus, and the control lines, including the read (active low) line. I assumed (incorrectly) that the 8155 peripheral chips would see the tri-stated read line as a high, and so I did not bother to have the programmer tie the the line high when it was being used to write to the 8155s. Since the tri-stated read line was actually seen by the 8155 as a low, the 8155 pushed its stored data onto the bus, while at the same time, the programmer was pushing the data it wanted to write to the 8155 onto the bus. This bus contention made it impossible to write to the 8155s, and thus program the robot.
After I figured this out, I tied the read line high when using the manual programmer, and loaded a short program into the robots memory, to make it stand still. It was successful so I tried to load the same program with the automatic programer, and that also worked. Next I attempted to program the robot using the refurbished 8155s that I though were broken, and they worked. At that point I was feeling pretty stupid, but I was glad that it was finally working.
I have been experimenting with more complicated programs to test the various circuits on the main board, and so far things have been relatively successful. I was having some issues with the 8085 resetting every so often, especially when main drive motor started, but after adding some decoupling and bulk capacitors, the problems disappeared.
« Last post by ServoCity on April 04, 2016, 09:11:00 AM »
https://www.servocity.com/ATTENTION SALE CUSTOMER
S: If your order is over $50, our free shipping offer will automatically be applied to your order (not valid for expedited or international orders). Expedited and international orders will automatically have $6.99 deducted from the shipping total.
« Last post by makspll on March 30, 2016, 08:46:25 AM »
I'm participating in the Rampaging chariots event in June. basically they give you a kit, and you have to build a robot, which is then supposed to either participate in robot sumo, tug of war and then in football and an obstacle course race.
here is the construction manual with all the specs: http://www.rampagingchariots.org.uk/construction/rampaging-chariot-manual-2015.pdf
and the rules: http://www.rampagingchariots.org.uk/games/rampaging-chariots-robotic-games-rules-2015.pdf
could someone guide me on what power transmission should we use to get the torque needed to push a 12 kg robot that is pushing aswell, out of the ring.
we also wanted to transmitt the power onto all wheels (4x4 drive)
we also want to add a scoop, front wedge to lift enemy vehicles easilly at sumo.
also maybe adding tank tracks would be useful
could someone guide us ?
« Last post by bdeuell on March 29, 2016, 08:11:03 PM »
note the best way to cool this chip is through through the thermal pad on the bottom of the chip, but without making a new board the heatsink on the top is better than nothing, if you still have overheating a small fan can make a big difference.
if you are supplying the board with only a 1.33A wall wart but trying to draw 2A there is a chance you are undervolting the system. basically as you try and draw more than 1.33A the voltage will start to drop. the datasheet lists 8v min for the load supply voltage. i would recommend using a power supply capable of delivering the desired current and adding a fuse if you are concerned about something drawing too much current.
looking at your motor pinout i think you might need to flip the blue and red wires. the motor datasheet i pulled off sparkfun shows:
i do not see the yellow and white wires listed on the datasheet but it is likely these are center taps to the windings so that the motor can be used as a unipolar stepper, this could be confirmed with a multimeter.
I have also heard connecting or disconnecting the motor while under power can fry these chips so that may have been the fatal blow to your chip. Im not sure of the exact reason why this can destroy the chip but a motor is also an inductor so if it is disconnected under power the energy needs to go somewhere this can create very high voltages. also there is current feedback through a sense resistor and connecting/disconnecting the motor may cause issues for the current regulation.
« Last post by FIFO on March 29, 2016, 05:23:20 PM »
I have been doing some debugging of the programer, and have discovered something very interesting.
At first I thought that the manual programmer might not have been functioning properly because the supply voltage was too low. I thought this might have been a problem because the programmer is powered by the robot through some relatively long wires, and I thought that the voltage drop might have been enough to drop the supply rail below the tolerance of the ICs in the programmer. I then measured the supply rail at the programer, and while it was low, it was not below the minimum required by the components.
Even though the supply voltage was in tolerance, because the supply was a little low, I wondered if I increasing the voltage might solve the problem. To test to see if this would work, I removed the main board, (which draws a lot of current and causes the voltage rail to dip a little), and attached the manual programmer. After some testing, it was clear that the programmer was functioning without error. I then measured the supply rail in the programmer, expecting to see a higher voltage, but to my surprise, the rail was only about 30mV higher.
I now strongly suspect that the main board is somehow interfering with the programmer which is why it is acting erratically.
« Last post by FIFO on March 29, 2016, 02:58:16 PM »
If your servos are put under a load that is greater than they can handle, they can be damaged by drawing too much current. To prevent an over current situation from damaging your servo, you could put a fuse inline with it's supply or ground connection, so that if the servo draws too much current, the fuse will blow, preventing damage.
One annoyance of this setup is that the fuse must be replaced if it is blown. To avoid this inconvenience, you could use what is called a PTC fuse, which unlike a normal fuse, resets after power is removed.
Can I use a 12v 5Ah lead-acid battery to power an Arduino and Dynamixel servos? Online I found that they both should be fine going up to 12v, but is there any chance that they will drawn to much current and burn up? Is a fuse all I need to be safe?
« Last post by FIFO on March 27, 2016, 07:02:56 PM »
I have tried also to use the wire wrap direction, and found that the wires acted like
antennas, with the bus speeds. This put out a lot of noise, and loaded down my CPU with a fanout rate.
Yeah, I thought that might be a possibility, but I am not experienced enough to know if it is an issue in my case or not. Just to be sure, I set up a test jig for the 8155 on a breadboard, and tried to write to it slowly using an Arduino board. That proved to be unsuccessful, and after several other attempts, I came to the conclusion that the chips were dead.
I ordered some new ones off of Ebay, and tried to write to those using the same test setup, however I was unsuccessful. At that point I began to doubt whether my test setup was correct, so I installed one of the new 8155s on robot.
Previously, when I still was using the refurbished chips, I had attempted to program the robot using the manual programmer. It turns out that I had wired it incorrectly, and the address/data bus lines were mixed up. Instead of attempting to fix the programmer, I tried to use the automatic programmer which I thought was working. However as is evident from my previous posts, those attempts proved to be futile.
Now that I had installed the new chip on the robot, I attempted to program the robot with the automatic programer, but that was ineffective. At this point I thought that the automatic programer might have a problem, so rather than try to debug its the hardware and code, I fixed the manual programmer and housed it in a tea tin. (Previously I had it in a cardboard box, but it looked really suspicious with wires hanging out, a red 7-segment display, and a bunch of red buttons, so I decided that I should make it a little less threatening.) I then used the manual programmer to program the robot to simply stand still, (if you remember, in its naturally unprogrammed state, the robot rolls backward,) and when I was finished, the robot did not move, indicating the the programming had been successful.
So it appeared that the new chips and the manual programmer worked, but that the automatic programmer did not. The next day I attempted to program the robot again with the manual programmer, but the programmer acted erratically. Since then I have tried to repair it, but have had little success.
Attached to this post are two pictures of the manual programmer. To operate the programmer, the programmer is first plugged into the back of the robot. Then the two toggle switches directly under the display are used to select which chip to write to. Next, the address to which the data is to be written is set up using the two red buttons on the right side of the programmer. Once the correct address is selected, the button on the top left of the programmer is pushed to latch the address. Then the two buttons on the right side are used again, except this time, to set up the data to write to the address that was previously latched. Once the data is set up, the bottom left button is pushed to write that data.
It took me a little while to get back to it, but today I swapped in my spare BigEasy driver and added a heatsink to the chip for good measure (using thermally conductive tape).
and tried things again.
I made a couple of changes; first, I figured that perhaps the very powerful Trinamic stepper was drawing too much current from the board (or produced too much back EMF or something), so I went back to the SparkFun stepper
(Wantai 125 oz/in stepper, supposed to draw a max of 2.0A). I was still powering things with a 24 vdc wall-wart which is spec'd to product 1.33 amps
(I was worried about blowing the board again)
Then I built it into the overall rig and started stepping. What you see below is a frame built from 80/20 with a faceplate of 1/4" MDF which the stepper is bolted to. The stepper shaft is connected to an Actobotics hub, and that's connected to a disk of 1/4" ply with some rings of 1/4" MDF added to it to add mass. I'd say the whole thing weighs about 400g.
The behavior is that it ran actually fairly nicely, with a little stutter, up to about 210 steps/second; I had to gently juice the pot on the board to get it to keep running smoothly. It got to about 210, hung up, and just quit. It seems the board produces no more steps. At first, I thought this was due to a wire coming loose (step B- had come loose). But when I reinserted the wire, still no more steps. The board seems to just be done. I was hoping to make a video to show the shaky rotation, but the thing quit before I got the chance to (I got about 90 seconds from powerup to stopped working).
FWIW, I'm wired (from the stepper)
Black -> A+
Green -> A
Blue -> B+
Red -> B
Yellow and white -> not connected, just kinda hanging there.
Now I'm really confused! Maybe the red wire coming loose blew the chip? Or maybe having so much inertia on the motor is ... (here my grasp of E&M as applied to steppers is failing me a little, but I could imagine some explanation like "the mass keeps spinning causing an induced current in the wire which is backwards from what the driver expects". Or something.)
I have some backup backup stepper drivers coming eventually. But where am I going wrong?
Hope all is well with you!