elfege
Hi,
Something is terribly annoying : ARC resets its default camera so if you are using a different camera than the ezb camera, any script that is supposed to boot your cam and then start it in the camera settings will not activate the one you want.
Is there a way to select a camera in the list as default and lock it so it stops bugging me like trying to force me to buy the low res ezb camera ?
thank you.
PS : ezb v4 is full of bugs. I can't count how many I meet. It is VERY unstable. Please, provide us with a firmware at some point. It is really very annoying. few examples :
-ezb disconnects -ezb has flawed digital ports : servos and motors won't respond ezb needs to be disconnected then connected again -ezb v4 used in conjunction with ezb V3 will screw all servos mixing up the old 100 position values and the new 180 positions. ARC has a very slow response rate - often due to a wifi board that is too slow, apparently, or a flawed buffer in the software, Idk. -digital ports will all lock to ON position and turn the robot totally nut and crazy -ARC will crash, very often, as soon as more than 3 scripts run at once. -i2C port is far too unstable. and so on... can't remember all the bugs I've encountered but it is really a lot.
To get it working I need to restart ezb and beside that I don't specify any new setting beside the usual Res that I've been using for months with this same Foscam. If by chancebincan get the camera control to stop running then I need a refresh and it works again. This either with alas.info filter or with URL directly.
I'll see what I can do on the hardware side when I'm back home.
Thanks.
Here's some insight to explain the issue, it's incredibly clear in the error which you shared.
The driver is not returning successfully and the name of the camera cannot be parsed yet. What is happening is one of two things...
Another program is attempting to use the camera device
The camera device driver is not fully loaded yet. Meaning, the USB cable was plugged in, but the driver hasn't completed loading. Most likely not providing enough time between connecting the cable and loading the camera control
The usb port or cable is damaged and the camera is not making a reliable connection
The camera driver is not 100% compatible with your OS version
The camera hardware is buggy
The camera device driver is buggy
Which ever the reason - there is little that ez-robot can do if the Windows Operating System is not providing the driver information.
In your post, you mention
Do you mean ARC or the EZ-B? Because the EZ-B has no relationship with the 3rd party camera being used. Please clarify
No, I mean ARC. I don't know what can be driver-related when I'm using the URL of an IP cam. I'll have to look into it further. Thanks again DJ.
If you're using the URL of an ip cam, then the issue can be network related. The ip cam may not be connected to the network at the time.
If you are always using the URL of the IP cam, the error of parsing the device name would never occur.
From what i read in the responses, sometimes you use IP URL and sometimes you specify a driver. Is this correct?
I require clarification to understand where the error resides. If you are stating that you always 100% using the IP URL and absolutely never ever use a physical device, let me know. That will be useful.
I think there's a mess to Clean up again in my project... I literally interconnected dozens of scripts using variables as triggers so I don't have them running all at once ... But there's still some cleaning to be made. I'm trying to achieve impossible goals here anyway, wanting my robot to go out in the apt. Check on some spots and come back charging... I think I'm gonna have to start drawing down my algorithms and try to achieve something much simpler and efficient. The thing is that I want to count for all possible bugs, stuck positions and all. There's also all the dead angles of my square rover which would benefit a lot from having a surrounding bumper... I have the sensors, just need to conceive the number and rethink the entire structure of it, again...
Anyway, regarding the camera yes both ip or alax.info driver. having also all sorts of trouble with ezboard constantly disconnecting but there are many possible causes that I can find in my network infrastructure and all these scripts not perfectly synchronized.
I'll work on all this and I'll come back if it doesn't change.
Question : is there a way to search for text over all the scripts at once? That would be hugely useful for checking on redundancies.
Another super super hugely needed feature : being able to see a script running without losing the hand on all other features. When I need to see how two or three scripts interact... Well it's almost impossible to do so without just guessing sometimes.
A separate window specific to script errors only another one for prints only, would also be useful.
Also, why I can't get the color coded display of the scripts? I have it on my laptop but on my desktop computer, even after reinstalling it doesn't activate.
Also can I export the variables ' list?
That's all!
:D
blush
Oh and FYI Ezb v3 should not be discontinued. It's really a great redundancy / alternative when It became imperative to reboot everything. I have two redundant ezb v3's on top of my main controller which sonic course a v4. They both allowed me to try out new scripts and have all these bugs while sitting at 130 miles from the robot...
Having the Bluetooth as a backup mean of connection, mainly for power management, is really great.
Maybe coming up with a mini Bluetooth ezb dedicated to remote rovers power redundancies and reboot possibilities?
The top of the ton would be a ezb with two separate chips and power connectivity automatically switching in case of failure. Two everything : 2 wifi, two processors but the same d and adc and etc ports... Just meditating lost in the middle of the Catskills --- it looks like Canada here.
ok, got the hardware issue fixed so I don't get the error message any longer.
Now, however, I can't get to access my camera, as I lately used to do, using the script command :
Here is how it looks :
and the variable $Rover prints out this address :
http://192.168.10.179:80/video.cgi?rate=0&user=XXXX&pwd=XXXXXXX
if I don't use the variable but type the url directly, same issue.
It's frustrating because I had finally got to access my camera without using Alax.info filter and now, for some reason, it doesn't work any longer.
I get the JPGStream Read Error.
Same camera, nothing changed. Maybe I'm forgetting something regarding the url, but no idea... probably this little thing that I'm not thinking about... of course. But I'm sure of one thing, I had been using the url access to the camera for weeks before I had this bug.
@Dj, I know this is only a temporary fix, but have you implemented yet a "refresh" command in an upcoming new version of ARC ? This is the only thing that allows me to script a reboot of the camera. This is another issue than the one I was just talking about. I still need to press refresh before I can see the camera feed again, using Alax.info filter.
Thanks a lot everybody.