View Full Version : Toggle Between Two Cameras in Vision Processing
RoboBucs
31-01-2015, 13:48
Hello, I am trying to make it to where I can toggle between two cameras in vision processing, and I tried to toggle between the cameras with a button on the joystick, but it did not work. How would I fix this?
http://i.imgur.com/WngxWfg.png
http://i.imgur.com/keFgzgs.png
Are you using Axis cameras or USB cameras?
Greg McKaskle
01-02-2015, 10:25
I'm not saying that this is going to fix everything, but the code is only reading the joystick once, outside the loop.
So move the Get Value inside each loop and at least at that point, you can probe and see that the buttons are working.
Greg McKaskle
RoboBucs
02-02-2015, 16:38
Ok, I am using USB Cameras, and I will try to place the get values into the loop. Thanks you all!
I'm planning to do this on our robot with USB cameras. My goal is to get the code done by tomorrow evening. If I can get it done, I'll post it.
RoboBucs
02-02-2015, 17:11
I'm planning to do this on our robot with USB cameras. My goal is to get the code done by tomorrow evening. If I can get it done, I'll post it.
That would be great! I'm still actually getting no connection between both cameras at the same time. I also tried to put the values into the loops, and there was still no change. But thank you for your idea. This is what it looks like right now:
http://i.imgur.com/amq85XX.png
Greg McKaskle
02-02-2015, 21:24
As I said, it may not fix all of the issues, but I guarantee that if you do not put the Joystick Get Values inside of each loop, you are only reading them once at the beginning. That is, I assume a part of the bug you are reporting.
Greg McKaskle
RoboBucs
02-02-2015, 22:02
As I said, it may not fix all of the issues, but I guarantee that if you do not put the Joystick Get Values inside of each loop, you are only reading them once at the beginning. That is, I assume a part of the bug you are reporting.
Greg McKaskle
Do you know anything else we could do to try to fix that? We tried it with the joystick inside with no results.
Mark McLeod
02-02-2015, 22:09
When toggling, are you by chance expecting the camera image on the Dashboard to change?
It won't, since the Dashboard forwarding is handled in the Camera IP & Dash vi.
Since you aren't doing anything in the Vision Processing loop, you won't see any effect of your joystick button, even if it weren't stuck at the first and only read.
Greg McKaskle
03-02-2015, 07:01
I had a bit more time to look at this.
As Mark mentioned, the actual code for sending USB camera images to the DB is inside of the IP & Dash VI.
What type of cameras do you have? The current WPI VIs are setup to handle one USB camera forwarded to the DB. They don't have a ready mechanism to swap cameras, but it wouldn't be hard to add it.
If one of the cameras were IP, it would be even simpler.
So, what types of cameras do you have?
Greg McKaskle
GrantCrowder
03-02-2015, 08:34
Greg, I'm assuming that this is a boolean function, so I will do some testing today with it. I'm also going to work with the dash vi today, so I will start working with it. Thanks
RoboBucs
03-02-2015, 14:13
I had a bit more time to look at this.
As Mark mentioned, the actual code for sending USB camera images to the DB is inside of the IP & Dash VI.
What type of cameras do you have? The current WPI VIs are setup to handle one USB camera forwarded to the DB. They don't have a ready mechanism to swap cameras, but it wouldn't be hard to add it.
If one of the cameras were IP, it would be even simpler.
So, what types of cameras do you have?
Greg McKaskle
They are both usb cameras, I won't know model numbers until I get to the shop today.
RoboBucs
03-02-2015, 16:21
I had a bit more time to look at this.
As Mark mentioned, the actual code for sending USB camera images to the DB is inside of the IP & Dash VI.
What type of cameras do you have? The current WPI VIs are setup to handle one USB camera forwarded to the DB. They don't have a ready mechanism to swap cameras, but it wouldn't be hard to add it.
If one of the cameras were IP, it would be even simpler.
So, what types of cameras do you have?
Greg McKaskle
The webcams are Microsoft livecam hd 3000
Ok, I hacked this together in about 90 minutes and verified it works with two of our HD-3000 cams. Everything is located in the "Vision Processing.vi". It uses the "DB/Button 1" switch on the dashboard. True will give you one camera, false the other. It only runs in "HW Mode". There is a small switching delay.
*Edit* now with file.
RoboBucs
03-02-2015, 20:05
Ok, I hacked this together in about 90 minutes and verified it works with two of our HD-3000 cams. Everything is located in the "Vision Processing.vi". It uses the "DB/Button 1" switch on the dashboard. True will give you one camera, false the other. It only runs in "HW Mode". There is a small switching delay.
*Edit* now with file.
Thank you so very much!!!
RoboBucs
04-02-2015, 16:05
Ok, I hacked this together in about 90 minutes and verified it works with two of our HD-3000 cams. Everything is located in the "Vision Processing.vi". It uses the "DB/Button 1" switch on the dashboard. True will give you one camera, false the other. It only runs in "HW Mode". There is a small switching delay.
*Edit* now with file.
Alright so we tried it today but with no results, is there anything in that VI that we need to edit other than the robot global data thing?
RoboBucs
04-02-2015, 16:47
Alright so we tried it today but with no results, is there anything in that VI that we need to edit other than the robot global data thing?
Nevermind we got it working, we just didn't assign DB/Button 1 anything *Facepalm
It's designed to be run unmodified with the default dashboard. You shouldn't have needed to modify any globals. DB/Button 1 is one of the default buttons on the default dashboard.
pastelpony
05-02-2015, 07:20
Would this work with Axis cameras or would it need to be fine tuned?
I am now in a recursive loop WRT cameras.
Please see the thread below for some code which should work with Axis cameras. I wasn't able to test that code on a robot so it may have some issues. If so, please let me know.
http://www.chiefdelphi.com/forums/showthread.php?t=133559
RobotMonkey
16-02-2015, 15:24
Just wanted to say that you are the man adciv. Using your code to switch between two USB cameras, and it works fine. I switched the toggle to happen on a joystick button press, to be easy for our driver. Now he has the stationary camera at the bottom of the lift, to help line up crates, and a camera at the top of the lift attached to a pan/tilt to get a better view of the field.
Thanks adciv.
I used your code with JS to switch cams.
The BOT Drivers were complaining about switching delay, so I tried opening two cameras and just switching the image source.
Didn't work. LV doesn't seem to like me opening two USB cameras. I get this error when I try to set the FPS on the second camera.
ERROR -1074360319 occurred at IMAQdx Start Acquisition.vi
NI-IMAQdx: (Hex 0xBFF69001) Internal error
I've included a simple example without the actual switching.
http://www.GEARSinc.org/images/cap.png
Everything work fine till I add the second cam. Any idea why LV is getting upset?
Greg McKaskle
23-02-2015, 07:48
I've definitely opened multiple USB cams on a roboRIO with no problem. I was processing them and not streaming. Are you sure that is the first call to fail?
Greg McKaskle
I've definitely opened multiple USB cams on a roboRIO with no problem. I was processing them and not streaming. Are you sure that is the first call to fail?
Greg McKaskle
I don't know which/when the call fails, but I do know that if I don't make the second call to SET FPS I don't get the error. Perhaps it's a reentrancy problem.
I'll try doing one camera setup at a time.
Phil.
Still hunting this down..
Stringing all the camera setup mods in-line didn't help.
In trying to identify the point of the error, I probed all the error outs of the first and second camera setups.
Interesting to note that even though the open to the second camera works, the SET FPS does generate an error. See the attached probe sequence.
A final point. If I just swap the USB0 and USB1 constants, the second camera is successfully displayed, so I know the second cam is functional and configurable.
Phil.
Starting to get worn out...
I reduced my problem down to two camera opens....
I open and start two cameras. The second start fails...
From the FP you can see that the system has identified the cameras properly.
Any idea why the second start doesn't work?
I've definitely opened multiple USB cams on a roboRIO with no problem. I was processing them and not streaming. Are you sure that is the first call to fail?
Greg McKaskle
It seems to be the WPI_CameraStartStopCount.vi that's causing the trouble.
The first call is fine, but the second call to IMAQdx Configure Grab is erroring out.
I can't tell if the "Cameras Address" is a valid input for the "Session" input of the Configure Grab function. It's being coerced.
The default "Start" action for an unopened USB cam is to open cam0. Is it trying to do this default action twice?
Phil.
Greg McKaskle
23-02-2015, 18:04
I have been able to reproduce the issue here and I'm speaking with the IMAQ group. I'll let you know what I find out.
Greg McKaskle
Sorry for taking so long to pop in, been working on the robot too many hours.
I think I saw this problem when initially developing this code (Added about 40 min or so to the dev time). It would explain why I couldn't do an instant switch like I wanted.
I have been able to reproduce the issue here and I'm speaking with the IMAQ group. I'll let you know what I find out.
Greg McKaskle
Woo Hoo!!!
Greg McKaskle
24-02-2015, 14:07
Good news and bad.
The vision team now has a reproducible case of this. It only occurs on the ARM linux target with certain cameras.
Unfortunately, the camera that shows it most easily is the MS 3000. I had four camera types and didn't do all combos of two, but did enough to see that some worked and some resulted in the internal error in Start. I saw it fail with two MS 3000 and one MS3000 and one high end Logitech. I saw it succeed with one MS3000 and a lower end logitech. And saw it succeed with two Logitech cams.
My only suggestion at this point is a workaround of trying there models or makes of camera. Sorry. Thanks for reporting the bug. They should have it fixed for an upcoming release. But that will probably be after the season ends.
Greg McKaskle
Greg McKaskle
24-02-2015, 15:04
I have an update. The error message is occurring when the addition of this camera stream will overwhelm the USB bus. If the camera framerate or resolution are lowered, they claim that the error won't happen. It is a pretty lousy error message, and that is what they will try to improve.
This matches my earlier testing in that my earlier tests were with a lower res camera.
Please let me know if this doesn't solve your issues.
Greg McKaskle
I have an update. The error message is occurring when the addition of this camera stream will overwhelm the USB bus. If the camera framerate or resolution are lowered, they claim that the error won't happen..
Greg McKaskle
Hmm
Do you mean that this is error occurs if the system calculates that the total stream requirements are too high? In other words, it's a protective issue rather than an actual detected error condition?
I'm a little surprised, since my setup was only trying to run the cameras at 320x240, with a reduced frame-rate (15fpm) and reasonable compression (30).
Do you know if it uses the MAX throughput requirements, or the limited throughput based on the Camera's current settings?
The reason I ask is that I would think that two 320x240 streams would have less throughput requirements than a single 640x480 stream.
I guess I need to do a super limited test.
Phil.
OK, some updated information.
I can get both USB Camera streams to start if I go low enough in image size.
The requested frame rate or compression don't seem to have any impact.
If I set BOTH cameras to 160x120 they work....
However, if I put just ONE of them up to 320x240, the second stream does not start.
This is oddly annoying, since the system is quite capable of sending one stream at 640x480. If the system can handle an uncompressed 640x680 image (307K pixels), the you'd think it could handle two 320x240 images (153K pixels), or certainly a 320x240 image plus an 160x120 image (115K Pixels).
Thanks Greg, for the insight.
Phil.
Are you running at 30fps or 15 fps?
Are you running at 30fps or 15 fps?
I tried a range of FPS. all the way down to 5 FPS with no apparent change to the Start error.
Is there anything magic about 15 FPS. I may not have tried that value: I did try 12,10,5 etc..
Update: I just tried 15 FPS. No change. Still fails with two 320x240 videos.
The MSHD3000 cameras natively support only two framerates. One is 30fps, the other is 15fps. In all other cases, the FRC LabView VIs are running the camera at a higher FPS and only taking "every so many" frames. I wonder if the cameras are both be running at 30fps and the VIs are just notifying at the lower rates. I'll have to dig out my code on how to set them at the lower fps.
The cameras, as is, have about 103 settings for video. This is a large combination of Frame Rates, Resolutions, and if the image is compressed or not. The FRC VIs don't directly show these and the native IMAQ one which does it is something like Imaq Get All Camera Resolutions.
Greg McKaskle
24-02-2015, 23:27
I believe that this is based on the camera mode at the time of start. It is also affected somewhat on the lower level drivers, as we tested this on an Intel embedded system and didn't see this error. So this is an error propagated from the lower level drivers saying that they will not start because they cannot or will not try to attempt the USB transfers.
I no longer have the cameras, since the other group wanted to borrow them. Please open the camera and set the resolution, framerate, and compression before doing the start. See if that will convince it to startup.
Please keep me updated and when I get the cameras back, I'll do the same.
Greg McKaskle
Please open the camera and set the resolution, framerate, and compression before doing the start. See if that will convince it to startup.
Greg McKaskle
Hi. That's how I was testing them. Although I was setting up cam 1 and then starting it, followed by setting up camera 2 and then starting it.
It occurred to me that if it's the start that is causing the problem, then the start and stop could be moved into the source switching loop, and the whole open/setup/close could be left out of the loop. This may shorten the time taken to switch cameras to a less noticeable pause.
Since I'm just discovering all this code, what is the purpose of the "notify" code in the error case? The original only checks the notification status of USB 0. Does this indicate when the camera is up and running again?
Some updated information.
I'm explicitly setting the FPS to 15, however, if I enumerate the Camera modes and display the current mode, I get mode 29, which is 320x240 at 30FPS. So there is a disconnect here somewhere.
I'm basing this on memory, so I may be a little off. The way the VIs select the camera mode is they enumerate all modes and then search for the first one which meets the resolution asked for. I suspect the 30fps modes come first. In order to select a 15fps mode, it may have to be done by explicitly selecting which mode you want to use and sending that to the appropriate IMAQ VI for setting up the camera.
Greg McKaskle
25-02-2015, 18:28
The code I just stepped through picks the smallest fps that is bigger than the requested image. With the Logitech I have plugged in, it lists 7 fps rates for 320x240.
Inside of WPI_CameraSet Framerate, you can prove the array of videoModes returned from the enumeration function and you can probe the videoMode sent into the GetSafe function on the right. Use the index sent into getSafe to look at the array description.
Greg McKaskle
Was there any significant progress by now?
I have tried to use the exact same code earlier this season and got the same error on the Open vi.
We now open the camera which we want to use on each switch and the lag is very noticeable.
We use 2 Lifecams 3000, one for far shooting and one for close shooting and switching during a match makes the driver wait for the other camera to show an image.
We really need a solution for this!
Will using a different camera model fix this?
Good news and bad.
The vision team now has a reproducible case of this. It only occurs on the ARM linux target with certain cameras.
Unfortunately, the camera that shows it most easily is the MS 3000. I had four camera types and didn't do all combos of two, but did enough to see that some worked and some resulted in the internal error in Start. I saw it fail with two MS 3000 and one MS3000 and one high end Logitech. I saw it succeed with one MS3000 and a lower end logitech. And saw it succeed with two Logitech cams.
My only suggestion at this point is a workaround of trying there models or makes of camera. Sorry. Thanks for reporting the bug. They should have it fixed for an upcoming release. But that will probably be after the season ends.
Greg McKaskle
Which model Logitech cams seem to work with this? We have been having a couple flakey results with the Lifecams:
1. Exposure setting VI. Zero sets image pretty dark (but seems workable), 1-100 appears to all be the same.
2. Sometimes exposure settings "take" on boot-up, sometimes not. No rhyme or reason. With low sample size, restarting robot code from DS seems to fix this. I suspect a boot-up sequence issue with camera settings being set before camera is up and running. We tried implementing a button to set the exposure again to Zero during teleop...does nothing.
We saw this behavior with both 1 and 2 camera scenarios.
-Steve
Was there any significant progress by now?
I have tried to use the exact same code earlier this season and got the same error on the Open vi.
We now open the camera which we want to use on each switch and the lag is very noticeable.
We use 2 Lifecams 3000, one for far shooting and one for close shooting and switching during a match makes the driver wait for the other camera to show an image.
We really need a solution for this!
Will using a different camera model fix this?
Please see this thread here for a beta project which may meet your needs.
http://www.chiefdelphi.com/forums/showthread.php?p=1560711
Greg McKaskle
25-03-2016, 08:02
The good/bad news post is from last season, and I believe fixed. Though I didn't personally verify this, I did file the bug report.
The camera exposure settings for all MS LifeCams seems to be odd on UVC/linux devices. The parameters are described and given ranges that various APIs will use to communicate requested properties to the camera. The MS LifeCam exposure is described as going from 5 to 20,000, with increment of one. That is a lot of range.
http://comments.gmane.org/gmane.linux.drivers.uvc.devel/5717
That link is to a 2011 forum post about a lifeCam 5000, but explains the same behavior. I does list the magic values, which are twelve geometrically scaled numbers centered around 156. I don't have a camera to try, but if you can use the percentage equivalents, or make your own Set Exposure to avoid the floating point scaling, you can probably make a LifeCam specific Exposure VI work.
Greg McKaskle
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.