Difference between revisions of "Talk:Optical tracking system for amateur rockets"

From ElphelWiki
Jump to: navigation, search
Line 32: Line 32:
  
 
I'll discuss about this solution with the team.
 
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)
 
--[[User:TRoll|TRoll]] 10:43:33, 2009-03-14 (CDT)
Line 38: Line 45:
  
 
Larry Liang
 
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]]

Revision as of 06:03, 20 April 2009

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

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

--TRoll