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
1 Like
@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
@Michael_Poelzl I apologize for my delay, and for the inconveniences you are experiencing but I am glad to hear you are designing your own rendition of the Arm. Recently, VEX is beginning to transition to use Cadasio, which provides users with 3D build instructions created from CAD files. You can login and create (I think it’s) three free projects from CAD files, each project would be a complete 3D Build Instruction of whatever CAD file you import! I’m intrigued to see what you are coming up with, so please attach images/videos!
Additionally it seems the “crazy motor” issue you are experiencing is a bug, and our software team is now investigating it. We will keep you updated, so thanks for pointing it out and providing all your research into it.
1 Like
Thanks for informing us about this issue. We were able to reproduce the issue. While investigating we did find that the issue is not exclusive android, but it seems to impact some devices more than others.
We found that the GO brain was having issues when it was getting too many messages from the connected device. We were able to fix the issue and are currently working on testing to make sure that it is fully fixed and that the fix does not introduce any other bugs.
The fix was made to the VEX GO Brain firmware. This means that to get the fix, all your GO Brains will need to get updated. Thankfully, once we push out the update, VEXcode will automatically update any brain that connects and is out of date. You just need to make sure that your Android tablets are connected to the internet so that VEXcode can detect the update.
I will post again when we push out the update so that you know to expect it.
Hi Jacob,
Thanks for getting back to me and the speedy resolution, it is much appreciated!
Not sure if this might be related but one other thing we noticed was that via the Android app the turns needed significantly different degree values vs controlling via the Laptop.
For example on all our sets we need to program an 80 degree turn to achieve a 90 degree turn and similarly we need to enter around 320 degrees in the turn block to achieve a 360 degree turn.
Kind Regards,
Michael
Thanks for reporting this. We will take a look and get back to you. However, if it is working correctly with your laptop but not the Android tablets, it may take some time to identify the cause.
I would like to get some additional information about this to try to speed up the investigation.
- Does this happen for all of your GO robots?
- Is it the same proportional amount for all of the robots? In your example it was targeting 8 results in 9. So targeting 40 gets 45, 120 → 135 etc.
- Can you submit a feedback from the android tablets after you see this issue? Please make sure that the diagnostic data is included. This will let me see what VEXcode is telling the robot to do.
- can you provide a simple example project that reproduces this issue?
Thanks for the demo. Now that I know that the turning issue is with the drivetrain we will investigate and get back to you.
I just wanted to update you on this.
We are still investigating the issue with the drivetrain turns. We would like to make sure that both issues are resolved with a single update, so we have not yet pushed out the motor fix.
I will let you know if anything changes or when we push out the update.
Hi Jacob,
I was wondering if there has been any progress on this?
I have just finished a robotics camp and the ‘crazy motors’ issue is really something that makes the Go kits almost unusable for us. I have another camp coming up in August would really need a fix for this.
The second issue I mentioned (Codebase turning too far when turning) is not much of a problem because it is easy to adjust the values to work around it and we wouldn’t need a fix for this so urgently.
Thank you and kind regards,
Michael
1 Like
We are planning to have a back to school update for the firmware and VEXcode in August. Unfortunately, the exact date has yet to be set. I will post when it has been pushed out.
1 Like
Just wanted to let you know that we pushed out the VEX GO firmware update. This should fix the issue with the motors. Next time you connect to your VEX GO Brains, you will be prompted to update them. Once that is done, you should no longer have that motor issue.
Unfortunately, we have been unable to find a fix for the drivetrain turning issue. we will continue to investigate it and let you know when we have fixed it.
1 Like
Thank you for the update! I have tested it on one of the units and the problem seems to be solved 
!
2 Likes
