As for the camera, save the project with the camera selected. The next time you load the project, the same camera will be started. If you wish to start the camera manually, consult the ControlCommand() specific to the camera control. The learn section can advise you on EZ-Script ControlCommand() as there is a tutorial regarding EZ-Script in the activities course.

PS, all ControlCommand() syntax for each control is visible in the Cheat Sheet tab when editing a script. The activity course in the learn section is a great place to start to learn ARC and to follow programming examples.

Also, use the Script Flow Control to see an overview of the scripts. It will help you see if there are circular references.

Please post your project so we can take a look at the issues you are experiencing. Here are responses to your points.

1. ez-b will disconnect if the data channel is flooded. a look at your project can resolve that :). Additionally, check to ensure proper delays are used in loops, etc.. this is a disciplinary technique which you will learn with programming. Sleeping allows other threads to share resources, such as network, user interface and more. Without a sleep delay in loops, single process will consume all available resources.

2. the v3 is discontinued and no longer supported by ez-robot. it is not advised to run both together for the reasons you stated. The servo position count between the two boards are not compatible (v3 has 1-100 positions, while the v4 has 1-180). The software will default to the servo position count of the last connected board.

3. ARC wifi is not very fast, as it's doing a lot of processing such as audio, video and data. we do have an upgrade available in the new year with a faster processor :). There is no flaw in the current ez-b v4, it's designed to spec.

4. digital ports float until they are configured by software.

5. upgrade ARC if you notice some crashes. Although, it does sound like your project can use a little advice. Post it and i'll have a look to clean it up and get you working.

6. i2c is a communication protocol and is out ez-robot's control. the i2c protocol information is available on the internet, perhaps wikipedia. if you're i2c device is having issues, consult an experienced engineer for a possible solution. i2c devices created by ez-robot are stable because they are designed around the i2c specification. if you are manually building i2c devices, you will run into problems because it's a very fragile protocol. specifically fragile in the sense that it does not like physical wires or long wires without much design consideration.

I personally would not use EZB3 With a EZB4, because of the servo position. DJ on a post long ago was having a buy back of the EZB3 for a credit to upgrade to EZB4 because at some point EZB3 will no long be support. Software wise. EDITED*

@elfege, my apologies for my frustration as well, never post when you're having a Christmas drink. Lol

Sorry DJ you're a lot more tactful then I am plus I'm having a Christmas drink tonight Lol

LOl, thanks Merne Christmas drink would be a good idea!

Also, make sure you're using the latest ARC. You can submit a diagnostic report as well after crashes/issues, just make sure it's the latest ARC or the diagnostic report will be of no use to us. Instructions are here: https://synthiam.com/Tutorials/Help.aspx?id=220

Another tip for keeping your camera settings as you start new projects (including any recognition you have trained) is to open a new project and use the merge function to copy the camera object from your existing configured project rather than adding a new camera object.

Alan

@elfege Maybe ez robot isn't right for you? I mean it is obviously "annoying you" as stated in pretty much every one of your posts... Perhaps I could recommend ROS? Surely that would not annoy you.... :P

Richard, be nice everyone has a different threshold of frustration. I also suffer from a little frustration here and there. Mostly it's with using other people's products, which is why I put so much effort to make ezrobot better and continue to increase reliability.

I'm so excited for you all to get the new comm upgrade. Jer and I were running tests tonight, it's a tank! A serious marvel of performance and reliability. Henry, our new Scm is pushing hard at us to get it done - top priority. It will really revolutionize everything.

So, if this poster has some frustrations today - I'm okay with that. Because my days are consumed with ways to make it better and feedback always helps.

However, it's important that I view projects that provide these experiences. We test really hard to break stuff, but with a programming environment, there's an infinite number of ways to do something, therefore an infinite number of ways to break stuff.

Once I receive his project, it will be easy for me to either identify an ARC fix, or fix the project. Mostly it's fixing projects, but that's also a win :)

So, post the project and let's get crack'n at fixing this issue.

@DJ.... You suffer from frustrations from this forum? Nah, not you... You're as cool as a cucumber dude... :D

Not the forum - surprisingly the forum is a good place to escape. This week has been frustrations programming with a library that is incomplete and full of bugs. I've spent the last week - 18 hours a day - fixing someones bugs in a framework before I can use it. :)

This forum stuff is a breeze!

@DJ.... We do our best to keep you entertained.... Now you got us all excited about the ezb4 1/2 and other goodies you are working on.... :)

oh yeah! 2016 is a big year - boy this thread got really off topic. Think of it as chatting while we wait for the project to be posted :)

While we wait for your project, here's the latest update which will not auto-start the camera when it's added to the project for you: https://synthiam.com/Community/Questions/8766

Also there is a performance setting for data channel flooding, which may be of help to you. Information about it is in the link above. Also, there is a help hover icon on the setting in the software.

Let me know!

indeed, @DJ, this is certainly a question of discipline in the scripting that I don't always apply to my programming in EZB. EZB allows for some... very inspirational scripting sometimes ! :D

For what regards the camera issue it switches sources by itself, no apparent reason beside the fact that it seems to happen after some connectivity bugs. It does not happen between close/open ARC actions.

Thanks again.

here it is, sorry.

FYI the performance data channel did improve the whole thing a lot! Thanks!

Thanks for posting - here's some information to help your project. BTW, great project with lots of features, it was fun to review!

1. Many loops that are eating up resources without Sleep(). A loop without a Sleep() will use as much CPU as available. This means it could potentially use more CPU than even the camera video stream. A Sleep() allows the CPU to do something else.

2. Code formatting will make logic errors easier to notice. The ALT-F shortcut when editing code will automatically format code for you. There are many logic errors in conditions - specifically redundant conditions in nearly all scripts. Although if the logic works, it really only uses additional resources, but it is a good idea to format the code with ALT-F. It will help in the future when code is revisited. Also, with the latest ARC, there are dramatic stability improvements which will benefit from the number of scripts that your project uses.

3. With plenty of Read commands, the project may benefit from tweaking the data channel flood setting in the Connection Control Settings. There is a question mark, which you can hover the mouse over to read how it works. Use the benchmark utility in a blank project to experiment with a value which is right for your PC and network. This will dramatically increase READ performance (on my computer from 5 reads per second to 70 reads per second).

4. The comment #3 also applies to the number of Digital Controls and GetDigital() commands redundant in code. The Digitial Controls and the GetDigital() EZ-Script commands are both reading from the same digital ports. This means twice (200%) the number of communication channel reads, which is an excess amount of unneeded data requests, resulting in 200% less performance. This also applies to the ADC as well - as there are meters and getadc() commands redundant throughout the project. My recommendation on both ADC and Digital is to set variables and use the Variable Watcher to see their values.

5. ARC version appears to be quite old. As mentioned, there have been dramatic stability and performance improvements with newer versions. Specifically the way the EZ-Script engine handles threads - and the ability to adjust data channel flood protection. Your ARC version 4 months old.

[feature] <EZBuilderVersionMajor>2015</EZBuilderVersionMajor> <EZBuilderVersionMinor>8</EZBuilderVersionMinor> <EZBuilderVersionBuild>9</EZBuilderVersionBuild> [/feature]

6. The Mobile Interface has a camera control with a strange address. It appears the address is for an IP Cam? If so, the address field of the mobile interface is for EZ-B v4 cameras, not any camera. By default, the mobile interface will display the video of the first camera control added to the project. I'm not certain what the behavior would be on a mobile interface with an IP Camera URL specified - but i can be quite accurate to say it won't work due to the protocol being specific to EZ-Robot.

http://192.168.11.179/videostream.cgi?rate=0&user=elfege&pwd=*******

Let's take a look at one of the scripts which stands out. Here's an example with the Reconnect All in Script Manager.

The Original Code:

:loop0
 if(isconnected(2)=1)
ControlCommand("Script Manager", ScriptStart, "PowerON")
 goto(loop)
 else 
 ControlCommand("Connection", connect2)
 endif 
 if(isconnected(2)=1)
 ControlCommand("Script Manager", ScriptStart, "PowerON")
 goto(loop)
 else 
 goto(loop0)
 endif 
 
 
 :loop

 if(isconnected(0)=1) 
 if(isconnected(1)=1)
 if(isconnected(2)=1)
 
Print("All boards are connected")
goto(continueboot)
endif
Endif 
Endif 

if(isconnected(0)=0)
sleep(100)
ControlCommand("Connection", connect0)
endif 


if(isconnected(0)=0)
goto(loop)

endif 

 if(isconnected(1)=0)
 sleep(100)
ControlCommand("Connection", connect1)

Endif
Goto(loop)

:continueboot
halt()

There are no delays in the above code, which will use as much CPU as available. A loop without a Sleep() will consume literally as much CPU as it can. So, unless this is the most important script in the project, even more important than the camera control or anything else, it should have a Sleep() in there.

Also it has redundant conditions, which i notice happens often in nearly every script. This can cause our human brains to sometimes struggle when re-visiting the code. Always a good suggestion to revisit scripts and condense/format them. We will never write a perfect script the first time.

For example, here is the above script modified. You will notice how I used logical conditions to prioritize which board is connected first, as duplicating the desired functionality that I believe the original script was attempting. Also I have added a delay in the loop to be friendly on the CPU. Lastly, the code is formatted nicely which makes it easier to read, specifically if revisited in the future.

:loop

# board #2 we want connected first
IF (isconnected(2) = true)
  ControlCommand("Script Manager", ScriptStart, "PowerON")
ELSE
  ControlCommand("Connection", connect2)
ENDIF

  # board 0 is connected second
IF (isconnected(2) = true && isConnected(0) = false)
  ControlCommand("Connection", connect2)
ENDIF

  # board 1 is connected third
IF (isconnected(2) = true && isConnected(0) = true && isConnected(1) = false)
  ControlCommand("Connection", connect0)
ENDIF

  # if all boards are connected, let's get outta here
IF (isconnected(2) = true && isConnected(0) = true && isConnected(1) = true)

  print("All Boards Connected")

  halt()
ENDIF

sleep(100)

goto(loop)

Haha, now this isn't an issue but i love it - because I do the same thing. I see you used excel to create a list of commands. Smart man! Great minds work alike :)

set       (         D1        , off)
set       (         D2        , off)
set       (         D3        , off)
set       (         D4        , off)
set       (         D5        , off)
set       (         D6        , off)
set       (         D7        , off)
set       (         D8        , off)
set       (         D9        , off)
set       (         D10       , off)
set       (         D11       , off)
set       (         D12       , off)
set       (         D13       , off)
set       (         D14       , off)
set       (         D15       , off)
set       (         D16       , off)
set       (         D17       , off)
set       (         D18       , off)
set       (         D19       , off)
set       (         D20       , off)
set       (         D21       , off)
set       (         D22       , off)
set       (         D23       , off)

Thanks a lot for this very extensive analysis on my scripts! Wow!

Regarding the camera, no, I don't use an ip, at least not directly. I use a directshow filter so the one in the list that you should see if you were locally connected to my network and had the proper directshow installed, is named "rover" and fortunately the password that you saw is no longer in use! ;)

The camera list switching to EZB default's camera is still a problem and it'd be great to solve it. I also use the EZB's camera but not as a main camera, more for the robot's arm so I can see closely what I'm grabbing and eventually even have things recognized and grabed automatically (like my cat's tale... but my wife doesn't agree with that part... fortunately I was able to get rid of most glyphs I was using for self docking since I can use now a compass thanks to Jeremie's genius).

regarding ARC version I'm not sure to understand. It is true that this file was created a while ago, but I'm definitely working on the latest version of the software so maybe it doesn't impact the original file and therefore that's a problem to solve : how do I get to benefit from updates without having to re-create the file itself (even though I could simply merge) ?

Regarding CPU usage I lately added many more sleep() in my loops. Still have to work on the redundancies. Some redundancies, though, are necessary for the rover to reconnect itself at any time while I'm away and it's running.

For the rest I'm going to look at all what you wrote carefully as of now and do the necessary modifications.

many thanks, Elfege

I see that in the corrected code that you wrote (thank you, btw), you use both boolean and C logical connectors (&&). Can you use others such as != and == ?

I really didn't know how to add 3 conditions like you do it beside by accumulating if's, which is a inconvenient in many ways.

Another thing : how do you get the system to remember variables? Each time I use variables declared at the beguining of a script, after any new ":reference" it acts as if it had lost them and won't read the associated sensor anymore. I noticed that issue in C programming too, after closing } I do have to re-declare certain variables but not all and I never got what caused this.

Thanks, Elfège.

1. How are you using 2 different cameras if there is only 1 camera control? There is a camera added to the mobile interface, but that has the strange url ip assigned (it's on the second virtual desktop)

2. what do you mean that a variable disappears after it is referenced? When you reload a project the variables will be cleared but not when the project is running - unless you call the clear variables function or press clear variables in the variable viewer.

3. Yes you can use != and == etc

4. regarding the project version, it's good to hear that you're running the most recent. I just wanted to ensure that you were. Thanks for confirming, because the latest version has so many stability improvements in scripting and threading - it's highly noticable.

1. Discard the one in the mobile interface. That's old stuff from when I was hopping I could have a video feed from my night vision ip cam to my mobile app and, also, when I was dreaming of port forwarding the whole thing and control the robot from the internet instead of local network only. It is actually really weird that I couldn't figure it out but I seem to remember that before giving up on that I had read that it was actually not possible due to a limited amount of ports available. However I really wonder why I could not do a simple http://mypublicIP:port where the port would be any port forwarded to port 80 pointing to the EZB V4 internal http port. I tried telnet ports too but the mobile app won't accept a connection this way either. So far I only use telnet to launch scripts but no mobile interface yet. That'd be a great feature to add and basically it only needs, I think, that the mobile app allows it instead of systematically blocking the use of a public IP... but if you can show me where I'm wrong and how this is in fact perfectly achievable, I not only will feel a little shame for not being able to do this with EZB while I have so many port forwardings that I have to add several routers so I don't exceed ther limitations (being busy with video surveillance when I'm away for instance), I'll also consider sending you a bottle of a good Champagne (at least in the form of a picture...).

2. About variables I have no clear all variable script running except for clearlastglyph, which is not the same I suppose. It really behaves sometimes like the variable is simply forgotten. If I write this, for instance :

:start $variable = getadc()

repeatwhile($variable = value) actions sleep() Endrepeatwhile

instead of this :

:start

repeatwhile($variable < value) $variable = getadc() actions sleep() Endrepeatwhile

then the loop won't end even though variable has gone beyond the value.

Maybe it's due to the excess of processes and maybe I'm basing this on only a couple of times I experienced something that looked like it. I'll test it further if you can't reproduce it. Just do it in a long script where a lot of other lines are written between the declaration of the variable and the request inserted in a repeat loop.

Not sure if I'm totally clear... kinda reaching the limit of what I can explain in what remains my second language! :)

Oops... this message had to be deleted...

Oops... message deleted by the author (like the previous one).

BTw I didn't answer a question :

So one main camera for all operations, a pan tilt foscam night vision, very convenient, through direct show so it shows in the list of cams in EZB.

Another cam for the arm, this one doesn't need night vision, been using EZB for a while but recently switched with a cam coming from a wowwee toy for I need ezb cam for another purpose at work.

Now, it would really be awesome if swithcing cams in the list could be scripted.

Thanks

This is correct regarding the variable example. I'll post both here with a title so they can be referenced in the description below

Version 1

:start

$variable = getadc()

repeatwhile($variable = value)

  actions

  sleep()

Endrepeatwhile

Version 2

:start

repeatwhile($variable < value)

  $variable = getadc()
  actions
  sleep()

Endrepeatwhile

So what's happening in Version 1 is that the GetADC value is applied to the variable only one time, before the RepeatWhile begins. Version 2 gets the ADC value each time the loop occurs.

What happens when you assign a variable is it holds a value. For example, when you put..

$variable = GetADC(0)

The $variable will hold the value that the ADC Port #0 had for ever, until it's told otherwise. If you assign a variable a value, it will never change unless you tell it to. A variable is like a pocket in your pants. If you put a used tissue in your pocket, no matter how long you wait, it will always be there. If you wish for the tissue to not be there, you have to remove it. If you wish for something else to be in the pocket instead of the tissue, you remove the tissue and replace it with something else.

Here is how variables work...

# make $x hold the value of 1
$x = 1

# print the value of $x, which will be 1
print($x)

# now put the value of 2 in the variable
$x = 2

# print the value of $x, which will now be 2
print($x)

The same applies when you assign the value to a result of a function..

# make $x hold the value of ADC(0)
$x = GetADC(0)

# print the value of $x, which was the value when the GetADC() happened
print($x)

# now get the latest value of ADC(0)
$x = GetADC(0)

# print the value of $x, which will now be the last time we got the ADC value
print($x)

Lastly, the question regarding starting the camera with a specific device. That already exists.

There is a feature when editing scripts called Cheat Sheet. This is a tab which displays all available commands of any control added to ARC.

The option you are looking for is listed in the Cheat Sheet under the camera control. Here is exactly how to use it..

[feature] ControlCommand("Camera", CameraStart, [Camera URL:PORT]) [/feature]

and an example code would be

ControlCommand("Camera", CameraStart, "Rover")

Damn! I definitely have a problem with the Cheat Sheet each time I'm looking for a new / never used before feature I just can't find it. I'm sorry about this, this is so stupid... Thanks anyway.

If it's helping, it isn't stupid :D. I'm also sure a huge number of people are watching this thread and also learning :)

ARC is MASSIVE and it's funny - because some people say "document more", but we do, it's just that the documentation is also massive! Haha, such as the cheat sheet. The Cheat Sheet is the world's best documentation for "what you can do". The problem is that there's a lot you can do!

I always forget what commands are even possible. When you asked about the camera, i had to look to see if it was even there!

Hi,

I'm coming back to this forum because I'm still struggling with cameras. I can't get the script supposed to start the camera to actually start it because each time I used a camera, well I need to refresh the list for the camera to work again. Otherwise the start button is stuck to "stop" (as if camera was running, but it's not) and I get error messages each time I try to actually stop it.

So, in clear : most of the time I can't stop a camera to restart it while there's no more picture. It's frozen on run mode. The only way is to restart ARC.

here is the error message :

Error Initializing Camera: System.Runtime.InteropServices.COMException (0x800401E4): Invalid syntax (Exception from HRESULT: 0x800401E4 (MK_E_SYNTAX)) at System.Runtime.InteropServices.UCOMIMoniker.ParseDisplayName(UCOMIBindCtx pbc, UCOMIMoniker pmkToLeft, String pszDisplayName, Int32& pchEaten, UCOMIMoniker& ppmkOut) at Rp33miUMIGbqXYpali.lvF6UlmL50Nw9ZUXPA.scapxQaT9t(String ) at Rp33miUMIGbqXYpali.lvF6UlmL50Nw9ZUXPA..ctor(String ) at EZ_B.Camera.StartCamera(ValuePair videoCaptureDevice, Control processedPreviewControl, Control realtimePreviewControl, Int32 captureWidth, Int32 captureHeight). Resolution: 320x240 Error Initializing Camera: System.Runtime.InteropServices.COMException (0x800401E4): Invalid syntax (Exception from HRESULT: 0x800401E4 (MK_E_SYNTAX)) at System.Runtime.InteropServices.UCOMIMoniker.ParseDisplayName(UCOMIBindCtx pbc, UCOMIMoniker pmkToLeft, String pszDisplayName, Int32& pchEaten, UCOMIMoniker& ppmkOut) at Rp33miUMIGbqXYpali.lvF6UlmL50Nw9ZUXPA.scapxQaT9t(String ) at Rp33miUMIGbqXYpali.lvF6UlmL50Nw9ZUXPA..ctor(String ) at EZ_B.Camera.StartCamera(ValuePair videoCaptureDevice, Control processedPreviewControl, Control realtimePreviewControl, Int32 captureWidth, Int32 captureHeight). Resolution: 640x480

Let me know if there's anything you can suggest me from there.

Thanks.

also, is there a script command to refresh the list ? That'd be useful and, I swear, this time I looked extensively into the cheat sheet! :)

Haha there isn't a refresh ControlCommand for the camera. That's a strange error - it's a hardware error. I can add a refresh for you. I'm wondering what that hardware error is about... Maybe the camera takes a little longer than usual to initialize? Or is the resolution unsupported?

What settings do you change to get the camera to start working? Hardware errors are nearly impossible to debug when we didn't make the hardware.

I too have this refresh necessity. If I don't refresh the list, the camera may not appear in the list, or I just can't start it without refreshing. A refresh script command would be nice, or perhaps a "refresh on load" feature could be made. I don't get an error though.

As a quick workaround, the Remote Mouse plugin can be used to automate just about anything you can do in ARC with a mouse that there isn't an existing ControlCommand() for: https://synthiam.com/redirect/legacy?table=plugin&id=37

Alan

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.

Quote:

Error Initializing Camera: System.Runtime.InteropServices.COMException (0x800401E4): Invalid syntax (Exception from HRESULT: 0x800401E4 (MK_E_SYNTAX)) at System.Runtime.InteropServices.UCOMIMoniker.ParseDisplayName(UCOMIBindCtx pbc, UCOMIMoniker pmkToLeft, String pszDisplayName, Int32& pchEaten, UCOMIMoniker& ppmkOut) at Rp33miUMIGbqXYpali.lvF6UlmL50Nw9ZUXPA.scapxQaT9t(String ) at Rp33miUMIGbqXYpali.lvF6UlmL50Nw9ZUXPA..ctor(String ) at EZ_B.Camera.StartCamera(ValuePair videoCaptureDevice, Control processedPreviewControl, Control realtimePreviewControl, Int32 captureWidth, Int32 captureHeight). Resolution: 320x240

The driver is not returning successfully and the name of the camera cannot be parsed yet. What is happening is one of two things...

1. Another program is attempting to use the camera device

2. 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

3. The usb port or cable is damaged and the camera is not making a reliable connection

4. The camera driver is not 100% compatible with your OS version

5. The camera hardware is buggy

6. 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

Quote:

to get it working i need to restart ezb

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 :

 ControlCommand("Camera", CameraStart, [Camera URL:PORT]) 

Here is how it looks :

 ControlCommand("Camera", CameraStart, $Rover) 

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.

@Dj

Ok, now I see a little bit more clearly in this.

I just did a test : If I run the camera (using alax.info driver) using the command :

 ControlCommand("Camera", CameraStart, "Rover") 

I get the same error message as before, the one that you said was hardware related.

But if I manually select the camera in the list and run press the start button or run the following command :

 ControlCommand("Camera", CameraStart) 

that is to say, without specifying the driver or any item whatsoever, then it works.

Any idea on what can make that happen ? Can it still be just hardware related ?

Thanks.