I have 5 Lynxmotion AL5D robots. They are old. They are the style with two power switches one for the AC and another for a 9 volt battery.
We are using Windows 10, and FlowArm PLTW.
The Blue tooth button is on, Found has a green light, I am on baud rate 9600. I seem to have communication but the robot does not start up in it’s erect position. One arm is randomly moving to all extreme motions slamming itself into the table and back up and all over. Another is slamming itself into the table. A couple others I can hear the servos humming but no movement.
@JPierce_Westhill Welcome to the RobotShop Community. We’re here to help. It seems there might be issues with operating that many arms using Bluetooth. Have you tried physically connecting each arm to their respective computer? If so, does it work? Can you try one robotic arm at a time (keeping the others not powered) and see if there is an issue with any of them?
I am not using the Bluetooth. Our directions had us turning it on. The robots are connected separately to their own computer. One of the things I also noticed is that Auto did not connect to a port. The connection was found only if I chose one.
Can you verify that the baud rate on the board is correct? If the “found” light does not turn on, that is problematic in that the software has not established communication via the COM port and detected the SSC-32 (electronics). Which SSC-32 do you have? The original or the SSC-32U? If you’re not sure, confirm they all have the same electronic board and provide a clear photo.
Based on your answer, we’ll also see if power is correct.
Good to know. It should look like this:
The baud rate is set using two jumpers on the board. Can you confirm they are all correct and set to 9600 (one jumper in the correct position and orientation)? Also, as indicated in the FlowArm software manual (step 5), can you ensure the Bluetooth icon is active?
The light confirming the connection would be in the FlowArm PLTW software.
It would be important to also check the VL / VS jumpers; since you are using separate 9V and 6V power supplies, it’s critical that the VL = VS jumper is NOT in place.
Check the see that the 9V batteries are providing the right voltage. They tend not to last very long, and if they have been left connected for a few days, would still have been powering the logic voltage and are likely discharged.
Finally, note that the quality of USB to DB9 adapters is not all the same, and some create issues - check the USB adapters for the arms which are working with those which are not.
All robots have worked in the past. We use them for teaching our PTLW CIM class and I am just getting them out of storage. This is the first time using them on windows 10.
One robot had one of the jumpers knocked out of the baud rate pins. There were also several pins bent over but this all probably happened when that particular robot was going berserk. The elbow smashed on top of those pins a few times before I could turn the power off. Straightened all the pins. All five robots say 9600.
One robot had the jumper between VL/VS. That seemed odd to me but I pulled it. I was not the last teacher to use these but they worked the last time I taught the class.
9volt batteries are fresh. Learned that the hard way many years ago.
USB to DB 9 adapters I also have learned are all different. I am using the ones that worked in the past.
I have restarted all five robots on new attempts. All have the same results. Blue tooth light is on. Set the com for auto green light blinks and they are all running through all coms and not picking any of them. If I click on a com the light goes green on Found then starts blinking. No robot movement.
Another possibility is that the connections between the servos and the SSC-32 are not correctly wired. We need to proceed one arm at a time.
Can you provide some clear photos of the SSC-32 of each arm so we can see all of the connections? If you can, label each arm A, B, C… and label each photo so we can differentiate between each.
Verify the wires existing each servo (yellow, red and black) that each time they connect to a servo extension cable that they meet yellow to yellow, red to red, black to black. Page 43 of the PLTW manual.
Ugh! I was hoping for a simpler solution. Had a feeling I would be doing this anyway. End of a marking period coming up so I have a lot of multitasking ahead of me so it will be awhile before I get all this done. Will be in touch one way or another as soon as I get to all this.
If you can quickly take a few clear photos of the setup (especially the electronics) we’ll try to spot what we can in case there’s anything wrong with the physical setup.
As you said, if they were working before, but you were not the last to use them, something must have changed.
The SSC-32 Servo Sequencer was huge! I didn’t know about it before that was instrumental in my troubleshooting! I have three working the others I’ll have to fine tooth comb to find their problems. May have to pull the Multimeter out for that too.
Three robots worked immediately off the SSC-32 Servo Sequencer. My robots apparently work by having the Bluetooth off, and the baud rate on 115200. So in flow arm I need to turn off the Bluetooth, and set the baud rate at 115200. The Auto find works well to identify the working port.
Since I have worked with Arduino’s the SSC-32U makes sense to have the baud rate at 9600. I only have LynxMotion experience with the SSC-32 so I need to do some learning to catch up with that. Documentation you linked should be good.
My class will be all set with the three working bots. I’ll give updates on the others as soon as I know more.
You indicate experience with Arduino, and the only difference between the AL5D you have and more recent ones is really the SSC-32, so some possibilities:
No more need for the USB to Serial adapter or the 9V battery.
Program the arms using Arduino, with all pins broken out.
The commands sent to the SSC-32U are the same as for the SSC-32, and are really easy to understand. If you want to use something Arduino-compatible like the BotBoarduino, consider experimenting with the Servo Library.
I seem to have most of the robots working now. However when we try to turn on the inputs externally the information does not make it to Flowarm software. I have measured the voltage on each A B C and D input and a switch does change the external pin from 5V to 0V. On the flow arm software you can click the A, B, C and D inputs and the robot and the software work properly. An external switch is not making the flow arm software execute the program.
Can you verify that you have the sequence associated with an input?
The button to select the input is the H in the image below (there’s a list of potential “triggers”:
So how do I get the A, B, C, and D ports on the board to talk to the software. Used to work. If I hold B and C down for an extended period of time they will pause the bot but then they lock on and do not turn off so you can push the switch again and continue the sequence. A and D do not work at all.
OK, I am not a very good writer so I’'ll try again. Please see my reply 5 posts up from your last reply.
A,B, C, and D work like they are supposed to when clicking on those options in Flow Arm. The external switches are registering 5volts and 0volts when pushing the switches. However that external signal of the A,B,C and D inputs on the circuit board is not making it to the flow arm software. Somewhere between the switches and the software the signal is getting lost. Is the Flow Arm code written for 9600 baud and my Lynxmotion arms work on 115000? Or on the random occasion when Flow arm does read the signal, it is random and sometimes locks the signal on in the case of B, and C.
So to confirm, the inputs via FlowArm work, and the inputs E,F,G,H work on the SSC-32U, but not those connected to A and D, and B and C are intermittent? It’s unlikely to be a baud issue if you can communicate with the board. As you said, quite weird given that they worked in the past, and the hardware and software have not changed.
Just some general ideas / speculation here:
You indicate you have buttons connected to A,B,C,D, so press the button quickly (no long presses). It might be an issue of timing between when the software queries the eight inputs and when the button is actually pressed. The software might read the button is pressed, and re-scan quickly enough to read that it is still pressed, thus “cancelling” the first.
Ensure that the sequences work as you would expect via the interface and are associated with the correct inputs.
Can you show the button setup and connections to the SSC-32U board, and to the sensors themselves? We’ll see if we can spot anything.
