AIRWiki - User contributions [en]

Cameras, lenses and mirrors

2011-09-29T11:37:21Z

DavideRizzi:

==IMPORTANT NOTES==
'''Never touch the sensor element (CCD or CMOS) of a camera with anything!''' It can very easily be scratched.

'''Never touch the glass elements of a lens with your hands!''' The oil from human skin will cause damage.

==Cameras==
In the AIRLab you can find different kind of cameras. These are the main groups:
*'''Analogue cameras'''. Video output is given as an electrical signal, which needs analogue-to-digital conversion to be processed by a computer; this is done by a specific card called ''frame grabber'' or ''video capture card'' (the latter tend to be the lowest-performance items; see [[Cameras, lenses and mirrors#Frame grabbers]] for details). Analogue video is outdated for computer vision and robotics applications, due to its cost, low performance and complexity; nowadays digital camera systems (such as all the ones listed below) are always preferred.
*'''USB cameras'''. Usually very cheap, they are suitable for low-performance applications (i.e. those where low frame rate is needed and low image quality can be accepted). Their main advantage (along with cost) is the fact that every modern computer has USB ports. The fact that the USB standard includes 5V DC power supply lines helps simplifying camera design and use.
*'''FireWire cameras'''. The FireWire (or IEEE1394) bus is generally used for low-end industrial cameras, i.e. devices with technical characteristics much superior to those typical of USB cameras but low-performance according to typical machine vision standards. Industrial cameras usually give to the user a much wider control over the acquisition parameters compared to consumer cameras, and therefore they are usually preferred in robotics; their downside is the higher cost. There are different versions of IEE1394 link (see http://en.wikipedia.org/wiki/Firewire for details), with different bitrates, starting from the 400Mbit/s FireWire 400. Generally they are all considered superior to USB 2.0, even if theoretical bandwidth is lower for FireWire 400. Firewire ports can include power supply lines, but some interfaces (and in particular those on portable computers) omit them. Although the use of FireWire interfaces has expanded in recent years, they are not yet considered a standard feature for motherboards.
*'''GigE Vision cameras'''. GigE Vision (or Gigabit Ethernet Vision) is a rather new connection standard for machine vision, based upon the established Ethernet protocol in its Gigabit (i.e. 1000Mbps) version. It is very interesting, as complex multiple-camera systems can be easily built using existing (Gigabit) Ethernet hardware, such as cables and switches. Vision data is acquired simply through a generic Ethernet port, commonly found on motherboards or easily added. However, 100Mbps (or ''fast Ethernet'') ports are not guaranteed to work and can sustain only modest video streams; on the other hand, 1000Mbps ports are now standard on motherboards, so this will not be a problem anymore in a few years. It seems that GigE Vision is becoming the most common interface for low- to medium-performance industrial cameras.
*'''CameraLink cameras'''. Cameralink is a high-speed interface expressly developed for high-performance machine vision applications. It is a point-to-point link, i.e. a CameraLink connection is used to connect a single camera to a digital acquisition card (''frame grabber''). Its diffusion is limited to applications where extreme frame rates ''and'' resolutions are needed, because CameraLink gear is very expensive.
*'''ST Camera boards'''. Cameras with cell phone sensor and ARM processor for onboard computation.

The following is a list of the cameras available in the AIRLab. (To be precise, it is a list of the cameras that are modern enough to be useful.) For each of them the main specifications (and a link to the full specifications) are given. Details on the different types of lens mount are given below in [[Cameras, lenses and mirrors#Lenses]]. The 'how many?' field tells if multiple, identical items are available. Finally, the 'where?' field tells you in which of the AIRLab sites (listed in [[The Labs]]) you can find an item, and the 'project' field is used to specify which project (if any) is using it.

Ah, one last thing. People like to actually ''find'' things when they look for them, so '''don't forget to update the table when you move something away from its current location'''. If you don't know where you are taking it, just put your name in the table.

==List of Cameras==
{| border="1" cellpadding="5" cellspacing="0"
!resolution
!B/W, color
!max. frame rate
!sensor size
!interface
!maker
!model
!lens mount
!how many?
!where?
!project
!link to full specifications and/or manuals
|-
|1628x1236
|B/W
|24fps
|1/1.8"
|CameraLink
|Hitachi
|KP-F200CL
|C-mount
|1
|DEI
|
|[[media:KP-F200-Op_Manual.pdf]]
|-
|752x480
|color
|70fps
|1/3"
|GigE
|Prosilica
|GC750C
|C-mount
|3
|Lambrate (1/3), [[User:SimoneTognetti| Simone Tognetti]](from 19/05/2009, dal 14/12/2009 sono impiegate per esperimenti Affective nell'Airlab del DEI)(2/3)
|Driving companions (2/3)
|http://www.prosilica.com/products/gc_series.html
|-
|659x493
|color
|90fps
|1/3"
|GigE
|Prosilica
|GC650C
|C-mount
|1
|Lambrate
|
|http://www.prosilica.com/products/gc_series.html
|-
|1024x768
|color
|30fps
|1/3"
|GigE
|Prosilica
|GC1020C
|C-mount
|2
|Lambrate (2/2)
|RAWSEEDS (1/2)
|http://www.prosilica.com/products/gc_series.html
|-
|CCIR (625 lines)
|B/W
|CCIR (50fps, interlaced)
|2/3"
|analogue
|Sony
|XC-ST70CE
|C-mount
|2
|DEI (2/2)
|
|[[media:XCST70E_manual.pdf]]
|-
|659x494
|color
|30fps
|1/4"
|FireWire 400
|Unibrain
|Fire-i 400 industrial
|C-mount
|3
|Lambrate (3/3)
|RAWSEEDS (3/3)
|http://www.unibrain.com/Products/VisionImg/Fire_i_400_Industrial.htm
|-
|659x494
|color
|30fps
|1/4"
|FireWire 400
|Unibrain
|Fire-i board camera
|proprietary
|8
|Lambrate (3/8), Bovisa (2/8), [[User:PaoloCalloni]] (1/8), [[User:DavideMigliore]] (1/8), [[User:CristianoAlessandro]] (1/8),

presa 1 a fine febbraio10 con lente wide (quella di riserva di robocom), montaggio "a la rizzi" con lastrine di plexiglass e pezzo di profilato item [[User:Domenicogsorrenti]] (1/8)
|RAWSEEDS (2/8), MRT (?/8)
queste sono quelle "nuove"? se si una e' su rabbiati, portiere di mrt, sin da cuvio, e' nella testa omnidir Domenicogsorrenti 21.04.09

1 nuova e' la frontale di recam

1 nuova sulla testa omnidir di ridan

|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|640x480
|color
|30fps
|1/4"
|FireWire 400
|Unibrain
|Fire-i digital camera
|fixed optics (4.3mm, f2.0)
|4
|
1 e' sulla testa omnidir di rigo

1 e' sulla testa omnidir di recam

1 e' sulla testa omnidir mrt05-03 (armadio domenico@unimib)

1 e' sulla testa omnidir mrt05-04 (armadio domenico@unimib)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_DC.htm
|-
|640x480 dual sensor, 9cm baseline
|color
|30fps
|1/3"
|FireWire 400
|Videre Design
|STOC stereo-on-a-chip stereo camera
|C-mount, fitted with two 3.5mm, f1.6, 1/2" lenses
|1
|Lambrate => li lin office => Domenicogsorrenti 13.01.09 => giulio fontana 23.01.09
|
|http://www.videredesign.com/vision/stoc.htm
|-
|640x480
|color
|60fps
|1/3"
|FireWire 400
|Videre Design
|DCSG (associated with STOC)
|C-mount, fitted with one 3.5mm, f1.6, 1/2" lens
|1
|Lambrate
|
|http://www.videredesign.com/vision/dcsg.htm
|-
|?
|color
|30 fps
|1/3.8 inch optical format
|?
|ST Microelectronics
|ST1-Cam + ST2-Cam
|integrated
|2
|ST1-Cam (STLCam (ST LEGO Camera)) (with Anil until 15.10.2010)[[User:AnilKoyuncu| Anil Koyuncu]], ST2-Cam [[User:LorenzoConsolaro | Lorenzo Consolaro]] and [[User:DarioCecchetto | Dario Cecchetto]]
|ST1-Cam [[RunBot: a Robogame Robot]]
| [[Media:Cameradatasheet.pdf]],‎[[Media:Rvs-v1-0.pdf‎]], [[Media:RVS_Datasheet_v2.1.pdf‎]] ,http://www.danielecaltabiano.com/wwme/ST-SW/st-sw.htm, ‎[[Media:Cam_pin_map.pdf]]
|-
|?
|color
|?
|?
|?
|ST Microelectronics
|ST5-CamMic + ST6-CamMic
|integrated with microphone
|2
|ST5-CamMic [[User:AndreaBonarini| Andrea Bonarini]], ST6-CamMic AIRLab per E-2?
|ST6-CamMic [[E-2?]]
|
|-
|?
|color
|?
|?
|?
|ST Microelectronics
|ST4-DC (Demo board)
|integrated
|1
|[[User:RaffaelePetta|Raffaele Petta]]
|-
|?
|color
|?
|?
|?
|ST Microelectronics
|ST5-CamMic + ST6-CamMic
|integrated with microphone
|2
|ST5-CamMic [[User:AndreaBonarini| Andrea Bonarini]], ST6-CamMic AIRLab per E-2?
|ST6-CamMic [[E-2?]]
|
|-
|?
|color
|30 FPS
|?
|USB 2
|?
|Microsoft Kinect
|?
|1
|[[User:CristianMandelli|Cristian Mandelli]], [[User:DeborahZamponi|Deborah Zamponi]] July/August 2011
|[[http://airlab.elet.polimi.it/index.php/E-2%3F_-_A_robot_for_exhibitions E2? A robot for exhibitions]]
|
|
|}
 

==Lenses==
Be aware that sensor dimension (i.e. its diagonal, measured in fractions of an inch) is ''not'' the same for all cameras. Therefore one of the key specifications for a lens is the maximum sensor dimension supported. If you use a given lens with too big a sensor, the edges of the image will be black as they lie outside the circle of the projected image. Also beware of the strange convention used for sensor diagonals, i.e. a fraction in the form A/B" where A and B are integer ''or non-integer'' numbers. For instance an 1/2" sensor is smaller than an 1/1.8" one.
The variability of sensor dimensions has another side effect: the same lens has a different angle of view if you change the sensor size. Therefore the same lens can behave as a wide-angle with a large sensor and as a telephoto with a small sensor.

An useful guide to lenses (in Italian or English) can be found at http://www.rapitron.it/guidaob.htm.

The following is a list of the actual lenses available in the AIRLab. For each of them the main specifications (and a link to the maker's or vendor's page for full specifications) are given. A '?' means an unknown parameter: if you know its value or experimentally find out it when using the lens (e.g. the maximum sensor size), please ''update the table'' before the information is lost again! Lenses having 'M12x0.5' in Column 'mount type' are only usable with Unibrain's Fire-i board cameras. A 'YES' in the 'Mpixel' column indicates a so-called ''Megapixel lens'', i.e. a high quality, low-distortion lens designed for high-resolution industrial cameras (typically having large sensors); please note that some of these are specifically designed for B/W (i.e. black and white) cameras. The 'how many?' field tells if multiple, identical items are available. Finally, the 'where?' field tells you in which of the AIRLab sites (listed in [[The Labs]]) you can find an item, and the 'project' field is used to specify which project (if any) is using it.

Ah, one last thing. People like to actually ''find'' things when they look for them, so '''don't forget to update the table when you move something away from its current location'''. If you don't know where you are bringing it, just put your name in the table.

===C-mount and CS-mount lenses===
Industrial cameras usually have interchangeable lenses. This allows for the choice of the lens that is more suitable to the considered application. There are two main standards for industrial camera lenses: '''C-mount''' and '''CS-mount'''. Both are screw-type mounts. CS-mount is simply a modified C-mount where the distance between the back of the lens and the sensor element (CCD or CMOS) is shorter: therefore a CS-mount lens can be mounted on a C-mount camera if an ''adapter ring'' (i.e. a distancing cylinder with suitable threads) is placed between them. It is impossible, though, to use a C-mount lens on a CS-mount camera: if you try you will almost certainly break the sensor, scratch the lens, or both. Just because a lens fits a camera, it doesn't mean it can be actually mounted on it!

{| border="1" cellpadding="5" cellspacing="0"
!focal length
!max. aperture
!max. sensor size
!mount type
!maker
!model
!Mpixel
!how many?
!where?
!project
!link to full specifications
|-
|3.5mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|Lambrate
|LURCH
|?
|-
|4.0mm
|f2.0
|1/2"
|C-mount
|Microtron
|FV0420
|YES (B/W only)
|2
|Lambrate
|
|http://www.rapitron.it/obmegpxman1.htm
|-
|4.5mm
|f1.4
|1/2"
|C-mount
|?
|?
|?
|1
|DEI
|
|?
|-
|4.8mm
|f1.8
|2/3"
|C-mount
|Computar
|M0518
|NO
|1
|DEI
|
|http://www.computar.com/cctvprod/computar/mono/048.html
|-
|6mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|Lambrate (?)
|
|?
|-
|6mm
|f1.4
|1/2"
|C-mount
|Goyo
|GMHR26014MCN
|YES
|4
|Lambrate
|2 nell'armadio + 2 scatole vuote
|http://www.goyooptical.com/products/industrial/hrmegapixel.html
|-
|8mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|DEI
|
|?
|-
|8mm
|f1.4
|2/3"
|C-mount
|Goyo
|GMHR38014MCN
|YES
|2
|Lambrate
|
|http://www.goyooptical.com/products/industrial/hrmegapixel.html
|-
|8.5mm
|f1.3
|2/3"
|C-mount
|Computar
|?
|?
|2
|DEI
|
|(old model)
|-
|12mm
|f1.8
|2/3"
|C-mount
|?
|?
|?
|2
|1 Lambrate + ? DEI
|
|
|-
|12mm
|f1.4
|2/3"
|C-mount
|Goyo
|GMHR31214MCN
|YES
|2
|Lambrate
|
|http://www.goyooptical.com/products/industrial/hrmegapixel.html
|-
|15mm
|f2.0
|2/3"
|C-mount
|Microtron
|FV1520
|YES
|1
|Lambrate
|
|http://www.rapitron.it/obmegpxman1.htm
|-
|6-15mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|Lambrate
|
|?
|-
|12.5-75mm
|f1.8
|?
|C-mount
|?
|?
|?
|1
|DEI
|
|?
|}
 

===M12 lenses===
We also use M12 lenses. These lenses are very simple, with no iris, and very small. Their mounting system is an M12x0.5 metric screw thread. They are commonly used for webcams, and usually do not provide the top optical quality.

{| border="1" cellpadding="5" cellspacing="0"
!focal length
!max. aperture
!max. sensor size
!mount type
!maker
!model
!Mpixel
!how many?
!where?
!project
!link to full specifications
|-
|2.1mm
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2042
|NO
|6
|
1 e' a bovisa nelle mani di marcello

1 e' a lambrate su un giano riusato come robowii

1 e' a bovisa sulla frontale del triskar recam

1 e' in mano a martino per fare una frontale => 06.05.09 E' in bovisa montata sul triskar #3

1 l'ha Davide Migliore per acquisizioni monoslam

1 e' sulla testa omnidir di rabbiati

Domenicogsorrenti 04.05.09
|MRT midsize, robowii, monoslam
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|4.3mm, no IR filter
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2046
|NO
|1
|Lambrate (1/1)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|4.3mm
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2043
|NO
|3
|Bovisa (1/3), Lambrate (2/3)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|8mm
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2044
|NO
|1
|Lambrate (1/1)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|}
 

==Frame grabbers==
As previously said, a '''frame grabber''' is an electronic board that connects to one or more cameras, and converts the signals from the cameras into a data stream that can be elaborated by a computer. They are usually designed as expansion boards to be fitted into the computer case. Frame grabbers are necessary for ''analogue cameras'' (as they include the analogue/digital converters) or for CameraLink digital cameras (in this case the frame grabber is essentially a high speed dedicated digital interface). Other kinds of digital cameras don't need a frame grabber: this is one of the main advantages of digital cameras over analogue ones in machine vision applications, where the processing is almost always performed by computers.
In the AIRLab two models of frame grabber are available:
*a digital frame grabber from Euresys, model Expert 2, having two CameraLink inputs (http://www.euresys.com/Products/grablink/GrablinkSeries.asp). ''Notes: needs a PCI-X slot; one of the inputs is not working due to a fault.''
*two multichannel analogue frame grabbers from Matrox, model Meteor II/Multi-Channel, having three analogue inputs that can be combined into a single three-channel RGB analogue input (http://www.matrox.com/imaging/support/old_products/home.cfm). ''Note: one item is permanently mounted on the MO.RO.1 robot: see [[The MO.RO. family]] for details.''
*two multichannel analogue frame grabbers from Matrox, model Meteor II/Multi-Channel, having three analogue inputs that can be combined into a single three-channel RGB analogue input (http://www.matrox.com/imaging/support/old_products/home.cfm). ''Note: one item is permanently mounted on the MO.RO.1 robot: see [[The MO.RO. family]] for details.''
*two single-channel analogue frame grabbers from Matrox, models Meteor and Meteor Pro (http://www.matrox.com/imaging/support/old_products/home.cfm).
All the frame grabbers (except the one on the MO.RO.1) are currently in AIRLab/DEI. If you move one of them, please '''write it down here'''... and do it NOW!

==Mirrors==
Much work has been done and is being done at the AIRLab on the topic of '''omnidirectional (machine) vision''' (sometimes referred to as ''omnivision''). Omnidirectional vision systems use special hardware to overcome the limitations of conventional vision systems in terms of field of view. The approach to this problem that we generally adopt is the use of conventional cameras in association with convex '''mirrors''', i.e. the capturing of the image reflected by a suitably-shaped mirror with a camera. The possibility of designing mirrors with specific geometric properties gives a very useful means to control the geometric behaviour of the whole camera+mirror system.

TODO for someone who knows better ;-) : mirror list

==Cable==
The complete list of cable for camera connection and/or power is under construction. You can partecipate listing below which cables are you using...

{| border="1" cellpadding="5" cellspacing="0"
!Type
!length
!how many?
!where?
!project
|-
|FireWire 6-6
|?
|2
|Bicocca (refer to Domenico G. Sorrenti, 2009-11-11)
|?
|-
|FireWire 6-6
|?
|1
|on LURCH wheelchair
|LURCH
|}

Roomba - vacuuming robots

2011-09-29T11:33:41Z

DavideRizzi:

Roomba is a low-cost robot produced by [http://www.irobot.it/ iRobot].
It is intended to be a commercial cleaning robot, however with little to no modification it can become a powerful educational/hobbyist robotics platform.
[[Image:Roomba_1.JPG|right|Roomba 560]]

=== Sensors & Actuators ===
The Roomba comes with these basic sensors:
# Four IR based cliff sensors
# Two bump sensors
# One wall sensor
# A top mounted IR sensor. Used by Virtual Walls, Docking Station, and Remote Control
# One Dirt Detector (acoustic impact). Some Roombas have two.

The Roomba is sold commercially as a mobile vacuum cleaner, thus it also has these actuators:
# Two wheels drive with differential drive
# One main brush motor
# A side brush motor
# A Vacuum motor.

=== Communication protocol ===

The Roomba proprietary Serial Command Interface is available here: [http://www.irobot.lv/uploaded_files/File/iRobot_Roomba_500_Open_Interface_Spec.pdf iRobot Roomba Open Interface (OI) Specification].

=== Hacking the Roomba ===

To interface with the Roomba Serial Port you need a USB - Serial adapter (for 0-5V signals, NOT RS232 levels!). You can find the schematics and the PCB layout of such an adapter here: [http://airwiki.elet.polimi.it/mediawiki/index.php/Useful_Circuits#USB_-_Serial_adapter_.28iRobot_Roomba_variant.29 USB - Serial adapter (iRobot Roomba variant)]

You can also find other schematics on net as well as ready to use cables: [http://blog.makezine.com/archive/2006/02/how_to_make_a_roomba_seri.html Roomba-serial], [http://todbot.com/blog/2006/07/19/roombongle-a-roomba-usb-dongle/#more-119 Roomba-USB] or [http://blog.makezine.com/archive/2006/02/how_to_roomba_bluetooth_i.html Roomba-bluetooth].

=== Schedule ===

If you need to move a Roomba from the lab, you should first ask to [[User:AndreaBonarini| Andrea Bonarini]], and then fill in the table below.

{| border="1"
! ID !! Test !! Notes !! Where/Who !! Project
|-
| #1 || OK || || AIRLab ||
|-
| #2 || OK || || AIRLab ||
|-
| #3 || Collaudato (Matteo) || || AIRLab ||
|-
| #4 || OK || || AIRLab ||
|-
| #5 || KO (bumper) || || AIRLab ||
|-
| #6 || KO (bumper)|| || AIRLab ||
|-
| #7 || KO (alimentazione)|| || AIRLab ||
|-
| #8 || Collaudato (Simone)|| || AIRLab ||
|-
| #9 || Collaudato (Martino) || White recharger borrowed || AIRLab||
|}

== See also ==

[[Disassembling_a_Roomba_560 | Disassembling a Roomba 560]]

[[Roomba_project | Roomba project]] - A wall following application showing the functioning of Roomba exploiting Pyro software interface.

== External links ==

[http://www.robotreviews.com/chat/viewforum.php?f=4 Roomba Hacking Forum]

[http://www.irobot.com iRobot USA]

Roomba - vacuuming robots

2011-05-02T13:14:02Z

DavideRizzi: /* Schedule */

Roomba is a low-cost robot produced by [http://www.irobot.it/ iRobot].
It is intended to be a commercial cleaning robot, however with little to no modification it can become a powerful educational/hobbyist robotics platform.
[[Image:Roomba_1.JPG|right|Roomba 560]]

=== Sensors & Actuators ===
The Roomba comes with these basic sensors:
# Four IR based cliff sensors
# Two bump sensors
# One wall sensor
# A top mounted IR sensor. Used by Virtual Walls, Docking Station, and Remote Control
# One Dirt Detector (acoustic impact). Some Roombas have two.

The Roomba is sold commercially as a mobile vacuum cleaner, thus it also has these actuators:
# Two wheels drive with differential drive
# One main brush motor
# A side brush motor
# A Vacuum motor.

=== Communication protocol ===

The Roomba proprietary Serial Command Interface is available here: [http://www.irobot.lv/uploaded_files/File/iRobot_Roomba_500_Open_Interface_Spec.pdf iRobot Roomba Open Interface (OI) Specification].

=== Hacking the Roomba ===

To interface with the Roomba Serial Port you need a USB - Serial adapter (for 0-5V signals, NOT RS232 levels!). You can find the schematics and the PCB layout of such an adapter here: [http://airwiki.elet.polimi.it/mediawiki/index.php/Useful_Circuits#USB_-_Serial_adapter_.28iRobot_Roomba_variant.29 USB - Serial adapter (iRobot Roomba variant)]

You can also find other schematics on net as well as ready to use cables: [http://blog.makezine.com/archive/2006/02/how_to_make_a_roomba_seri.html Roomba-serial], [http://todbot.com/blog/2006/07/19/roombongle-a-roomba-usb-dongle/#more-119 Roomba-USB] or [http://blog.makezine.com/archive/2006/02/how_to_roomba_bluetooth_i.html Roomba-bluetooth].

=== Schedule ===

If you need to move a Roomba from the lab, you should first ask to [[User:AndreaBonarini| Andrea Bonarini]], and then fill in the table below.

{| border="1"
! ID !! Test !! Notes !! Where/Who !! Project
|-
| #1 || OK || || AIRLab ||
|-
| #2 || OK || || AIRLab ||
|-
| #3 || Collaudato (Matteo) || || AIRLab ||
|-
| #4 || OK || + Batteria roomba #6 || Mohammed Ali ||
|-
| #5 || KO (bumper) || || AIRLab ||
|-
| #6 || KO (bumper)|| || AIRLab ||
|-
| #7 || KO (alimentazione)|| || AIRLab ||
|-
| #8 || Collaudato (Simone)|| || AIRLab ||
|-
| #9 || Collaudato (Martino) || White recharger borrowed || AIRLab||
|}

== See also ==

[[Disassembling_a_Roomba_560 | Disassembling a Roomba 560]]

[[Roomba_project | Roomba project]] - A wall following application showing the functioning of Roomba exploiting Pyro software interface.

== External links ==

[http://www.robotreviews.com/chat/viewforum.php?f=4 Roomba Hacking Forum]

[http://www.irobot.com iRobot USA]

Cameras, lenses and mirrors

2010-05-12T15:19:56Z

DavideRizzi:

==IMPORTANT NOTES==
'''Never touch the sensor element (CCD or CMOS) of a camera with anything!''' It can very easily be scratched.

'''Never touch the glass elements of a lens with your hands!''' The oil from human skin will cause damage.

==Cameras==
In the AIRLab you can find different kind of cameras. These are the main groups:
*'''Analogue cameras'''. Video output is given as an electrical signal, which needs analogue-to-digital conversion to be processed by a computer; this is done by a specific card called ''frame grabber'' or ''video capture card'' (the latter tend to be the lowest-performance items; see [[Cameras, lenses and mirrors#Frame grabbers]] for details). Analogue video is outdated for computer vision and robotics applications, due to its cost, low performance and complexity; nowadays digital camera systems (such as all the ones listed below) are always preferred.
*'''USB cameras'''. Usually very cheap, they are suitable for low-performance applications (i.e. those where low frame rate is needed and low image quality can be accepted). Their main advantage (along with cost) is the fact that every modern computer has USB ports. The fact that the USB standard includes 5V DC power supply lines helps simplifying camera design and use.
*'''FireWire cameras'''. The FireWire (or IEEE1394) bus is generally used for low-end industrial cameras, i.e. devices with technical characteristics much superior to those typical of USB cameras but low-performance according to typical machine vision standards. Industrial cameras usually give to the user a much wider control over the acquisition parameters compared to consumer cameras, and therefore they are usually preferred in robotics; their downside is the higher cost. There are different versions of IEE1394 link (see http://en.wikipedia.org/wiki/Firewire for details), with different bitrates, starting from the 400Mbit/s FireWire 400. Generally they are all considered superior to USB 2.0, even if theoretical bandwidth is lower for FireWire 400. Firewire ports can include power supply lines, but some interfaces (and in particular those on portable computers) omit them. Although the use of FireWire interfaces has expanded in recent years, they are not yet considered a standard feature for motherboards.
*'''GigE Vision cameras'''. GigE Vision (or Gigabit Ethernet Vision) is a rather new connection standard for machine vision, based upon the established Ethernet protocol in its Gigabit (i.e. 1000Mbps) version. It is very interesting, as complex multiple-camera systems can be easily built using existing (Gigabit) Ethernet hardware, such as cables and switches. Vision data is acquired simply through a generic Ethernet port, commonly found on motherboards or easily added. However, 100Mbps (or ''fast Ethernet'') ports are not guaranteed to work and can sustain only modest video streams; on the other hand, 1000Mbps ports are now standard on motherboards, so this will not be a problem anymore in a few years. It seems that GigE Vision is becoming the most common interface for low- to medium-performance industrial cameras.
*'''CameraLink cameras'''. Cameralink is a high-speed interface expressly developed for high-performance machine vision applications. It is a point-to-point link, i.e. a CameraLink connection is used to connect a single camera to a digital acquisition card (''frame grabber''). Its diffusion is limited to applications where extreme frame rates ''and'' resolutions are needed, because CameraLink gear is very expensive.
*'''ST Camera boards'''. Cameras with cell phone sensor and ARM processor for onboard computation.

The following is a list of the cameras available in the AIRLab. (To be precise, it is a list of the cameras that are modern enough to be useful.) For each of them the main specifications (and a link to the full specifications) are given. Details on the different types of lens mount are given below in [[Cameras, lenses and mirrors#Lenses]]. The 'how many?' field tells if multiple, identical items are available. Finally, the 'where?' field tells you in which of the AIRLab sites (listed in [[The Labs]]) you can find an item, and the 'project' field is used to specify which project (if any) is using it.

Ah, one last thing. People like to actually ''find'' things when they look for them, so '''don't forget to update the table when you move something away from its current location'''. If you don't know where you are taking it, just put your name in the table.

==List of Cameras==
{| border="1" cellpadding="5" cellspacing="0"
!resolution
!B/W, color
!max. frame rate
!sensor size
!interface
!maker
!model
!lens mount
!how many?
!where?
!project
!link to full specifications and/or manuals
|-
|1628x1236
|B/W
|24fps
|1/1.8"
|CameraLink
|Hitachi
|KP-F200CL
|C-mount
|1
|DEI
|
|[[media:KP-F200-Op_Manual.pdf]]
|-
|752x480
|color
|70fps
|1/3"
|GigE
|Prosilica
|GC750C
|C-mount
|3
|Lambrate (1/3), [[User:SimoneTognetti| Simone Tognetti]](from 19/05/2009, dal 14/12/2009 sono impiegate per esperimenti Affective nell'Airlab del DEI)(2/3)
|Driving companions (2/3)
|http://www.prosilica.com/products/gc_series.html
|-
|659x493
|color
|90fps
|1/3"
|GigE
|Prosilica
|GC650C
|C-mount
|1
|???
|???
|http://www.prosilica.com/products/gc_series.html
|-
|1024x768
|color
|30fps
|1/3"
|GigE
|Prosilica
|GC1020C
|C-mount
|2
|Lambrate (2/2)
|RAWSEEDS (1/2)
|http://www.prosilica.com/products/gc_series.html
|-
|CCIR (625 lines)
|B/W
|CCIR (50fps, interlaced)
|2/3"
|analogue
|Sony
|XC-ST70CE
|C-mount
|2
|DEI (2/2)
|
|[[media:XCST70E_manual.pdf]]
|-
|659x494
|color
|30fps
|1/4"
|FireWire 400
|Unibrain
|Fire-i 400 industrial
|C-mount
|3
|Lambrate (3/3)
|RAWSEEDS (3/3)
|http://www.unibrain.com/Products/VisionImg/Fire_i_400_Industrial.htm
|-
|659x494
|color
|30fps
|1/4"
|FireWire 400
|Unibrain
|Fire-i board camera
|proprietary
|8
|Lambrate (3/8), Bovisa (2/8), [[User:PaoloCalloni]] (1/8), [[User:DavideMigliore]] (1/8), [[User:CristianoAlessandro]] (1/8),

presa 1 a fine febbraio10 con lente wide (quella di riserva di robocom), montaggio "a la rizzi" con lastrine di plexiglass e pezzo di profilato item [[User:Domenicogsorrenti]] (1/8)
|RAWSEEDS (2/8), MRT (?/8)
queste sono quelle "nuove"? se si una e' su rabbiati, portiere di mrt, sin da cuvio, e' nella testa omnidir Domenicogsorrenti 21.04.09

1 nuova e' la frontale di recam

1 nuova sulla testa omnidir di ridan

|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|640x480
|color
|30fps
|1/4"
|FireWire 400
|Unibrain
|Fire-i digital camera
|fixed optics (4.3mm, f2.0)
|4
|
1 e' sulla testa omnidir di rigo

1 e' sulla testa omnidir di recam

1 e' sulla testa omnidir mrt05-03 (armadio domenico@unimib)

1 e' sulla testa omnidir mrt05-04 (armadio domenico@unimib)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_DC.htm
|-
|640x480 dual sensor, 9cm baseline
|color
|30fps
|1/3"
|FireWire 400
|Videre Design
|STOC stereo-on-a-chip stereo camera
|C-mount, fitted with two 3.5mm, f1.6, 1/2" lenses
|1
|Lambrate => li lin office => Domenicogsorrenti 13.01.09 => giulio fontana 23.01.09
|
|http://www.videredesign.com/vision/stoc.htm
|-
|640x480
|color
|60fps
|1/3"
|FireWire 400
|Videre Design
|DCSG (associated with STOC)
|C-mount, fitted with one 3.5mm, f1.6, 1/2" lens
|1
|Lambrate
|
|http://www.videredesign.com/vision/dcsg.htm
|-
|?
|color
|30 fps
|1/3.8 inch optical format
|?
|ST Microelectronics
|ST1-Cam + ST2-Cam
|integrated
|2
|ST1-Cam (STLCam (ST LEGO Camera)) [[User:AnilKoyuncu| Anil Koyuncu]], ST2-Cam [[User:LorenzoConsolaro | Lorenzo Consolaro]] and [[User:DarioCecchetto | Dario Cecchetto]]
|ST1-Cam [[RunBot: a Robogame Robot]]
| [[Media:Cameradatasheet.pdf]],‎[[Media:Rvs-v1-0.pdf‎]], [[Media:RVS_Datasheet_v2.1.pdf‎]] ,http://www.danielecaltabiano.com/wwme/ST-SW/st-sw.htm
|-
|?
|color
|?
|?
|?
|ST Microelectronics
|ST5-CamMic + ST6-CamMic
|integrated with microphone
|2
|ST5-CamMic [[User:AndreaBonarini| Andrea Bonarini]], ST6-CamMic [[User:GiulioFiscella|Giulio Fiscella]] [[User:FedericoSem|Federico Sem]]
|ST6-CamMic [[Face detection]]
|
|-
|?
|color
|?
|?
|?
|ST Microelectronics
|ST4-DC (Demo board)
|integrated
|1
|[[User:RaffaelePetta|Raffaele Petta]]
|
|
|}
 

==Lenses==
Be aware that sensor dimension (i.e. its diagonal, measured in fractions of an inch) is ''not'' the same for all cameras. Therefore one of the key specifications for a lens is the maximum sensor dimension supported. If you use a given lens with too big a sensor, the edges of the image will be black as they lie outside the circle of the projected image. Also beware of the strange convention used for sensor diagonals, i.e. a fraction in the form A/B" where A and B are integer ''or non-integer'' numbers. For instance an 1/2" sensor is smaller than an 1/1.8" one.
The variability of sensor dimensions has another side effect: the same lens has a different angle of view if you change the sensor size. Therefore the same lens can behave as a wide-angle with a large sensor and as a telephoto with a small sensor.

An useful guide to lenses (in Italian or English) can be found at http://www.rapitron.it/guidaob.htm.

The following is a list of the actual lenses available in the AIRLab. For each of them the main specifications (and a link to the maker's or vendor's page for full specifications) are given. A '?' means an unknown parameter: if you know its value or experimentally find out it when using the lens (e.g. the maximum sensor size), please ''update the table'' before the information is lost again! Lenses having 'M12x0.5' in Column 'mount type' are only usable with Unibrain's Fire-i board cameras. A 'YES' in the 'Mpixel' column indicates a so-called ''Megapixel lens'', i.e. a high quality, low-distortion lens designed for high-resolution industrial cameras (typically having large sensors); please note that some of these are specifically designed for B/W (i.e. black and white) cameras. The 'how many?' field tells if multiple, identical items are available. Finally, the 'where?' field tells you in which of the AIRLab sites (listed in [[The Labs]]) you can find an item, and the 'project' field is used to specify which project (if any) is using it.

Ah, one last thing. People like to actually ''find'' things when they look for them, so '''don't forget to update the table when you move something away from its current location'''. If you don't know where you are bringing it, just put your name in the table.

===C-mount and CS-mount lenses===
Industrial cameras usually have interchangeable lenses. This allows for the choice of the lens that is more suitable to the considered application. There are two main standards for industrial camera lenses: '''C-mount''' and '''CS-mount'''. Both are screw-type mounts. CS-mount is simply a modified C-mount where the distance between the back of the lens and the sensor element (CCD or CMOS) is shorter: therefore a CS-mount lens can be mounted on a C-mount camera if an ''adapter ring'' (i.e. a distancing cylinder with suitable threads) is placed between them. It is impossible, though, to use a C-mount lens on a CS-mount camera: if you try you will almost certainly break the sensor, scratch the lens, or both. Just because a lens fits a camera, it doesn't mean it can be actually mounted on it!

{| border="1" cellpadding="5" cellspacing="0"
!focal length
!max. aperture
!max. sensor size
!mount type
!maker
!model
!Mpixel
!how many?
!where?
!project
!link to full specifications
|-
|3.5mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|Lambrate
|LURCH
|?
|-
|4.0mm
|f2.0
|1/2"
|C-mount
|Microtron
|FV0420
|YES (B/W only)
|2
|Lambrate
|
|http://www.rapitron.it/obmegpxman1.htm
|-
|4.5mm
|f1.4
|1/2"
|C-mount
|?
|?
|?
|1
|DEI
|
|?
|-
|4.8mm
|f1.8
|2/3"
|C-mount
|Computar
|M0518
|NO
|1
|DEI
|
|http://www.computar.com/cctvprod/computar/mono/048.html
|-
|6mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|Lambrate (?)
|
|?
|-
|6mm
|f1.4
|1/2"
|C-mount
|Goyo
|GMHR26014MCN
|YES
|4
|Lambrate
|2 nell'armadio + 2 scatole vuote
|http://www.goyooptical.com/products/industrial/hrmegapixel.html
|-
|8mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|DEI
|
|?
|-
|8mm
|f1.4
|2/3"
|C-mount
|Goyo
|GMHR38014MCN
|YES
|2
|Lambrate
|Only 1...
|http://www.goyooptical.com/products/industrial/hrmegapixel.html
|-
|8.5mm
|f1.3
|2/3"
|C-mount
|Computar
|?
|?
|2
|DEI
|
|(old model)
|-
|12mm
|f1.8
|2/3"
|C-mount
|?
|?
|?
|2
|1 Lambrate + ? DEI
|
|
|-
|12mm
|f1.4
|2/3"
|C-mount
|Goyo
|GMHR31214MCN
|YES
|2
|Lambrate
|
|http://www.goyooptical.com/products/industrial/hrmegapixel.html
|-
|15mm
|f2.0
|2/3"
|C-mount
|Microtron
|FV1520
|YES
|1
|Lambrate
|
|http://www.rapitron.it/obmegpxman1.htm
|-
|6-15mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|Lambrate
|
|?
|-
|12.5-75mm
|f1.8
|?
|C-mount
|?
|?
|?
|1
|DEI
|
|?
|}
 

===M12 lenses===
We also use M12 lenses. These lenses are very simple, with no iris, and very small. Their mounting system is an M12x0.5 metric screw thread. They are commonly used for webcams, and usually do not provide the top optical quality.

{| border="1" cellpadding="5" cellspacing="0"
!focal length
!max. aperture
!max. sensor size
!mount type
!maker
!model
!Mpixel
!how many?
!where?
!project
!link to full specifications
|-
|2.1mm
|f2.0, with IR coating
|1/4"
|M12x0.5
|Unibrain
|2042
|NO
|6
|
1 e' a bovisa nelle mani di marcello

1 e' a lambrate su un giano riusato come robowii

1 e' a bovisa sulla frontale del triskar recam

1 e' in mano a martino per fare una frontale => 06.05.09 E' in bovisa montata sul triskar #3

1 l'ha Davide Migliore per acquisizioni monoslam

1 e' sulla testa omnidir di rabbiati

Domenicogsorrenti 04.05.09
|MRT midsize, robowii, monoslam
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|4.3mm, no IR filter
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2046
|NO
|1
|Lambrate (1/1)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|4.3mm
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2043
|NO
|3
|Bovisa (1/3), Lambrate (2/3)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|8mm
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2044
|NO
|1
|Lambrate (1/1)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|}
 

==Frame grabbers==
As previously said, a '''frame grabber''' is an electronic board that connects to one or more cameras, and converts the signals from the cameras into a data stream that can be elaborated by a computer. They are usually designed as expansion boards to be fitted into the computer case. Frame grabbers are necessary for ''analogue cameras'' (as they include the analogue/digital converters) or for CameraLink digital cameras (in this case the frame grabber is essentially a high speed dedicated digital interface). Other kinds of digital cameras don't need a frame grabber: this is one of the main advantages of digital cameras over analogue ones in machine vision applications, where the processing is almost always performed by computers.
In the AIRLab two models of frame grabber are available:
*a digital frame grabber from Euresys, model Expert 2, having two CameraLink inputs (http://www.euresys.com/Products/grablink/GrablinkSeries.asp). ''Notes: needs a PCI-X slot; one of the inputs is not working due to a fault.''
*two multichannel analogue frame grabbers from Matrox, model Meteor II/Multi-Channel, having three analogue inputs that can be combined into a single three-channel RGB analogue input (http://www.matrox.com/imaging/support/old_products/home.cfm). ''Note: one item is permanently mounted on the MO.RO.1 robot: see [[The MO.RO. family]] for details.''
*two multichannel analogue frame grabbers from Matrox, model Meteor II/Multi-Channel, having three analogue inputs that can be combined into a single three-channel RGB analogue input (http://www.matrox.com/imaging/support/old_products/home.cfm). ''Note: one item is permanently mounted on the MO.RO.1 robot: see [[The MO.RO. family]] for details.''
*two single-channel analogue frame grabbers from Matrox, models Meteor and Meteor Pro (http://www.matrox.com/imaging/support/old_products/home.cfm).
All the frame grabbers (except the one on the MO.RO.1) are currently in AIRLab/DEI. If you move one of them, please '''write it down here'''... and do it NOW!

==Mirrors==
Much work has been done and is being done at the AIRLab on the topic of '''omnidirectional (machine) vision''' (sometimes referred to as ''omnivision''). Omnidirectional vision systems use special hardware to overcome the limitations of conventional vision systems in terms of field of view. The approach to this problem that we generally adopt is the use of conventional cameras in association with convex '''mirrors''', i.e. the capturing of the image reflected by a suitably-shaped mirror with a camera. The possibility of designing mirrors with specific geometric properties gives a very useful means to control the geometric behaviour of the whole camera+mirror system.

TODO for someone who knows better ;-) : mirror list

==Cable==
The complete list of cable for camera connection and/or power is under construction. You can partecipate listing below which cables are you using...

{| border="1" cellpadding="5" cellspacing="0"
!Type
!length
!how many?
!where?
!project
|-
|FireWire 6-6
|?
|2
|Bicocca (refer to Domenico G. Sorrenti, 2009-11-11)
|?
|-
|FireWire 6-6
|?
|1
|on LURCH wheelchair
|LURCH
|}

Cameras, lenses and mirrors

2010-05-12T15:17:00Z

DavideRizzi:

==IMPORTANT NOTES==
'''Never touch the sensor element (CCD or CMOS) of a camera with anything!''' It can very easily be scratched.

'''Never touch the glass elements of a lens with your hands!''' The oil from human skin will cause damage.

==Cameras==
In the AIRLab you can find different kind of cameras. These are the main groups:
*'''Analogue cameras'''. Video output is given as an electrical signal, which needs analogue-to-digital conversion to be processed by a computer; this is done by a specific card called ''frame grabber'' or ''video capture card'' (the latter tend to be the lowest-performance items; see [[Cameras, lenses and mirrors#Frame grabbers]] for details). Analogue video is outdated for computer vision and robotics applications, due to its cost, low performance and complexity; nowadays digital camera systems (such as all the ones listed below) are always preferred.
*'''USB cameras'''. Usually very cheap, they are suitable for low-performance applications (i.e. those where low frame rate is needed and low image quality can be accepted). Their main advantage (along with cost) is the fact that every modern computer has USB ports. The fact that the USB standard includes 5V DC power supply lines helps simplifying camera design and use.
*'''FireWire cameras'''. The FireWire (or IEEE1394) bus is generally used for low-end industrial cameras, i.e. devices with technical characteristics much superior to those typical of USB cameras but low-performance according to typical machine vision standards. Industrial cameras usually give to the user a much wider control over the acquisition parameters compared to consumer cameras, and therefore they are usually preferred in robotics; their downside is the higher cost. There are different versions of IEE1394 link (see http://en.wikipedia.org/wiki/Firewire for details), with different bitrates, starting from the 400Mbit/s FireWire 400. Generally they are all considered superior to USB 2.0, even if theoretical bandwidth is lower for FireWire 400. Firewire ports can include power supply lines, but some interfaces (and in particular those on portable computers) omit them. Although the use of FireWire interfaces has expanded in recent years, they are not yet considered a standard feature for motherboards.
*'''GigE Vision cameras'''. GigE Vision (or Gigabit Ethernet Vision) is a rather new connection standard for machine vision, based upon the established Ethernet protocol in its Gigabit (i.e. 1000Mbps) version. It is very interesting, as complex multiple-camera systems can be easily built using existing (Gigabit) Ethernet hardware, such as cables and switches. Vision data is acquired simply through a generic Ethernet port, commonly found on motherboards or easily added. However, 100Mbps (or ''fast Ethernet'') ports are not guaranteed to work and can sustain only modest video streams; on the other hand, 1000Mbps ports are now standard on motherboards, so this will not be a problem anymore in a few years. It seems that GigE Vision is becoming the most common interface for low- to medium-performance industrial cameras.
*'''CameraLink cameras'''. Cameralink is a high-speed interface expressly developed for high-performance machine vision applications. It is a point-to-point link, i.e. a CameraLink connection is used to connect a single camera to a digital acquisition card (''frame grabber''). Its diffusion is limited to applications where extreme frame rates ''and'' resolutions are needed, because CameraLink gear is very expensive.
*'''ST Camera boards'''. Cameras with cell phone sensor and ARM processor for onboard computation.

The following is a list of the cameras available in the AIRLab. (To be precise, it is a list of the cameras that are modern enough to be useful.) For each of them the main specifications (and a link to the full specifications) are given. Details on the different types of lens mount are given below in [[Cameras, lenses and mirrors#Lenses]]. The 'how many?' field tells if multiple, identical items are available. Finally, the 'where?' field tells you in which of the AIRLab sites (listed in [[The Labs]]) you can find an item, and the 'project' field is used to specify which project (if any) is using it.

Ah, one last thing. People like to actually ''find'' things when they look for them, so '''don't forget to update the table when you move something away from its current location'''. If you don't know where you are taking it, just put your name in the table.

==List of Cameras==
{| border="1" cellpadding="5" cellspacing="0"
!resolution
!B/W, color
!max. frame rate
!sensor size
!interface
!maker
!model
!lens mount
!how many?
!where?
!project
!link to full specifications and/or manuals
|-
|1628x1236
|B/W
|24fps
|1/1.8"
|CameraLink
|Hitachi
|KP-F200CL
|C-mount
|1
|DEI
|
|[[media:KP-F200-Op_Manual.pdf]]
|-
|752x480
|color
|70fps
|1/3"
|GigE
|Prosilica
|GC750C
|C-mount
|3
|Lambrate (1/3), [[User:SimoneTognetti| Simone Tognetti]](from 19/05/2009, dal 14/12/2009 sono impiegate per esperimenti Affective nell'Airlab del DEI)(2/3)
|RAWSEEDS (1/3), Driving companions (2/3)
|http://www.prosilica.com/products/gc_series.html
|-
|659x493
|color
|90fps
|1/3"
|GigE
|Prosilica
|GC650C
|C-mount
|1
|Lambrate
|RAWSEEDS
|http://www.prosilica.com/products/gc_series.html
|-
|1024x768
|color
|30fps
|1/3"
|GigE
|Prosilica
|GC1020C
|C-mount
|2
|Lambrate (2/2)
|RAWSEEDS (2/2)
|http://www.prosilica.com/products/gc_series.html
|-
|CCIR (625 lines)
|B/W
|CCIR (50fps, interlaced)
|2/3"
|analogue
|Sony
|XC-ST70CE
|C-mount
|2
|DEI (2/2)
|
|[[media:XCST70E_manual.pdf]]
|-
|659x494
|color
|30fps
|1/4"
|FireWire 400
|Unibrain
|Fire-i 400 industrial
|C-mount
|3
|Lambrate (3/3)
|RAWSEEDS (3/3)
|http://www.unibrain.com/Products/VisionImg/Fire_i_400_Industrial.htm
|-
|659x494
|color
|30fps
|1/4"
|FireWire 400
|Unibrain
|Fire-i board camera
|proprietary
|8
|Lambrate (3/8), Bovisa (2/8), [[User:PaoloCalloni]] (1/8), [[User:DavideMigliore]] (1/8), [[User:CristianoAlessandro]] (1/8),

presa 1 a fine febbraio10 con lente wide (quella di riserva di robocom), montaggio "a la rizzi" con lastrine di plexiglass e pezzo di profilato item [[User:Domenicogsorrenti]] (1/8)
|RAWSEEDS (2/8), MRT (?/8)
queste sono quelle "nuove"? se si una e' su rabbiati, portiere di mrt, sin da cuvio, e' nella testa omnidir Domenicogsorrenti 21.04.09

1 nuova e' la frontale di recam

1 nuova sulla testa omnidir di ridan

|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|640x480
|color
|30fps
|1/4"
|FireWire 400
|Unibrain
|Fire-i digital camera
|fixed optics (4.3mm, f2.0)
|4
|
1 e' sulla testa omnidir di rigo

1 e' sulla testa omnidir di recam

1 e' sulla testa omnidir mrt05-03 (armadio domenico@unimib)

1 e' sulla testa omnidir mrt05-04 (armadio domenico@unimib)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_DC.htm
|-
|640x480 dual sensor, 9cm baseline
|color
|30fps
|1/3"
|FireWire 400
|Videre Design
|STOC stereo-on-a-chip stereo camera
|C-mount, fitted with two 3.5mm, f1.6, 1/2" lenses
|1
|Lambrate => li lin office => Domenicogsorrenti 13.01.09 => giulio fontana 23.01.09
|
|http://www.videredesign.com/vision/stoc.htm
|-
|640x480
|color
|60fps
|1/3"
|FireWire 400
|Videre Design
|DCSG (associated with STOC)
|C-mount, fitted with one 3.5mm, f1.6, 1/2" lens
|1
|Lambrate
|
|http://www.videredesign.com/vision/dcsg.htm
|-
|?
|color
|30 fps
|1/3.8 inch optical format
|?
|ST Microelectronics
|ST1-Cam + ST2-Cam
|integrated
|2
|ST1-Cam (STLCam (ST LEGO Camera)) [[User:AnilKoyuncu| Anil Koyuncu]], ST2-Cam [[User:LorenzoConsolaro | Lorenzo Consolaro]] and [[User:DarioCecchetto | Dario Cecchetto]]
|ST1-Cam [[RunBot: a Robogame Robot]]
| [[Media:Cameradatasheet.pdf]],‎[[Media:Rvs-v1-0.pdf‎]], [[Media:RVS_Datasheet_v2.1.pdf‎]] ,http://www.danielecaltabiano.com/wwme/ST-SW/st-sw.htm
|-
|?
|color
|?
|?
|?
|ST Microelectronics
|ST5-CamMic + ST6-CamMic
|integrated with microphone
|2
|ST5-CamMic [[User:AndreaBonarini| Andrea Bonarini]], ST6-CamMic [[User:GiulioFiscella|Giulio Fiscella]] [[User:FedericoSem|Federico Sem]]
|ST6-CamMic [[Face detection]]
|
|-
|?
|color
|?
|?
|?
|ST Microelectronics
|ST4-DC (Demo board)
|integrated
|1
|[[User:RaffaelePetta|Raffaele Petta]]
|
|
|}
 

==Lenses==
Be aware that sensor dimension (i.e. its diagonal, measured in fractions of an inch) is ''not'' the same for all cameras. Therefore one of the key specifications for a lens is the maximum sensor dimension supported. If you use a given lens with too big a sensor, the edges of the image will be black as they lie outside the circle of the projected image. Also beware of the strange convention used for sensor diagonals, i.e. a fraction in the form A/B" where A and B are integer ''or non-integer'' numbers. For instance an 1/2" sensor is smaller than an 1/1.8" one.
The variability of sensor dimensions has another side effect: the same lens has a different angle of view if you change the sensor size. Therefore the same lens can behave as a wide-angle with a large sensor and as a telephoto with a small sensor.

An useful guide to lenses (in Italian or English) can be found at http://www.rapitron.it/guidaob.htm.

The following is a list of the actual lenses available in the AIRLab. For each of them the main specifications (and a link to the maker's or vendor's page for full specifications) are given. A '?' means an unknown parameter: if you know its value or experimentally find out it when using the lens (e.g. the maximum sensor size), please ''update the table'' before the information is lost again! Lenses having 'M12x0.5' in Column 'mount type' are only usable with Unibrain's Fire-i board cameras. A 'YES' in the 'Mpixel' column indicates a so-called ''Megapixel lens'', i.e. a high quality, low-distortion lens designed for high-resolution industrial cameras (typically having large sensors); please note that some of these are specifically designed for B/W (i.e. black and white) cameras. The 'how many?' field tells if multiple, identical items are available. Finally, the 'where?' field tells you in which of the AIRLab sites (listed in [[The Labs]]) you can find an item, and the 'project' field is used to specify which project (if any) is using it.

Ah, one last thing. People like to actually ''find'' things when they look for them, so '''don't forget to update the table when you move something away from its current location'''. If you don't know where you are bringing it, just put your name in the table.

===C-mount and CS-mount lenses===
Industrial cameras usually have interchangeable lenses. This allows for the choice of the lens that is more suitable to the considered application. There are two main standards for industrial camera lenses: '''C-mount''' and '''CS-mount'''. Both are screw-type mounts. CS-mount is simply a modified C-mount where the distance between the back of the lens and the sensor element (CCD or CMOS) is shorter: therefore a CS-mount lens can be mounted on a C-mount camera if an ''adapter ring'' (i.e. a distancing cylinder with suitable threads) is placed between them. It is impossible, though, to use a C-mount lens on a CS-mount camera: if you try you will almost certainly break the sensor, scratch the lens, or both. Just because a lens fits a camera, it doesn't mean it can be actually mounted on it!

{| border="1" cellpadding="5" cellspacing="0"
!focal length
!max. aperture
!max. sensor size
!mount type
!maker
!model
!Mpixel
!how many?
!where?
!project
!link to full specifications
|-
|3.5mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|Lambrate
|LURCH
|?
|-
|4.0mm
|f2.0
|1/2"
|C-mount
|Microtron
|FV0420
|YES (B/W only)
|2
|Lambrate
|
|http://www.rapitron.it/obmegpxman1.htm
|-
|4.5mm
|f1.4
|1/2"
|C-mount
|?
|?
|?
|1
|DEI
|
|?
|-
|4.8mm
|f1.8
|2/3"
|C-mount
|Computar
|M0518
|NO
|1
|DEI
|
|http://www.computar.com/cctvprod/computar/mono/048.html
|-
|6mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|Lambrate (?)
|
|?
|-
|6mm
|f1.4
|1/2"
|C-mount
|Goyo
|GMHR26014MCN
|YES
|4
|Lambrate
|2 nell'armadio + 2 scatole vuote
|http://www.goyooptical.com/products/industrial/hrmegapixel.html
|-
|8mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|DEI
|
|?
|-
|8mm
|f1.4
|2/3"
|C-mount
|Goyo
|GMHR38014MCN
|YES
|2
|Lambrate
|Only 1...
|http://www.goyooptical.com/products/industrial/hrmegapixel.html
|-
|8.5mm
|f1.3
|2/3"
|C-mount
|Computar
|?
|?
|2
|DEI
|
|(old model)
|-
|12mm
|f1.8
|2/3"
|C-mount
|?
|?
|?
|2
|1 Lambrate + ? DEI
|
|
|-
|12mm
|f1.4
|2/3"
|C-mount
|Goyo
|GMHR31214MCN
|YES
|2
|Lambrate
|
|http://www.goyooptical.com/products/industrial/hrmegapixel.html
|-
|15mm
|f2.0
|2/3"
|C-mount
|Microtron
|FV1520
|YES
|1
|Lambrate
|
|http://www.rapitron.it/obmegpxman1.htm
|-
|6-15mm
|f1.4
|?
|C-mount
|?
|?
|?
|1
|Lambrate
|
|?
|-
|12.5-75mm
|f1.8
|?
|C-mount
|?
|?
|?
|1
|DEI
|
|?
|}
 

===M12 lenses===
We also use M12 lenses. These lenses are very simple, with no iris, and very small. Their mounting system is an M12x0.5 metric screw thread. They are commonly used for webcams, and usually do not provide the top optical quality.

{| border="1" cellpadding="5" cellspacing="0"
!focal length
!max. aperture
!max. sensor size
!mount type
!maker
!model
!Mpixel
!how many?
!where?
!project
!link to full specifications
|-
|2.1mm
|f2.0, with IR coating
|1/4"
|M12x0.5
|Unibrain
|2042
|NO
|6
|
1 e' a bovisa nelle mani di marcello

1 e' a lambrate su un giano riusato come robowii

1 e' a bovisa sulla frontale del triskar recam

1 e' in mano a martino per fare una frontale => 06.05.09 E' in bovisa montata sul triskar #3

1 l'ha Davide Migliore per acquisizioni monoslam

1 e' sulla testa omnidir di rabbiati

Domenicogsorrenti 04.05.09
|MRT midsize, robowii, monoslam
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|4.3mm, no IR filter
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2046
|NO
|1
|Lambrate (1/1)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|4.3mm
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2043
|NO
|3
|Bovisa (1/3), Lambrate (2/3)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|-
|8mm
|f2.0
|1/4"
|M12x0.5
|Unibrain
|2044
|NO
|1
|Lambrate (1/1)
|
|http://www.unibrain.com/Products/VisionImg/Fire_i_BC.htm
|}
 

==Frame grabbers==
As previously said, a '''frame grabber''' is an electronic board that connects to one or more cameras, and converts the signals from the cameras into a data stream that can be elaborated by a computer. They are usually designed as expansion boards to be fitted into the computer case. Frame grabbers are necessary for ''analogue cameras'' (as they include the analogue/digital converters) or for CameraLink digital cameras (in this case the frame grabber is essentially a high speed dedicated digital interface). Other kinds of digital cameras don't need a frame grabber: this is one of the main advantages of digital cameras over analogue ones in machine vision applications, where the processing is almost always performed by computers.
In the AIRLab two models of frame grabber are available:
*a digital frame grabber from Euresys, model Expert 2, having two CameraLink inputs (http://www.euresys.com/Products/grablink/GrablinkSeries.asp). ''Notes: needs a PCI-X slot; one of the inputs is not working due to a fault.''
*two multichannel analogue frame grabbers from Matrox, model Meteor II/Multi-Channel, having three analogue inputs that can be combined into a single three-channel RGB analogue input (http://www.matrox.com/imaging/support/old_products/home.cfm). ''Note: one item is permanently mounted on the MO.RO.1 robot: see [[The MO.RO. family]] for details.''
*two multichannel analogue frame grabbers from Matrox, model Meteor II/Multi-Channel, having three analogue inputs that can be combined into a single three-channel RGB analogue input (http://www.matrox.com/imaging/support/old_products/home.cfm). ''Note: one item is permanently mounted on the MO.RO.1 robot: see [[The MO.RO. family]] for details.''
*two single-channel analogue frame grabbers from Matrox, models Meteor and Meteor Pro (http://www.matrox.com/imaging/support/old_products/home.cfm).
All the frame grabbers (except the one on the MO.RO.1) are currently in AIRLab/DEI. If you move one of them, please '''write it down here'''... and do it NOW!

==Mirrors==
Much work has been done and is being done at the AIRLab on the topic of '''omnidirectional (machine) vision''' (sometimes referred to as ''omnivision''). Omnidirectional vision systems use special hardware to overcome the limitations of conventional vision systems in terms of field of view. The approach to this problem that we generally adopt is the use of conventional cameras in association with convex '''mirrors''', i.e. the capturing of the image reflected by a suitably-shaped mirror with a camera. The possibility of designing mirrors with specific geometric properties gives a very useful means to control the geometric behaviour of the whole camera+mirror system.

TODO for someone who knows better ;-) : mirror list

==Cable==
The complete list of cable for camera connection and/or power is under construction. You can partecipate listing below which cables are you using...

{| border="1" cellpadding="5" cellspacing="0"
!Type
!length
!how many?
!where?
!project
|-
|FireWire 6-6
|?
|2
|Bicocca (refer to Domenico G. Sorrenti, 2009-11-11)
|?
|-
|FireWire 6-6
|?
|1
|on LURCH wheelchair
|LURCH
|}

AIRLab Repository

2010-03-02T10:57:45Z

DavideRizzi:

AIRLab Repository

2010-03-01T12:36:26Z

DavideRizzi:

AIRLab Repository

2010-03-01T11:05:24Z

DavideRizzi:

AIRLab Repository

2010-03-01T10:59:49Z

DavideRizzi:

AIRLab Repository

2010-03-01T10:49:46Z

DavideRizzi:

AIRLab Repository

2010-02-26T16:59:52Z

DavideRizzi:

[https://svn.ws.dei.polimi.it/airlab/ AIRLab] is a repository containing all the software, hardware projects, thesis, and so on, developed in AIRLab.

== Who & What ==
The repository is particularly addressed to students: they '''must''' deposit all the material produced for their thesis on the repository.
This includes:

* Code (C/C++, Java, Matlab, ...)
* Hardware projects (such as CAD drawings of mechanical parts, schematics, layouts, ...)
* Thesis source (tex, bibliography, pictures, ...)

The only exception consists in large data, such as big movies, datasets, and so on.

== Becoming a member ==
AIRLab is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.ws.dei.polimi.it/airlab/</nowiki>''.

Students who need to work with AIRLab repository should fill the form at https://acme.ws.dei.polimi.it/request_account.plp with their info and put their supervisor in the "DEI responsible" field. They should then ask their supervisor to confirm their account (supervisors, here are [[DEI Subversion Administration#Let users create their own accounts|the instructions for you]]).

== Structure ==
This is a very brief overview of the directory hierarchy of the repository. The root may contain other directories beside the ones listed. Ignore them, if you don't know what they're about.

* '''Thesis''': contains the thesis (text, code, and all the stuff listed above)
** <SurnameName>-<student id> is the directory you must put your stuff in. You must create this directory.

* '''Projects''': contains bigger projects, usually carried on independently from BSc/MSc thesis.

Note: you must adhere to the exact format for your personal directory. The format is:
<pre><Surname and name, in CamelCase http://en.wikipedia.org/wiki/CamelCase>-<6 digits student id></pre>
Please avoid middle names and '''spaces'''.

Example: ''BottazziGiuseppe-123456''

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

AIRLab Repository

2010-02-26T16:55:48Z

DavideRizzi:

[https://svn.ws.dei.polimi.it/airlab/ AIRLab] is a repository containing all the software, hardware projects, thesis, and so on, developed in AIRLab.

== Who & What ==
The repository is particularly addressed to students: they '''must''' deposit all the material produced for their thesis on the repository.
This includes:

* Code (C/C++, Java, Matlab, ...)
* Hardware projects (such as CAD drawings of mechanical parts, schematics, layouts, ...)
* Thesis source (tex, bibliography, pictures, ...)

The only exception consists in large data, such as big movies, datasets, and so on.

== Becoming a member ==
AIRLab is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.ws.dei.polimi.it/airlab/</nowiki>''.

Students who need to work with AIRLab repository should fill the form at https://acme.ws.dei.polimi.it/request_account.plp with their info and put their supervisor in the "DEI responsible" field. They should then ask their supervisor to confirm their account (supervisors, here are [[DEI Subversion Administration#Let users create their own accounts|the instructions for you]]).

== Structure ==
This is a very brief overview of the directory hierarchy of the repository. The root may contain other directories beside the ones listed. Ignore them, if you don't know what they're about.

* '''Thesis''': contains the thesis (text, code, and all the stuff listed above)
** <SurnameName>-<student id> is the directory you must put your stuff in. You must create this directory.

* '''Projects''': contains bigger projects, usually carried on independently from BSc/MSc thesis.

Note: you must adhere to the exact format for your personal directory. The format is:
<Surname and name, in camel case http://en.wikipedia.org/wiki/CamelCase>-<6 digits student id>

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

AIRLab Repository

2010-02-26T16:50:25Z

DavideRizzi:

[https://svn.ws.dei.polimi.it/airlab/ AIRLab] is a repository containing all the software, hardware projects, thesis, and so on, developed in AIRLab.

== Who & What ==
The repository is particularly addressed to students: they '''must''' deposit all the material produced for their thesis on the repository.
This includes:

* Code (C/C++, Java, Matlab, ...)
* Hardware projects (such as CAD drawings of mechanical parts, schematics, layouts, ...)
* Thesis source (tex, bibliography, pictures, ...)

The only exception consists in large data, such as big movies, datasets, and so on.

== Becoming a member ==
AIRLab is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.ws.dei.polimi.it/airlab/</nowiki>''.

Students who need to work with AIRLab repository should fill the form at https://acme.ws.dei.polimi.it/request_account.plp with their info and put their supervisor in the "DEI responsible" field. They should then ask their supervisor to confirm their account (supervisors, here are [[DEI Subversion Administration#Let users create their own accounts|the instructions for you]]).

== Structure ==
This is a very brief overview of the directory hierarchy of the repository. The root may contain other directories beside the ones listed. Ignore them, if you don't know what they're about.

* '''Thesis''': contains the thesis (text, code, and all the stuff listed above)
** <student id>-<NameSurname> is the directory you must put your stuff in. You must create this directory.

* '''Projects''': contains bigger projects, usually carried on independently from BSc/MSc thesis.

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

AIRLab Repository

2010-02-26T16:38:41Z

DavideRizzi:

[https://svn.ws.dei.polimi.it/airlab/ AIRLab] is a repository containing all the software, hardware projects, thesis, and so on, developed in AIRLab.

== Who & What ==
The repository is particularly addressed to students: they '''must''' deposit all the material produced for their thesis on the repository.
This includes:

* Code (C/C++, Java, Matlab, ...)
* Hardware projects (such as CAD drawings of mechanical parts, schematics, layouts, ...)
* Thesis source (tex, bibliography, pictures, ...)

The only exception consists in large data, such as big movies, datasets, and so on.

== Becoming a member ==
AIRLab is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.ws.dei.polimi.it/airlab/</nowiki>''.

Students who need to work with AIRLab repository should fill the form at https://acme.ws.dei.polimi.it/request_account.plp with their info and put their supervisor in the "DEI responsible" field. They should then ask their supervisor to confirm their account (supervisors, here are [[DEI Subversion Administration#Let users create their own accounts|the instructions for you]]).

== Structure ==
This is a very brief overview of the directory hierarchy of the repository. The root may contain other directories beside the ones listed. Ignore them, if you don't know what they're about.

* '''Thesis''': contains the thesis (text, code, and all the stuff listed above)

these directories:
* '''AffectiveComputing''': software for analysis of biological signals for [[BioSignal Analysis]]
* '''Robot''': software used for the control of the robots built to generate different level of stress in users
* '''bci''': software for analysis of EEG used for [[Brain-Computer Interface | Brain-Computer Interfaces]]. There are a common directory and a directory for each person.
** '''common''': contains files and programs that could be useful to others, e.g., Matlab functions to load data. The subdirectory '''java''' contains (as you guessed) Java software, while the subdirectory '''matlab''' contains Matlab scripts and functions.
** There are also directories for each person (or group) working on BCI, named after the persons. The stuff in these directories is "private", i.e., only the owner should modify things there and they may contain work in progress, programs still badly documented or incomplete... These directories are not secret and not intended to be so. Moreover, they are also writable by other users, as the repository doesn't enforce any such policy; but it is slightly rude to modify files on which others are working.
* '''lurch''': software used for the [[LURCH - The autonomous wheelchair | Lurch]] project.

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

AIRLab Repository

2010-02-26T16:34:33Z

DavideRizzi:

[https://svn.ws.dei.polimi.it/airlab/ AIRLab] is a repository containing all the software, hardware projects, thesis, and so on, developed in AIRLab.

== Who & What ==
The repository is particularly addressed to students: they '''must''' deposit all the material produced for their thesis on the repository.
This includes:

* Code (C/C++, Java, Matlab, ...)
* Hardware projects (such as CAD drawings of mechanical parts, schematics, layouts, ...)
* Thesis source (tex, bibliography, pictures, ...)

The only exception consists in large data, such as big movies, datasets, and so on.

== Becoming a member ==
AIRLab is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.ws.dei.polimi.it/airlab/</nowiki>''.

Students who need to work with AIRLab repository should fill the form at https://acme.ws.dei.polimi.it/request_account.plp with their info and put their supervisor in the "DEI responsible" field. They should then ask their supervisor to confirm their account (supervisors, here are [[DEI Subversion Administration#Let users create their own accounts|the instructions for you]]).

== Structure ==

This is a very brief overview of the directory hierarchy of the repository. The root contains these directories:
* '''AffectiveComputing''': software for analysis of biological signals for [[BioSignal Analysis]]
* '''Robot''': software used for the control of the robots built to generate different level of stress in users
* '''bci''': software for analysis of EEG used for [[Brain-Computer Interface | Brain-Computer Interfaces]]. There are a common directory and a directory for each person.
** '''common''': contains files and programs that could be useful to others, e.g., Matlab functions to load data. The subdirectory '''java''' contains (as you guessed) Java software, while the subdirectory '''matlab''' contains Matlab scripts and functions.
** There are also directories for each person (or group) working on BCI, named after the persons. The stuff in these directories is "private", i.e., only the owner should modify things there and they may contain work in progress, programs still badly documented or incomplete... These directories are not secret and not intended to be so. Moreover, they are also writable by other users, as the repository doesn't enforce any such policy; but it is slightly rude to modify files on which others are working.
* '''lurch''': software used for the [[LURCH - The autonomous wheelchair | Lurch]] project.

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

AIRLab Repository

2010-02-26T16:19:23Z

DavideRizzi: New page: [https://svn.ws.dei.polimi.it/airlab/ AIRLab] is a repository containing all the software, hardware projects, thesis, and so on, developed in AIRLab. The repository is particularly address...

[https://svn.ws.dei.polimi.it/airlab/ AIRLab] is a repository containing all the software, hardware projects, thesis, and so on, developed in AIRLab.
The repository is particularly addressed to students: they '''must''' deposit all the material produced for their thesis on the repository:
* Code (C/C++, Java, Matlab, ...)
* Hardware projects (such as CAD drawings of mechanical parts, schematics, layouts, ...)
* Thesis source (tex, bibliography, pictures, ...)

The only exception consists in large data, such as big movies, datasets, and so on.

== Becoming a member ==
AIRLab is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.ws.dei.polimi.it/airlab/</nowiki>''.

Students who need to work with AIRLab repository should fill the form at https://acme.ws.dei.polimi.it/request_account.plp with their info and put their supervisor in the "DEI responsible" field. They should then ask their supervisor to confirm their account (supervisors, here are [[DEI Subversion Administration#Let users create their own accounts|the instructions for you]]).

== Structure ==

This is a very brief overview of the directory hierarchy of the repository. The root contains these directories:
* '''AffectiveComputing''': software for analysis of biological signals for [[BioSignal Analysis]]
* '''Robot''': software used for the control of the robots built to generate different level of stress in users
* '''bci''': software for analysis of EEG used for [[Brain-Computer Interface | Brain-Computer Interfaces]]. There are a common directory and a directory for each person.
** '''common''': contains files and programs that could be useful to others, e.g., Matlab functions to load data. The subdirectory '''java''' contains (as you guessed) Java software, while the subdirectory '''matlab''' contains Matlab scripts and functions.
** There are also directories for each person (or group) working on BCI, named after the persons. The stuff in these directories is "private", i.e., only the owner should modify things there and they may contain work in progress, programs still badly documented or incomplete... These directories are not secret and not intended to be so. Moreover, they are also writable by other users, as the repository doesn't enforce any such policy; but it is slightly rude to modify files on which others are working.
* '''lurch''': software used for the [[LURCH - The autonomous wheelchair | Lurch]] project.

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

Talk:LURCH - The autonomous wheelchair

2009-09-11T14:57:35Z

DavideRizzi:

=D-Link router=
ip: 192.168.0.100 
User: admin 
Pass: pcbricklurch 
WPA2 PSK: pcbricklurch 

==Fixed IPs==
airlab-blackbox 192.168.0.1 
mubuntu 192.168.0.2 
PCBrick-03 192.168.0.3 
PCBrick-05 192.168.0.5 

=Planner=
MSL library soruce + PQP source: [[Media:MSL.zip]]
compiled on Ubuntu 8.10 with gcc 4.3.2

User:DavideRizzi

2008-05-15T12:54:20Z

DavideRizzi: /* Links */

{{UserProf
|firstname=Davide
|lastname=Rizzi
|email=davide(dot)rizzi(at)mail(dot)polimi(dot)it
|researchareas=''
* [[Robotics]]
|photo=MitchBuchannon.jpg
}}

== Who I am? ==
Davide Rizzi

== Links ==
[[Rawseeds]]

Stay tuned for more!

User:DavideRizzi

2008-05-15T11:57:45Z

DavideRizzi:

File:MitchBuchannon.jpg

2008-05-15T11:53:11Z

DavideRizzi: Davide Rizzi

Davide Rizzi