What does the Camera Slow Down?

[Greg McKaskle]

If you want to lower the overhead of the Dashboard, open the source project and right click on the image display and toggle Visible>>Image Information to be off. You can achieve similar effect by deleting the chart or modifying the chart drawing region so that it is not overlapped by the Y scales.

The combination of these two drawing elements that invalidate in order to update, will cause a large section of the screen to be redrawn, not just the modified areas.

I don't know enough about the Java video to guarantee that this will get rid of the lag, but it will not hurt either.

As for using raw TCP to transfer video, the underlying camera uses ...
wait for it
...
wait for it
...
TCP.

Sorry, but I couldn't resist. My two year old now says that -- the wait for it part.

While I agree that it is not the ideal protocol, it isn't as bad as described, because it is the underlying IP packets that are acked and retransmitted, not the entire TCP message. Since it is not possible to decode a jpeg past a missing packet, incomplete jpegs do need to be detected and dealt with. Ideally, the images would be sent over RTP or a similar specialization of UDP.

Actually, as the topology of the robot network changes, the camera may someday be moved to be on a common switch so that the camera can serve up images to both the robot and DB, meaning that no image server is needed. That'd be nice.

Greg McKaskle

[Joe Hershberger]

Originally Posted by ErichKeane

Yep, seems like that is the case. Perhaps it would give me a reason to fix the WPILib like I've been promising myself for years

For any improvements you make, please submit patches as artifacts on the wpilib project at firstforge.wpi.edu

Thanks,
-Joe

[MishraArtificer]

Originally Posted by slavik262

The problem seems to have much more to do with the Classmate having issues rendering video and working the TCP stream at the same time due to its absolutely [sarcasm]wonderful processor[/sarcasm].

Is there absolutely nothing to be done about gutting the WinXP install on the Classmates to be able to do more with that chip? I'm aware that hardware-wise, we're screwed, but are we allowed to disable background processes that the Classmates won't be needing for our purposes (such as the Print Spooler)? Someone pointed me at one of the rules in the rulebook, but my machine here at home won't download it properly...

[Greg McKaskle]

While it may be cathartic to gut something every now and then, you may want to look at the task manager before spending the effort. I think you'll find that while there are threads and processes spun up, they aren't doing much.

You will get much better results by hiding the label I mentioned. In hindsight, I'd have hidden it myself, but I thought the performance was acceptable.

Also, I found this info using the profiler built into LV. If you are trying to speed something up, I highly recommend taking measurements first, to know what is slow.

If you have other questions, please post.
Greg McKaskle

[Dave Scheck]

Originally Posted by Greg McKaskle

Also, I found this info using the profiler built into LV

I don't have LV in front of me, so forgive me if this is something that can be figured out in a few seconds of playing around. Where is the profiler located? Is there anything that would be beneficial to know for a first time user? I'm assuming this should be run on the classmate to get the most bang for the buck and I'm also assuming that it has to be run in the developer account (with no way to profile in the driver account). Thanks!

[Greg McKaskle]

I'll be happy to give a bit of guidance.

As with most profilers, it isn't hard, but getting good data and finding the needle in the haystack sometimes takes some finesse.

You will want to run in the developer account, or possibly run on a different computer -- its what I did. By the way, once you use it on the dashboard, you may find it useful on the cRIO too, if using LV.

The profiler is located under Tools>>Profile>>Performance and Memory. It opens the profile window. Open the project for the dashboard, open the dashboard panel, its diagram, start the driver station, killing the DB it opens if necessary. Open the profiler and ...

1. Press Start on the profile window.
2. Run the dashboard for five or ten seconds.
3. Abort the dashboard.
4. Press Stop on the profile window.

This should give you a table. Rows of VIs with columns for VI time, subVI time, and total time. To hunt for the hot spot, it is often useful to sort by different columns by clicking on the header above the column. Clicking on a row hilights it to more easily follow it and absorb what the row is telling you. Additionally, it is often useful to double click a VI row to see how that item was affected by subVI calls. This lets you see how common subVI calls are charged to different callers. You can right click on a row to access a contextual menu that aids navigation to hierarchy, to the VI, or to callers. You may also find it useful to turn on Timing Statistics (after the fact is fine). I don't use it for statistics so much as number of calls to spot n-squared algorithms, etc. Also useful (after the fact is fine) is the Timing Details to see drawing time, display time, etc.

Saving the profile data will put it into a spreadsheet file. You cannot load it into the profile window again, but you can make due with loading several sheets into Excel and doing your own before and after comparisons.

The profiler works at the VI level, meaning it is a little coarse, but since it is pretty easy to make subVI from selection, it is usually good enough to get you in the ballpark of the hotspot, and if not, you can introduce new profile VIs easily. Similarly, you can comment out code using the Diagram Disable structure to surround code.

Note:
The profiler only records and reports complete VI runs. If a VI was already running when the profiler was started, its time will not be in the report. For the complete picture, start the profile before you profile what you care about. If you know that you are calling into the subVIs where the hotspot likely is, you can Start mid-application and hit the snapshot button to see intermediates. This is very useful for ad hoc measurements, but be careful to remember what you aren't profiling by doing this.

Let me know what else is confusing. Hope this helps.
Greg McKaskle