
PRO
afcorson
Australia
Asked

Arc ver 2021.03.02 is freezing. Need to use previous version. Has anyone else reported problems?
Related Hardware EZ-B v4
Arc ver 2021.03.02 is freezing. Need to use previous version. Has anyone else reported problems?
Here is the error log...
EZB 0: EZB 1: EZB 2: EZB 3: EZB 4: Windows version: Microsoft Windows NT 10.0.19042.0 Screen Resolution: 1536x864 (96x96 dpi) ARC (Teams) Version: 2021.03.02.00 Speech Recognition Culture: en-GB Loaded speech recognition successfully Attempting connection on 192.168.1.1:23 Connected to 192.168.1.1:23 Reports EZB v4 OS With Comm 2 Firmware 'EZ-B v4.x/2 Native Firmware' on 'EZ-Robot EZ-B v4.x/2' supports the following capabilities:
EZ-B v4.x/2 Native Firmware ID: 48-50-0-0-120-255-59-59-59-38-38-38 Setting battery monitor voltage: 6.5 Setting battery protection: True **WARNING: The low battery warning monitor value is set LOWER than the recommended default of 7v. Your voltage monitor set for 6.5v. If using the LiPo batteries, for battery longevity and your safety we highly recommend that you change the low battery monitor back to 7v. This setting can be found in the Connection Control Config Menu. Setting i2c rate: 300000 EZ-B voltage is 7.678518792 EZ-B temperature is 24.81367440630666168C Connected Comm Err: System.IO.IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) --- End of inner exception stack trace --- at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) at EZ_B.EZB.uNCRWAcYFg(Int32 , Byte[] cmdData) BbytesToExpect: 2
Received: 0 0 Disconnected
That error is from disconnected wifi - the "freezing" might be due to a process or script that is repeating and either flooding the data channel or waiting for a data response. I'm leaning toward the power consumption issue on the EZB and it browning out rather than flooding the datachannel.
Check for a good wifi channel that doesn't have any interference. Secondly, if you have the ability, hardwire the ezb to the pc.
Lastly, ensure the EZB isn't "Browning out" due to power supply limitations. Consider if your servos are powered directly off the EZ-B v4 and if they require a better connection than the little ezb traces? How many amps is the robot drawing?
Give this a quick read: https://synthiam.com/Support/troubleshooting/EZB%20Disconnecting
See if your robot checks the boxes for having adequate power.
As an FYI, ARC is primarily tested with a few virtual machines that run through a bunch of unit tests. But, the big test is that ARC is running 4 robots 24/7 connected to Exosphere. They are performing multiple camera tracking, NMS, etc.. And they're live so people use them throughout the day. Generally, you can dismiss ARC core as causing issues. I find it's best to work backward from the robot in this order...
How many amps is the robot drawing?
How many amps is the power supply rated for?
Is the EZB connection over WiFi? Check for the Wi-Fi channel saturation? Use THIS TOOL to check and use a less saturated channel. If possible, consider hard-wiring the EZB to the PC.
Are there any i2c devices connected to the EZB? (i.e. RGB Eyes, Compass, Accelerometer) If so, ensure the wiring and connectors are secure. I2C devices with poor wiring/connections can lock up many microcontrollers
If those items above do not resolve the issue, the next step would be to consider looking at the ARC project.
I think I am getting better at diagnosing my robot problems. First thing I looked at was the LED RGB board which was not lighting up in the usual manner. And sure enough, the wiring was faulty caused by the head be wrenched sideways with too much button pushing by visiting student groups. When the wiring to the RGB board was re-secured, the robot worked perfectly (touch wood). I am so glad this was all it was, otherwise I could have wasted many hours. Thanks for your efforts though.
Great to hear! Were you able to implement the enable/disable buttons in the interface builder?
Not effectively. I use my $ScriptRunning variable to skip to the end of the code if a button is pressed when one is still running. I couldn't work out a way of disabling buttons other than this method.
Here’s a link to your feature request that contains a solution: https://synthiam.com/Community/FeatureRequests/Disabling-button-in-interface-builder-20431