ElphelWiki - User contributions [en]

Talk:Optical tracking system for amateur rockets

2009-05-18T11:33:31Z

LarryLiang: /* Using C-mout adapter with 35-mm lenses */

== CPU-controlled H-bridges ==
Did you consider using camera CPU to control H-bridges? With 10369 board you can use any of i2c or usb to control the motors. There are several GP I/O going directly to the FPGA available, so you can flip those bits by software initially and then add some FPGA module (i.e. PWM) so these outputs will be run w/o CPU overhead.

It is also possible to design custom extension board to sit right on the 10353 board - in that case you have all the 12 FPGA I/O available (still it is better leave 2 of them for i2c that is used to read board identification EEPROM

We have some un-populated 10369 boards that you may use for prototyping.--[[User:Andrey.filippov|Andrey.filippov]] 17:47, 12 March 2009 (CDT)

-------------------
Hi Andrey,

Sure, using the camera CPU and FPGA can be the ultimate goal in integration.
But I have some concerns about the real-time capability of the CPU running
a general purpose Linux.

I'm the most capable member of the team concerning hardware and low-level
software and I must admit I'm a little afraid by the idea of developing FPGA
code, it's something I've never done. And, in the same time, it is quite tempting!

About the 10 FPGA available GPIO, it may be just enough because we need :
- 2 x 2 inputs for motor quadrature decoders,
- 2 x 3 outputs for H-bridge driving (PWM, 2 enables 1 for each half bridge)
and, in this case, I make the assumption the GND is available as a common output pin.

Well, while writing this comment, I must admit your proposition seems to be the way
to go.
First step would be full software handling, but meaning driver development for quadrature
decoder.
Then little by little replacing software modules by FPGA module.

I'll discuss about this solution with the team.

So after discussion and some mail exchange with Alexandre,
we will use the FPGA and implement some functionnalities by hard :
- the PWM generation
- the quadrature decoders for position and speed
- may be the PID filter but later...

--[[User:TRoll|TRoll]] 10:43:33, 2009-03-14 (CDT)

== One motor or two motors? ==

How about just use one motor other than 2 motor? it seems only the tilt movement is critical for tracking, pan movement maybe not necessary for this application. and the burden of micro controller can be half.

Larry Liang

Hi Larry,

well, due to the zoom level (field of view is about 1.5° x 2°), it is needed to track the rocket on both axes.
For a rocket at 1 km, this means a picture of about 26 m x 35 m,
whereas the total excursion is 2000 m high and several kilometres on side if under parachute.

--[[User:TRoll|TRoll]]

An FOV of 2X1.5 deg. means a 160mm lens, it could be quite long and heavy. Larry--[[User:LarryLiang|LarryLiang]] 06:27, 24 April 2009 (CDT)

Hi Larry,

In fact, we will use a 70mm lens (ie FoV about of 5.2x4 deg) with a numeric zoom, ie only a part of CMOS and not the full CMOS.

--[[User:Keops_Leader|Keops Leader]]

== Using C-mout adapter with 35-mm lenses ==

For longer focal length - did you try any of the 35mm lenses with a [http://www.astrovid.com/products.php?subcat=86 C-mount adapter]? I think you can get better image quality than using x2 extender--[[User:Andrey.filippov|Andrey.filippov]] 08:37, 13 May 2009 (CDT)

Hi Andrey,

For obtaining an equivalent mount of < 1/2" sensor + 70 mm lens +/- X2 extender >,
we should use a 380 mm lens for a '35mm'(24x36) sensor,
ie. if we want the same FoV, we should have the mount : < 1/2" sensor + C-mount adapter(C-'35mm') + 380 mm lens +/- X2 extender(in C or '35mm' format) >
For a same resolution, this mount has a better quality, it's true,
but it's really too expensive and too heavy. Julien
--[[User:Keops Leader|Keops Leader]] 13:35, 13 May 2009 (CDT)

----
Julien, these adapters do not have any lenses inside, so they do not change the focal length. If you would like to have the "equivalent" of 70*2=140mm for C-mount camera - well, you just need a 35mm f=140mm lens. If you use some popular in France 35mm lens mount - you may easily try different lenses that either you or your friends have --[[User:Andrey.filippov|Andrey.filippov]] 15:27, 13 May 2009 (CDT)

Ok, Andrey, I did not understand the first time the adapter was not a lens.
I agree, it's a good idea and a 140 mm of '35mm' mount should not be too expensive.
--[[User:Keops Leader|Keops Leader]] 08:22, 14 May 2009 (CDT)

The varifocal lens which you are using maybe not a good choice: the image is too soft, lots detail lost. maybe you can try fujinon's 75mm 5 megapixel lens( It should be affordable for this project), it can generate much better image than the existing one. of course, some 35mm lens (with C mount adaptor) is another feasible approach. however, 35 mm lens has lower resolution compared some high resolution 2/3 lens. to compensate such drawback, you may need a much larger Zoom, I mean, maybe 300mm. it could be quite long.--[[User:LarryLiang|LarryLiang]] 06:33, 18 May 2009 (CDT)

Talk:Optical tracking system for amateur rockets

2009-04-24T11:27:36Z

LarryLiang:

Did you consider using camera CPU to control H-bridges? With 10369 board you can use any of i2c or usb to control the motors. There are several GP I/O going directly to the FPGA available, so you can flip those bits by software initially and then add some FPGA module (i.e. PWM) so these outputs will be run w/o CPU overhead.

It is also possible to design custom extension board to sit right on the 10353 board - in that case you have all the 12 FPGA I/O available (still it is better leave 2 of them for i2c that is used to read board identification EEPROM

We have some un-populated 10369 boards that you may use for prototyping.--[[User:Andrey.filippov|Andrey.filippov]] 17:47, 12 March 2009 (CDT)

-------------------
Hi Andrey,

Sure, using the camera CPU and FPGA can be the ultimate goal in integration.
But I have some concerns about the real-time capability of the CPU running
a general purpose Linux.

I'm the most capable member of the team concerning hardware and low-level
software and I must admit I'm a little afraid by the idea of developing FPGA
code, it's something I've never done. And, in the same time, it is quite tempting!

About the 10 FPGA available GPIO, it may be just enough because we need :
- 2 x 2 inputs for motor quadrature decoders,
- 2 x 3 outputs for H-bridge driving (PWM, 2 enables 1 for each half bridge)
and, in this case, I make the assumption the GND is available as a common output pin.

Well, while writing this comment, I must admit your proposition seems to be the way
to go.
First step would be full software handling, but meaning driver development for quadrature
decoder.
Then little by little replacing software modules by FPGA module.

I'll discuss about this solution with the team.

So after discussion and some mail exchange with Alexandre,
we will use the FPGA and implement some functionnalities by hard :
- the PWM generation
- the quadrature decoders for position and speed
- may be the PID filter but later...

--[[User:TRoll|TRoll]] 10:43:33, 2009-03-14 (CDT)

How about just use one motor other than 2 motor? it seems only the tilt movement is critical for tracking, pan movement maybe not necessary for this application. and the burden of micro controller can be half.

Larry Liang

Hi Larry,

well, due to the zoom level (field of view is about 1.5° x 2°), it is needed to track the rocket on both axes.
For a rocket at 1 km, this means a picture of about 26 m x 35 m,
whereas the total excursion is 2000 m high and several kilometres on side if under parachute.

--[[User:TRoll|TRoll]]

An FOV of 2X1.5 deg. means a 160mm lens, it could be quite long and heavy. Larry--[[User:LarryLiang|LarryLiang]] 06:27, 24 April 2009 (CDT)

Talk:Optical tracking system for amateur rockets

2009-04-18T12:15:21Z

LarryLiang:

Did you consider using camera CPU to control H-bridges? With 10369 board you can use any of i2c or usb to control the motors. There are several GP I/O going directly to the FPGA available, so you can flip those bits by software initially and then add some FPGA module (i.e. PWM) so these outputs will be run w/o CPU overhead.

It is also possible to design custom extension board to sit right on the 10353 board - in that case you have all the 12 FPGA I/O available (still it is better leave 2 of them for i2c that is used to read board identification EEPROM

We have some un-populated 10369 boards that you may use for prototyping.--[[User:Andrey.filippov|Andrey.filippov]] 17:47, 12 March 2009 (CDT)

-------------------
Hi Andrey,

Sure, using the camera CPU and FPGA can be the ultimate goal in integration.
But I have some concerns about the real-time capability of the CPU running
a general purpose Linux.

I'm the most capable member of the team concerning hardware and low-level
software and I must admit I'm a little afraid by the idea of developing FPGA
code, it's something I've never done. And, in the same time, it is quite tempting!

About the 10 FPGA available GPIO, it may be just enough because we need :
- 2 x 2 inputs for motor quadrature decoders,
- 2 x 3 outputs for H-bridge driving (PWM, 2 enables 1 for each half bridge)
and, in this case, I make the assumption the GND is available as a common output pin.

Well, while writing this comment, I must admit your proposition seems to be the way
to go.
First step would be full software handling, but meaning driver development for quadrature
decoder.
Then little by little replacing software modules by FPGA module.

I'll discuss about this solution with the team.

--[[User:TRoll|TRoll]] 10:43:33, 2009-03-14 (CDT)

How about just use one motor other than 2 motor? it seems only the tilt movement is critical for tracking, pan movement maybe not necessary for this application. and the burden of micro controller can be half.

Larry Liang