Very nice work on your project!

It sounds like you’ve really got it all under control! Your project sounds really impressive, I can’t wait to hear how it turns out. Doing proper SLAM with a line laser would be incredibly cool (basically LIDAR) and in theory can get you great results for indoor maps. Getting something basic working for stabalisation will probably suffice, especially for indoor flying or such. That’s a really ambitious A2 project you’ve got going! I bet Mr P’s loving it. Good luck again!

I’m writing everything in assembler at the moment. I have tried to find actual information about the cortex m3′s caches, but I really don’t know where to look. I find the SYSTICK timer useful for cycle-counting – but a reasonable amount of it is just guessing.

Unfortunately I cannot just poll the pixel clock line because each poll loop takes at minimum 8 or 9 cycles, which is not fast enough. My approach is to synchronise with the pixel clock line, so that my inline assembler will read each pixel at the centre of the PIXCLK waveform. The synchronisation will occur once before each line. I’m pretty sure that the pixel reading code will take consistently the same amount of time, because I tested it billions of times.

I did not know that interrupts were that responsive on the cortex m3, but using them would still reduce the FPS by a lot. Perhaps I will try them if I can’t get this CPU approach to work.

It is not just one point – it is a line laser pulsed at the exposure time of the camera, and I was thinking more for inside the house – navigating and building maps of walls etc, not a height map (ultrasonic sensors will probably be used for landing/ceiling awareness). But that will be next year!

I have found 3, 3 axis sensors (acc, gyro and magneto), and will probably just try making up some simple stuff to start with (complimentary filters and things) and just improve on that, a PID loop would also be used.

Thanks for your suggestions!

Processing each pixel on the fly seems reasonable. Are you writing the code for that in assembler or C? You might want to think about things like the caching system and how likely your code is to cause cache hits…
I was able to read in one line of data by having an interrupt fire on the HSYNC line and then reading bytes into memory by polling the pixel clock line. Once I’d read an entire line, I had time to do quick processing of it (finding the centre of mass of red pixels on that line) before the next line started, an approach that sounds like it could also work for you. If you’ve got per-pixel processing working well there’s no point changing though. If interrupt latency is being an issue check out the various priority configuration options for the STM32′s interrupts — it’s one of the most configurable and powerful interrupt systems in microchips these days and can probably work with what you need (I think they should be able to work down to just a couple of clock cycles…).

Doing SLAM sounds like fun. Is this laser just facing down, so you build a height map of the terrain you fly over? Trying to do localisation with such a narrow field of view (just one height measurement…) sounds like it might be tricky, though — have you got a proof of concept or a simulation or anything working?

Some of the hardest bits of quadcopters is stabalisation: ideally you need sensor fusion (a Kalman filter or something) with a degree of freedom for, at least, three axis of gyro, magno and accel, and ideally also further DoFs for bias; plus you need control systems to keep the thing level and flying where you want it to go (a tuned PID or such) that work without a human in the loop to correct errors. That’s not easy to do, though it’s a problem other people have solved — are you using (or considered using) things like OpenPilot or Paparazzi for your sensor fusion and control loops? Using their code might let you focus on the (already not trivial) problem of making the thing autonomous.

At any rate it sounds like a very exciting project, good luck!

After days of trying to get the camera to work, I had almost given up. But just out of luck, I reduced the clock speed to 6MHz and now it seems to work perfectly! It’s strange how the ARM can’t seem to output 12MHZ (maybe rise/fall times are too high).

I’m not planning to use DMA, nor to store the image data. Each pixel will be processed on-the-fly (I’m making a laser triangulation depth sensor) – each in exactly 14 cycles. It is a bit risky, because I’m not using a pixel clock to know when the data is valid, but I’ve cycle-timed my processing code block and it is consistently 13 cycles (plus one NOP as a buffer). There will be 752 copies of the code inline (!!!) to process one row. Also the interrupt latency time is far too high and unpredictable to use (I think this is what you used for robot2). The brightest pixel’s position in each column will be stored in the SRAM. Then, when the frame is over, will be converted into depth measurements and sent to the sensor’s host (maybe another ARM chip) for SLAM or something. The camera will be running at about 14FPS so I think the sensor will be good enough for some pretty intelligent robots

I’ve looked into quad-copters and it doesn’t seem too bad, but something will probably crop up (although will hopefully crop back down again safely).

If you have any advice or think you can see any problems I’d gladly absorb it

A 752*480px camera sounds fairly hefty indeed! Are you storing the data coming off it, or trying to process it a line at a time? If you’re storing the data, what on? If you’re clocking it at 12MHz into the STM32 running at 72MHz that really gives you very, very, very few clock cycles to accomplish anything useful, it sounds like you’d really better be using DMA from the GPIO peripheral to stand a chance. Alternatively the new STM32F4 line includes onboard camera peripherals that would interface with many embedded cameras directly, streaming image data into RAM (and have a lot more RAM to boot, too) which might make your life a lot easier!

The Sharp sensors should be fine indoors and are indeed a fairly good way of getting precise small-distance ranges, but an ultrasonic module might be better for distances in the range of a couple of metres — less affected by interference, too.

It sounds like a really cool and ambitious project, I bet Mr P’s excited for it! I’ve toyed with autonomous quads too, and it’s definitely not an easy undertaking. Best of luck! I’d love to hear how it goes.