Having recently become aware of Boris B's custom version of Cleanflight known as Betaflight, I decided to update my Acro Naze32 I made this decision after seeing so much positive feedback from others on rcgroups, Facebook and YouTube.
My notes here explain some of the problems I had to overcome before successfully upgrading to Betaflight. Some of the issues are really minor and might seem obvious to others but at times I was almost going to give up thinking I'd just try out Cleanflight 1.10RC3.
The first hurdle came about after somehow I managed to do an incomplete / corrupt firmware update and the Naze32 board become unresponsive (couldn't connect via the Configurator app). The good news was that I read the boot loader is stored in ROM and "the Naze32 board can't be bricked". I read plenty of posts where people explained how to just connect the two physical boot loader pads on the board and re-flash. Shorting pads on any PCB is a risk if you aren't confident which ones to do so just to be clear, owners of the Afroflight Naze32 ver 5 board here's a picture of the boot loader pads.
I found it easy to solder a lead in place rather than try and hold two pins in place while simultaneously plugging in the micro usb connector and go through the firmware flash. Once the board has booted with the boot loader pads shorted, set a couple of options in Clenflight Configurator;
And flash to ver 1.9.
The next issue I had was trying to use the "Load Local Firmware" button in Configurator. I kept getting error messages to the effect of corrupt or invalid file and "Loaded bytes" would show zero. I hadn't followed the directions properly to download the file from GitHub. I was right clicking on the Naze Betaflight hex file to download it. The problem was I hadn't clicked through to the screen that shows the "RAW" option.
Naze32 Hex files right location to download from. From that screen the hex file will download properly.
After finally uploading Betaflight and connecting via Configurator I could configure my board. My next big issue was that the motors would not spin up at all even though I could see the RC input tab and motors output tab showing all the right signs. If I disconnected the LiPo battery and kept the board powered by USB, I found on reconnecting the LiPo would activate the motors but with two problems 1) they wouldn't disarm ever and 2) full throttle on the input stick translated to maybe 50% output on the motors. Eventually I realised that I had BLHeli version 13.xx on the Afro 12A ESCs and Betaflight needs version 14.xx. No big deal unless like me you've soldered the signal pins directly to the board. At this point though I'd invested too much effort to be deterred. After de-soldering all the signal wires and updating BLHeli to the most current version, I'm happy to report a fully functioning board with Betaflight firmware.
I haven't had a chance to actually fly it yet so that feedback will be next.
As a side note, while I had the soldering iron out, I took the time to run a couple of wires to the VBAT pins. This lets me use the audible beeper and the programmable LED strip to warn of low voltage levels. A handy backup in case I forget to connect the LiPo alarm to the battery before each flight.
I need to activate PPM input to the Naze32 board from the Orangerx UHF running OpenLRSng. PPM input is needed so I can use RC5 pin to control some WS2812 addressable LEDs.
The solution process:
In the Cleanflight configurator, enable RX_PPM. Connect the receiver Port 6 output to the RC input pin 1 of the Naze32 board. The problem is when I do that, and switch on the transmitter (ie the PPM stream is presented to the Naze32 input), the Naze 32 seems to lag horribly. Connecting it to the configurator takes ages for the screen to refresh.
I found disabling Telemetry in the openLRSng options for the orangerx Tx module seemed to fix the problem of the Naze32 board lagging. Now I can use the RC5 pin on the Naze32 board to control the addressable LEDs (WS2812).
The only remaining issue is that appears after arming once, then disarming, I can't re-arm with completely removing power from the Naze32.
Problem: Trying to update the OpenLRSng firmware to version 3.8 failed to due error message "PSP Command Not recognised" after trying to connect the USB to serial adapter to the Tx module
Solution: Flashed the Tx module with the bootloader via the Arduino IDE and USBasp. On doing this I was getting another error message "AVRDUDE: Warning: cannot set SCK period". After trying driver / firmware updates to the USBasp and not being able to solve this error message, i found it didn't really matter after trying a firmware update to 3.8 and it worked anyway!
Google Map resolution isn't good enough.
Fit a downward facing GoPro camera to Phantom Fx-61 Flying wing, fly circuits with the GoPro taking still images photos every two seconds or so, post process in AgiSoft PhotoScan.
The advantage of creating a map stitched together from still photos as a 3D model means it can be rotated and viewed from any angle. The example below was created from a very quick flight and not even with a pre-programmed flight path. I mostly just flew manual circuits so credit due to the powerful software processing.
This image shows a zoomed in section of this map using Google Earth viewer. The low resolution makes it difficult to make out the details.
The same section but from the custom made map shows a lot more detail.
Trying to use the openLRSng Configurator app and connect to my OrangeRx Open LRS 433MHz Transmitter 1W just wouldn't connect and keeps reporting the error "Start message not received within 10 seconds, disconnecting"
- Connect your 3.3V FTDI USB to serial adapter to the pins inside the Tx module. At a minimum you need Gnd <-> Gnd, Tx <->Rx, Rx<->Tx connected.
- Make sure the Vcc pin is disconnected.
- Install the Tx module in your transmitter. I'm using a Taranis.
- With the transmitter turned off, advance the throttle to half. This stops power to the Tx module*.
- In the , openLRSng Configurator app enable the auto-connect check box next to "Connect".
- Turn the Tx turned on.
- Plug in the USB to serial FTDI.
- Wait until you see "Serial port successfully opened with ID: #"
- Pull the throttle down so the Tx initialises.
- There should be a couple of beeps and the configurator continues to connect.
Now you can configure your openLRSng Tx and Rx modules all via the Google Chrome Configurator and even use the Spectrum Analyser function.
* I'm not sure if other transmitter brands have the feature where power isn't applied to the Tx module until the throttle is at zero. I found the timing was important between connecting the USB and activating the Tx. With the Taranis it seemed to be much easier by having the Transmitter in the on state but with throttle up, as soon as the "connecting" message appeared, pull the throttle and it connected.
I did manage to connect without using the throttle up trick but only once and I couldn't get it to do it again. I read a post on rcgroups where a guy said it took him 20 tries before it would connect.
Trying to flash the Hobbyking OrangeRX Open LRS 433MHz Transmitter 1W ( JR Compatible) with openLRS produced the error "avrdude: stk500():not in sync: resp=0x00" in the Arduino IDE.
Buy a 3.3V USBAsp board and following the guide here, flash the bootloader to the board. Once the bootloader was installed, the openLRS firmware uploaded without any errors.
Following the guide here;
I'm making a camera capable of taking near-infrared photos. The theory being that with some image processing, a photo taken with an NDVI camera can show where plants / vegetation is growing well compared to where it's not growing so well.
The hardest part involves taking a camera apart, removing the infrared filter and putting it all back together in a working state. A couple of cheapy cameras off eBay help with the practice. I destroyed the first camera but go the second going ok. Here's a photo of the camera in pieces and the image sensor.
The photos below show "normal", "near infrared" and "NDVI" versions of the same photo;
The on screen display (OSD) characters from the Hobbyking Minim OSD v1.1 appear garbled.
With the latest release of the OpenPilot software version 14.01 come two new features (among others) that when combined, make flipping and rolling a multirotor (MR) even easier. A new flight mode called "Rattitude" is a hybrid of the self levelling "Attitude" and the more aerobatic 'Rate' mode. In "Rattitude" mode as the control stick on the transmitter moves out from the centre, the flight mode of the craft changes from 100% Attitude through to 100% Rate with varying degree of mixture in between. The effect means that letting go of the sticks means the MR will return to self levelling (ie Attitude mode) but you can still throw it around as the control sticks move out from centre, you get the aerobatic response of Rate mode.
Normally you would have to flick a switch to go from Attitude to Rate. In Attitude mode, because it's always trying to self level, to maintain forward flight you have to constantly be holding the stick forward. It feels like you're fighting it to a degree for the whole flight. Also Attitude mode limits the maximum angle of pitch and roll so if you try to roll in Attitude mode, you'll roll to the angle defined as the maximum and not go any further around.
In Rate mode, it goes where you point it. If you roll to 45 degrees, the MR will attempt to hold that angle until you tell it otherwise. Rate mode can be intimidating for the novice pilot as the safety net of self levelling is removed and depending on the settings, Rate mode can fill quite 'slippery' if you're not used to it.
The other new feature in 14.01 is Cruise Control which from my limited reading of the topic attempts to maintain a steady altitude when the MR is turning or banking by slightly increasing the rpm to counter the slight decrease in lift). With Cruise Control comes a 'Max Angle' parameter that when set to 90 degrees, combined with Rattitude mode, means that as the MR rolls past 90 degrees, it automatically spins down the motors. That means the part of the roll when the MR is passing through the inverted (ie the props would normally be pulling it to the ground), the motors are automatically shut down which seems to make for a much tighter roll.
From personal experience I went from rolling and flipping with at least 10m height to doing the same at maybe head height. The first time I tried this combination it was quite weird to hear the motors shut down as it passed through the 90 degree vertical point but they came back up a few milliseconds later. Posts in the OpenPilot forum suggest that setting the Cruise Control Max Angle (CCMA) to 80 degrees and the degrees / second to 360 make for some nice smooth rolls.
The screenshots below show captures from the OPenPilot GCS software version 14.01 and the settings required to change to get this to work. I first tried it on my "beater" quad with a CC3D flight controller and liked it so much I put it on my "nice" quad with a Revo FC and Ov3rquad frame. The video below shows the results from these settings on both my CC3D and Revo controlled quads with CCMA set to 90 degrees and the Rate mode "Degrees / second" setting up at around 450-500.
The next thing I want to try is lowering the CCMA to 80 and deg/sec to 360 for the nice, "natural" roll and then go the other way to CCMA = 100 and deg/sec =720. Maybe with these settings I might get in a few double or triple rolls before hitting the ground.
As soon as I engage Altitude hold on my Arducopter Hexacopter, it shoots up instead of holding a nice steady altitude as expected.
My throttle mid-point was not exactly at centre and when I engaged Altitude hold, the throttle stick becomes an altitude adjustment control as opposed to a throttle meaning relative to the centre position, if the stick is up, the Hex will rise. If the stick is below centre, it will fall. I analysed a logfile where I had been hovering in a nice stable position and found my throttle setting to be about 480. I thought this would have been close enough to the default (500) but apparently not because after adjusting THR_MID, the Hex hovered perfectly in position.
These URLs helped me identify and solve the problem: