Problems with Consistent Connectivity when using Classroom Set

We have loved using VEX GO! Until recently, I was just using the building activities with my 2nd – 3rd grade classes. Recently, we have moved into the coding with the VEX GO app on our Chromebooks.

I have updated all the brains and all the batteries are fully charged. We are having an issue with 2-3 robots not working with the VEX GO program consistently. Students go through the process to connect their robot to their Chromebook via the VEX GO app, but the program they write does not communicate with the actual robot. The program gets “stuck” on the “When Started” block and won’t move through the progression.

I’ve double checked to make sure the block based program is assembled correctly and made sure the student was connected to the correct robot. I’ve even disconnected and powered down the robot and reconnected it. It still gets stuck on “When Started”. Interestingly, when I go to reconnect the robot, it is listed as “paired” in the connection list, even after disconnecting and powering down. The green light remains solid, even though the list says “paired”. I can even click on the “robot name- paired” and it will go through the connection process again. The Chromebook will say that it’s paired to the robot, but will still not run the program.

Am I missing something? It’s happens to 2-3 every class period.

Hi @Amy, I’ve shared your message with the software team and they are looking into it.
In the meantime, I have a question to help troubleshoot.

*Are the Chromebooks in fairly close to the robots? The VEX GO Brain must be in Bluetooth range (within approximately 30 feet) of the device you are attempting to connect. If the GO Brain is out of range, bring it back into range of the Chromebook.

  • Do you know the age of the Chromebooks?

  • Are you using Web-Based VEXcode GO?

In the meantime, I recommend reporting your issue via the feedback button on the computers that are having an issue. This will alert the software team to what is happening, while also providing information about the computer and operating system on which it is being used- which can help them troubleshoot further. Here is a link to the Using the Share and Feedback Buttons in VEXcode GO article in the STEM Library, which walks you through using this feature (here is a screenshot from the article for quick reference.)

@Amy_Anderson - here are some additional troubleshooting steps suggested by the software team:

*Restart the Chromebooks that are having issues, to see if this fixes it.

  • Try connecting other robot Brains to the Chromebooks that are having this issue.

  • If other Brains can’t connect to the Chromebook, then it may be an issue with the computer.

  • Inversely, if the issue seems to be more with the robot Brain, try connecting the Brain to a different Chromebook to see if the issue remains. If it does, then force updating the Brain with the GO Classroom App.

Let us know if this helps. If not, can you give us the Chromebook models that aren’t working?This could help us debug as well, if it turns out to be a Chromebook hardware issue.

Age of Chromebooks should be about 2-3 years. This issue happened to my 2nd and 3rd grade students today and they are all issued their new Chromebooks in Kindergarten(they get new ones again each year in 4th grade)


. I have attached a picture of the back of the Chromebook.

We are using the Chromebook APP version of VEX Go.

We restarted the Chromebook.

Students are within 1-2 feet of the robot while using.

All brains were updated first thing this morning. I even force updated when we had issues to make sure. No change.

In fact, one robot was connected, but didn’t even follow the commands correctly. The student had…
When Started…
->drive forward 340 mm
->turn left 90 degrees
->drive forward 340 mm

What the robot actually did was drive forward about 500 mm, drive reverse 500 mm, then turned left 90 degrees! At each step, the blocks lit up, but it did a completely different action on the robot. All cords were plugged in securely and the batteries were fully charged.

I’m just at a loss as to what to do. It’s not even the same brain each time it happens. Yesterday, it was brains 1 and 5. Today it was brains 4 and 9.

We were very frustrated.

Hi Amy,
I’m going to share this info with the Software team. I’ll let you know what I hear from them, if someone from the team doesn’t respond themselves. I’m sorry you are having this issue.
Olivia

Hey @Amy_Anderson I’m Tyler, I’m one of the developers for VEXcode GO. Just wanted to touch base and see if I can help directly.

First thing I wanted to mention is there was a firmware update pushed last night. We had some other teachers finding connection issues so we pushed a firmware update out to address that. This might help, so it’s worth a try to update and try again.

I did want to clarify one thing because it is a quirk with the Chrome browser and ChromeOS that can be confusing. The “Paired” next to the device in the device list means that the device had been previously paired to the Chromebook before, not that it is currently paired.

This is supposed to help identify devices you’ve used before, but it is just a weird phrasing. We don’t have control over the wording on the device list, but we can add that bit of information to our documentation since it can get a little confusing in cases like this.

A question I had was, is it possible that multiple Chromebooks are connected to the GOs that are having issues? You mentioned that you made sure that the correct GO was connected to the Chromebook, I wasn’t sure if that included making sure other Chromebooks weren’t connected to it. The behavior can get kind of weird when multiple devices are connected. Especially if both devices start running a project.

If you need anymore help or have any other questions I’ll be keeping an eye on this thread!

Hi Tyler,

Thanks for the response. We are currently on Christmas break so I’ll update in January and let you know :wink:

As far as any other students being connected to the same VexGo, I don’t believe so because 8/10 were working just fine with their individual robots. For the 1-2 I had to troubleshoot during classes, I made sure they were connected correctly and they still were quirky.

Hopefully the update will fix the connection issues. Thank you for your help!

1 Like

Hi Tyler! We are back in person and used the physical robots for the first time again today. I freshly updated all of them and all Chromebooks were up to date. We had two that just kept getting stuck on the “When Started” block and wouldn’t move through the program. For one, we troubleshooted by turning on and off the bluetooth and it began to work. Only thing is, it took about 10 seconds for the program to actually start working on the robot. For the other, the robot would completely skip the first block (move forward 200 mm) and move to the 2nd block (turn right 90 degrees). Any clues as to how to further troubleshoot?

Hey Amy, glad to hear back!

If you haven’t already, you can submit feedback from the chrombooks that the issue is happening on. Make sure that the “Include diagnostic and usage data” is checked so we can get the project and some other data about the app. In the feedback mention this issue and I’ll keep an eye out for it.

Another troubleshooting step you could try is between periods with no other GO brains on, see if you can reproduce the issue with the brains it was happening with. This could tell us if it some sort of interference with a bunch of brains communicating with other devices at the same time.

If you have an iPad, you could try using VEXcode GO on that to see if it is the connection with the Chromebooks is the issue or if it is the GO brians themselves that is having issues.

Hi Tyler. I’m back after 2 weeks out and I think I may have discovered something. I know the directions mention that movement of the robot may occur during an initial calibration period when turning on and connecting the robot. Because I also teach using VEX IQ, I know that we refrain from moving/disturbing the robot during calibration of the gyro sensor. Because I am using these GO bots with 2nd and 3rd grade, sometimes there are pairs of students who may moved the robot immediately after connecting/ I’ve been instructing them to leave the robot still when connecting.

However…

I’m still having some issues with 1-2 robots (not always the same bot) per class period that still don’t respond correctly. Our latest lesson was on learning how to drive the CodeBase Bot using the different drive modes. 1-2 bots weren’t responding to these modes correctly. For example, in Tank mode, even when I had both joysticks in the full “up” position, the left wheel was spinning considerably faster than the right, so the robot would never drive forward. For one robot, when I moved the joysticks up and down, the robot still only went forward, never backward.

So…

I ended up toggling between tank and right arcade and back to tank. Each time you change driver mode, the screen says to “Wait. Reconfiguring robot.” After I did this, it started working correctly! It’s almost as if it needed to be recalibrated. The problem is, WHY would it need to be recalibrated if students did not disturb the robot when powering it on and when connecting to their Chromebook.

I really want these to work well and to be consistent - just kind of disappointed and frustrated at the moment. Any ideas? Is there something else I’m missing?

FYI - I did send in a few reports last week via the app feedback button.

1 Like

Hey Amy! Great to hear back from you. I saw your feedbacks and I am looking at the projects and the other data we got back. Regarding your previous issues with commands being skipped, we’ll look in to this with the firmware developers and check this out. We have been able to get it to happen one some of our Chromebooks.

Regarding the configuration, the GO configuration process is different than the IQ calibration process, though not touching the GO robot during the configuration process would be a good idea.

During the calibration for IQ it is calibrating the Gyro so that it can get more accurate readings from the sensor. For GO, when you connect it is sending the robot configuration so that it knows what motors and sensors are where and the movement is essentially the robot figuring that out.

The robot configuration is sent to the GO brain in a few other situations as well:

  1. When you hit “Done” in the Robot config with a robot connected
  2. When switching to the Drive tab
  3. When switching devices and drive modes in the Drive tab

The third case is what you are seeing when you select between the Left Joystick and Tank Drive modes in the controller screen. Because the robot needs to know that it should be in Tank mode and not Joystick mode, we need to send a new configuration.

What could have been happening when you were seeing the weird behavior was it might not have configured itself properly the first time, which is why switching between modes fixed it since it essentially reconfigured itself. That is another thing we can look in to on our end. It could be possible a partial config was sent and the motors weren’t configured properly.

My suggestion would be exactly what you ended up doing, just switching drive modes and see if it fixes the issue. I would also say not to touch the robot when switching drive modes as well to rule out the wheels spinning during that configuration process causing the issue.

But we’ll be looking in to these issues and all of this has been a lot of help!