// Delay is approx 0.2us per loop @64Mhz
#define I2CDEV_LOOPS_PER_US 5
#define I2CDEV_LOOPS_PER_MS (1000 * I2CDEV_LOOPS_PER_US)
#define I2CDEV_I2C1_PIN_SDA GPIO_Pin_7
#define I2CDEV_I2C1_PIN_SCL GPIO_Pin_6
#define I2CDEV_NO_MEM_ADDR 0xFF
3D hover with wide FOV optical flow
Re: 3D hover with wide FOV optical flow
I2C2 pins don't appear to be defined in drivers/interface/i2cdev.h.
Re: 3D hover with wide FOV optical flow
In addition, I2C1 and I2C2 seem to be using completely different methods for initialization.
i2cdevResetBusI2c1() vs. I2C_LowLevel_Init(I2Cx). No idea where the latter's coming from.
Edit: Ah, I2C1 init calls I2C_LowLevel_Init too at the end of i2cdevResetBusI2c1(). At a guess, it seems I2C2 support was never finished or refactored and probably needs work. Have you tried appropriating the code for I2C2 initialization/reset? You'll need to define the I2C2 pins as well as they don't seem to be at present.
i2cdevResetBusI2c1() vs. I2C_LowLevel_Init(I2Cx). No idea where the latter's coming from.
Edit: Ah, I2C1 init calls I2C_LowLevel_Init too at the end of i2cdevResetBusI2c1(). At a guess, it seems I2C2 support was never finished or refactored and probably needs work. Have you tried appropriating the code for I2C2 initialization/reset? You'll need to define the I2C2 pins as well as they don't seem to be at present.
Re: 3D hover with wide FOV optical flow
I heard back from Tobias- Apparently the I2C2 initializer is not complete yet. No worries though- I have the 6DOF model which means there are extra pads (from the unpopulated barometer) to which I was able to solder two wires to access I2C1. With that, I got the entire thing up (with my sensors powered by a separate supply) and got an appropriate optical flow response from the motors.
Next step was to power my sensor module from the CF. That didn't work- for some reason when I attach my sensor to either the battery direct or to U8 pins 10 and 11 (node VCOM) the CF does not start properly.
Not to worry- I have lying around a number of 45mAH LiPo cells that weigh about 1.4 grams apiece. So I'll just power my sensor from a separate battery for now. (This is only a prototype...) This will help isolate any motor induced voltage spikes and give a better response.
I should get airborne soon, knock on wood...
Next step was to power my sensor module from the CF. That didn't work- for some reason when I attach my sensor to either the battery direct or to U8 pins 10 and 11 (node VCOM) the CF does not start properly.
Not to worry- I have lying around a number of 45mAH LiPo cells that weigh about 1.4 grams apiece. So I'll just power my sensor from a separate battery for now. (This is only a prototype...) This will help isolate any motor induced voltage spikes and give a better response.
I should get airborne soon, knock on wood...
Re: 3D hover with wide FOV optical flow
Fingers crossed! 
Re: 3D hover with wide FOV optical flow
My guess is that the battery might be depleted and that the PCM kicks in or the Crazyflie shuts it off due to low voltage.
First flight!
Tobias- Thanks for the reply about the power. I haven't tried it yet with a full battery but will do so before making the next iteration.
OK This past Saturday I put it all together and got my first few flights.
Everything is held together with masking tape. (Duct tape is too heavy.) The two wires sticking out on the top-right of the battery form a "power switch" for my sensor that I turn on by plugging in a 0.1" jumper. I know it's ugly.
For the first flights I tried just height control (e.g. "heave control") with the CF attempting to hold pose as horizontal on it's own. The YouTube video here shows two flights, one with the thrust setpoint a bit low and another set higher. So obviously the Kp constant needs to be reduced. But you can hear the motor spin rates changing with height. I think the crash on the second flight was from when the CF snagged the carpet pulling it into a sharp tilt.
(Clarification: The CF is just trying to hold "zero degree" pose, with no optical flow input, so it will drift around horizontally.)
Video: http://www.youtube.com/watch?v=cBxllJ_o ... e=youtu.be
If I can get this far in this short time then further tuning will almost certainly get this to work.
OK This past Saturday I put it all together and got my first few flights.
Everything is held together with masking tape. (Duct tape is too heavy.) The two wires sticking out on the top-right of the battery form a "power switch" for my sensor that I turn on by plugging in a 0.1" jumper. I know it's ugly.
For the first flights I tried just height control (e.g. "heave control") with the CF attempting to hold pose as horizontal on it's own. The YouTube video here shows two flights, one with the thrust setpoint a bit low and another set higher. So obviously the Kp constant needs to be reduced. But you can hear the motor spin rates changing with height. I think the crash on the second flight was from when the CF snagged the carpet pulling it into a sharp tilt.
(Clarification: The CF is just trying to hold "zero degree" pose, with no optical flow input, so it will drift around horizontally.)
Video: http://www.youtube.com/watch?v=cBxllJ_o ... e=youtu.be
If I can get this far in this short time then further tuning will almost certainly get this to work.
Last edited by geof on Mon Feb 03, 2014 4:05 pm, edited 1 time in total.
Re: 3D hover with wide FOV optical flow
Great progress! I'm sure you will get it running pretty soon. Keep up the good work!
Re: 3D hover with wide FOV optical flow
Just a suggestion, but tethering the cf (either to a jig on the ground or to the ceiling) in 3-4 points might be a good idea during these early stages.
You should still see the effects of the algorithm, without crashing and snagging things.
You should still see the effects of the algorithm, without crashing and snagging things.
Re: 3D hover with wide FOV optical flow
OK here is the second iteration:
There is a single square board holding and STM32F4. It talks to four chips mounted in the sideways directions. These are different chips than from the first iteration- these were optimized for light sensitivity so theoretically this will work in a very dark room. The whole assembly weighs about 5.4 grams. The assembly is attached to the CF board using four tiny wires and glue.
So far I have everything talking and I am getting signs of heave (height) response.
There is a single square board holding and STM32F4. It talks to four chips mounted in the sideways directions. These are different chips than from the first iteration- these were optimized for light sensitivity so theoretically this will work in a very dark room. The whole assembly weighs about 5.4 grams. The assembly is attached to the CF board using four tiny wires and glue.
So far I have everything talking and I am getting signs of heave (height) response.
Re: 3D hover with wide FOV optical flow
Bingo! I have some initial results! It took a bit of work but after some tweaking I was able to get half-decent hover.
The entire system actually uses a combination of human operator input and optical flow (actually a variation of it) to navigate. So when the human operator moves the control sticks, rather than directly implementing the command the Crazyflie tries to achieve the effect that the human operator desired. And when the human operator let's go of the sticks, the Crazyflie hovers.
For these experiments I was using an experimental chip we developed that is very sensitive to light. It has two operating modes, one for regular light and one for dim light. I was only using the dim-light mode. So you get the strange effect that if there is too much light (even regular indoor lighting is too much) it won't work. But it can get very dark. The video below shows three flights: The first two show hover and control using just ambient light in the room. The third shows hover in darkness using LEDs mounted on the CF to illuminate the world. The latter demo barely worked.
There is a noise issue in the PCB- I didn't include RC or LC filters after a switching regulator, and so this added a lot of extra noise. I think there is room for about two orders of magnitude improvement. A new PCB is in fab which should address this.
https://www.youtube.com/watch?v=G8S0MYzyJDk
The entire system actually uses a combination of human operator input and optical flow (actually a variation of it) to navigate. So when the human operator moves the control sticks, rather than directly implementing the command the Crazyflie tries to achieve the effect that the human operator desired. And when the human operator let's go of the sticks, the Crazyflie hovers.
For these experiments I was using an experimental chip we developed that is very sensitive to light. It has two operating modes, one for regular light and one for dim light. I was only using the dim-light mode. So you get the strange effect that if there is too much light (even regular indoor lighting is too much) it won't work. But it can get very dark. The video below shows three flights: The first two show hover and control using just ambient light in the room. The third shows hover in darkness using LEDs mounted on the CF to illuminate the world. The latter demo barely worked.
There is a noise issue in the PCB- I didn't include RC or LC filters after a switching regulator, and so this added a lot of extra noise. I think there is room for about two orders of magnitude improvement. A new PCB is in fab which should address this.
https://www.youtube.com/watch?v=G8S0MYzyJDk