Some time ago I lost interest in the Mikrokopter project due to a set of reasons:

I tried to understand the stabilization settings better. I studied the code and was shocked to see how unreadable and dirty the code (at least of the FC board) was. People already had put lots of effort in cleaning up the code. To my astonishment, this cleaner code was not adopted by the main developers, they obviously did not consider this as important...
Also the implementation of the PID controllers was very hard to understand. Tried to analyze it together with PID controller experts and I just gave up

Some of the navigation code is not available and has severe restrictions for FPV. The official reason is safety, but this is bull as they have published videos where they have a MK travel very long distances. In an open forum discussion the MK-developers where very arrogant.

Almost 2 weeks ago now and I did not mention the BeNeLux (Belgium-Netherlands-Luxemburg) RCAP meeting on my blog...

The weather was good but not excellent. In the morning the sky was blue but in the afternoon it was clouded. As last year, it was a rather windy day.

This was the third edition of the event and what an evolution! The first year all brought planes with a photo-camera. That year I also experimented with my brand new FPV equipment. There was one guy with a home-built tri-copter. I had never seen such a device before...
The next year there where some quadcopters and this year there was one FPV plane and there rest where quadcopters.

Eliminating the screen is already a huge weight-saver. The buttons remain operational. I will need to use a AV RX/TX and a screen on the ground to have feedback.

The weight of the battery is about 20g. If I can power the camera from the flight-battery, i save weight an I no longer need to worry about charging the camera battery. The DC input is 5V, so you can just solder wires on the connector and power the camera from the servo 5V the MK generates.
The video signal is also simple to find. I use the same connector for my FX35 and my 5V FPV camera.

How can I get rid of the trigger servo? The trigger button has 6 pins. Some are ground, one detects half-press, one detects full-press. Just pulling the full-press to ground seems enough.
In theory, one could connect the full-press button to one of the open-collectors of the MK (the ones to drive leds). Because I suspect that this signal is going directly to the camera processor, I decided to introduce an optocoupler, a small relay will also work.
The weight of the camera is now 90g.

Some vibration sources where already eliminated but there are still too much vibrations in the footage. I compared different damping materials that isolate the...Continue Reading

Images

At new year's eve I was thinking: what if I just install my camera on my MK and try to get footage of the fireworks the neighbors traditionally light in abundance? In the last days I installed leds on my MK, so night-flying should be possible...

I prepared all equipment and just after midnight I launched my MK. The flight went well. The resulting video is slightly disappointing. The darker it gets, the more noisy the image as the camera increases sensitivity. It also seems that my latest modification to feed the 12V camera from the main battery (instead of converting it to 5V and boost that to 12V) causes lots of banding, especially when the battery is starting to fade. I will experiment a bit and will possibly reinstall the 5V->12V booster.

After all, the end-result is not too bad. Without any doubt, I will have better equipment to get footage of the fireworks by next year!

I have no experience with heli-flying but I had the MK reasonably well under control, but it takes a lot of concentration. My experience with aeroplanes helps me but it also hinders me. When I fly backwards for example, I have a strong tendency to reverse the controls as the MK comes towards me.

Images

Last Saturday, it was very foggy in the morning.
Not knowing how the video-system would react to the fog, I waited until the tick fog around the airfield was gone before I launched my plane. I was hoping there would still be some fog left to capture... While most of the fog was gone, the visibility was not very good, but I found some low clouds about 1Km away.
It looks like the humidity had a bad influence on the video link.

I bought an Canon MV960 on eBay to record flights. I seem to get about the same compression/image quality as before when I was recording using my laptop with VirtualDub and the MainConcept codec. However, I strongly prefer the new camera setup as it is much easier to setup. Before I would only record once in a while but with the camera I record each flight. It is also good to have some footage in case something goes wrong...

Here is some footage or a recent flight. On the video the windmill of "Captain Zeppos" can be seen. Captain zeppos is a famous Belgian children's television series from the 1960s.

I was testing a new algorithm for my autopilot. So I was flying in the traditional way, without goggles. The video-rx with recorder was at home, 300m away.

When I activated the return-home function nothing happened.... I tried to disengage the autopilot and bring the plane back manually, but the plane did not respond and just flew away and disappeared.

I could no longer see the plane and thought I had lost it. I reactivated the return home but I was thinking that the system had failed and that it would not respond. A few minutes later, while I was explaining to a friend that I had just lost my plane, I could hear a plane above me... It had come back!

When I studied the video-footage of the event, it showed that I had been playing with the switch for the altitude-hold. All the time the Heading-hold function was active (this explains why I could not control the plane). When the plane was out of sight I seem to have used the correct switch and activated the return home...

A made a small video of what happened. The values in the middle of the screen are debug-values.

I am in the process of introducing the actual return-home and heading-hold in the code for the plugon-board.
I decided to make a small simulator. The simulator runs on a PC, get servo-pulse length from the OSD and generates NMEA for the OSD. The coordinates are always the same but the simulator alters the reported heading. It is currently a very basic model of the plane, but it takes into account the latency from the GPS. While the simulator runs, it generates a logfile that can be imported in excel to draw a graph.

In the OSD, I currently have a simple proportional controller. I configured the simulator to simulate drift; when the OSD is not correcting, the plane turns left with 1 degree per second. I wanted to reproduce the issue I had with the older proportional implementation: depending on the wind the autopilot steers too much or too little. And yes, when turning in the direction of the drift, there is almost overshoot, when turning in the other direction, it takes ages.
The heading-hold shows a ripple. In the coming days I will add an integrator and see how this improves things...

Addition May 23th:
I added the integrator and it looks very good now, in the simulator at least...
The deflection of the rudder depends of the direction of the turn because the drift (or wind) facilitates of inhibits the turn.
Let's see if it behaves equally well in a real situation...

Periodically I get the question if I can provide my software for the BlackBoxCamera boards. As there is no short answer to this question and as there is a lot of confusion, I decided to place a comprehensive answer here, so that I can point to this message each time I get this question.

The BlackBoardCamera board comes standard with a 16F628 PIC. I can provide a hex file for a 16F648 PIC that fits in the same socket.
Here are a few important remarks:
- it only works on the OLD boards that have a STV5730 OSD chip. BlackBoxCamera now sells new boards with a MAXIM OSD. Unfortunately my software is not compatible with these new boards. Perhaps it is possible to find second-hand boards …
- This is a version that displays ground-speed, heading, altitude, flight-time, climb-indicator, north-indicator and pilot-indicator (distance and direction). If does not contain features like rudder-home or failsafe-detection.
- I use a Haicom GPS. Several people have tested with the popular EM406 GPS. For GPS devices that output RS232 levels or low TTL levels (<4V), the board must have a DS275 chip or you must add some other circuit to adapt the signal levels. Possibly it also works with other GPS devices at generate NMEA messages at 4800baud but there are no guarantees.

I finally found some time to work on my idea to have multiple switches on one channel to control my OSD.

I want different switches with distinct functions:
- a 3-state switch that controls how many details are displayed
- a 3-state switch that activates heading hold or rudder-home
- a switch that activates altitude-hold
- a push-button

I made a small video: the OSD runs a special test-application that shows low-level information and the decoded positions (2 switches with 4 possible positions and 2 switches with 2 positions). The idea is that these switches should have specific functions. The camera points to the transmitter where the switches are installed.
I now use 2 3-position switches and 2 2-position switches. Instead of these 3-position switches I could use 4-position ones but I did not find any.

I am still struggling a bit with the transmitted signal that is somehow disturbing the system. When I remove the antenna it all goes well but with the TX antenna installed there is sometimes important jitter on the channel. I need to investigate if it is the PIC or the potentiometer that gets into trouble. Any hints are very welcome, I have very little experience with this...