Hello!
Sorry for posting into the general category with a VEX GO question but I do not have access to the VEX GO category yet.
We are having a very hard time with the VEX GO 2 axis robot arm STEM lab. As it is, I believe the motors are not capable of supporting this build or the exercise. If you have a quick look at the attached video you will see the problem. Because I had to reduce the video quality you can’t really see the program anymore but it is basically a simple move right, enegize the magnet, lift arm, move left, drop arm and de-energise the magnet. As you can see the movement judders massively, completely misses the mark and does not achive anywhere near 90 degrees on any movement.
This is just a simple program with no fine tuning. We did spend quite a bit of time to try and get this to work better with reducing motor speeds etc. but the end result is virtually the same. In no configuration is it possible to carry out a simple task coding the robot arm like the STEM lab suggests. Is there anything we are doing wrong? Do you have any real live video of this STEM lab with an actual GO set where this works like the animation in the lab docs?
And additionally we have a big problem with using the motors in general. The kids call this ‘crazy motor’. Basically randomly when using a motor it will move at high speed (not 100% but much faster) for a short period of time and then continue with the program. Please see the second video for an example of this. This happens frequently and breaks builds and generally scares the kids. We also find that frequently the program gets stuck when a motor movement is carried out. We have tried the motor timeout function but that didn’t seem to help.
Any help would be appreciated.
Regards,
Michael
Hello @Michael_Poelzl ,
Thank you for reaching out with your concerns regarding the VEX GO 2 Axis Code Robot Arm. I understand the challenges you’re facing and would be happy to assist you. In regards to the robot arm performance, it’s possible that the issue might be coming from a combination of the building process, the programming, and the weight load on the motors. Here are a few troubleshooting steps:
-
Check the Assembly: First, I’d recommend double-checking the build instructions to make sure the robot arm has been assembled correctly. It’s essential to ensure all pieces are securely attached and not exerting any unnecessary strain on the motors. Additionally, the problem of the base inaccuracy may be arising from the “plastic on plastic” rubbing of the white beam of the arm, and the beam of the connection point to the tile. Observe this spot in particular, and see if your build has friction when turning the base (plastic pieces may be interfering with each other).
-
Gearing: If the arm is experiencing issues reaching 90 degrees, this could be due to an issue with added gears. I think I can see in the first video the build is very similar to the provided build instructions, but in the second video I can see some gears added onto the arm assembly. Remember that when gears are added, this alternates the rotation that would be experienced by the arm, potentially causing your arm to not move the intended 90 degrees.
-
Power Supply: Make sure your batteries are fully charged. Low power can cause the motors to perform inefficiently.
-
Program Fine-tuning: Although it may seem simple, programming motor movements can be quite delicate. You might need to adjust the duration of the motor movements, the wait times between actions, or the motor power levels. I understand you have already tried this, but it might need some further adjustments.
About the issue of the ‘crazy motor,’ it might be an issue related to the program or the motor itself.
-
Program-related: Make sure there are no loops or commands in your program that could be causing the motor to move unexpectedly.
-
Motor-related: If the issue persists, the motor might be faulty. If you have an extra motor, you could try swapping it out to see if the problem continues.
-
Another issue is that the crazy motor may be caused by a caught wire. Ensure all wires are snugly stored, as when they get snagged it may cause the motor to overreact.
It’s important to be patient with this process. Robotics and programming can sometimes be tricky and might require some fine-tuning. I’d encourage you to turn this into a learning opportunity for the kids - show them how engineers troubleshoot and solve problems.
I’ve attached a video of the same build (VEX GO 2 Axis Code Robot Arm) performing (from what I could see in your video) the exact same code. While it is not perfect (might be from step 1 above), I am not able to reproduce the arm position error you are experiencing. Feel free to attach any additional photos/videos of the build/code so we can better work this out. I hope these tips help, and I wish you the best of luck with your STEM lab!
Hi Mathew,
Thanks for your details reply, it’s much appreciated. Here are my thoughts to your comments:
- Yes this might well be a big factor but most likely an inherent property of how the build was designed… We did have a good look to see if we could remove as much fricton as possible but and made sure nothing was snagging but that didn’t really help very much. A bearing of sorts and some balance would probably help but need a considerable change in the build instructions.
- I didn’t mention this but yes I did another build with added gearing to overcome the problem (this is the build you see in the second video). It has a 3:1 gear ratio and needs a multiplication by 3 on the angle values. This works fairly well and makes the arm more usable. For our scenario though (8 to 10 year olds from normal classes) the added complexity of the build without instructions, motor reversal and a gear ratio was too much. Very interesting points to discuss and implement in a group of older students for sure but not for this demographic.
- This was my first suspect but the battery was fully charged and we also swapped it out to make sure.
- Yes we did a fair amount of fine tuning with speeds, power leves, ‘hold’ on stop etc. but the problem there really is repeatability, which we did not achieve.
Thanks for the video. Your result seems slightly better than what I got but if you look at where the arm ends up at the end of the clip I’m sure you can appreciate how this will be compounded on the second or third movement. I think you would struggle a lot to pick up and put two disk into a different location (not helped by the fact that the discs have a very small metal pin that needs to be attracted by the electro magnet).
In the end I think it is also a matter of expectation. For the prepared STEM labs I envisaged that you can use the provided builds and instructions and without much tinkering execute the lessons (and to be fair I think this is how they are presented). I appreciate that ‘tinkering’ and problem solving is a big part of the process but for 8 to 10 year olds in a normal class environment (not special interest) we often need something that works reasonably well ‘out of the box’ to be able to focus on the task in hand.
For now I am trialling a custom build with custom code blocks to hide the complexity of the extra gearing. One thing that is a problem though is the fact that I cannot create build instruactions for it.
Does VEX have an in house tool to create build instructions? Something like that would help greatly.
All the best,
Michael
@Matthew_Goodwin
The second problem (the crazy motors 
) is definitely the bigger problem and is really hampering our efforts right now.
I did some more in depth trouble shooting and here are the results:
- The problem occurs with a simple program i.e. a simple loop that turns the motor some degrees and then pauses before doing the same again so a coding problem is very unlikely.
- It happens on all motors on our 5 VEX GO sets, across all brain and motor combinations.
- It happens when I use our Android tablets but NOT with a laptop (unfortunately at the school we only have tablets)
- It happens consistently on every 4 to 5 movement (if I remove the pause then even more)
- It always seems to happen at the end of the movement.
- It usually last around 2 where the motor spins at max speed in the opposite direction of the previous movement
I have attached a short video where you can see this more clearly. Looks like a problem in the Android version of the app.
We would really need a solution for this as soon as possible.
Thanks,
Michael
