with PPM
without PPM

Above is zipped logfiles renamed to .jpg save as .zip to view

Subroutine gpsNewFrameNMEA not verifying checksum correct before making changes to GPS_coord[LAT] and GPS_coord[LON] or NOT making changes.

While logging with baseflight I have seen sporadic random dropping of the sign of reported latitude and longitude, verified with WinGUI as a line drawn from ie. -81.3444 to 81.3444 tested with a LS20031 GPS also simulated with SatGenNMEAFree.

Using U-blox U-center in parallel to monitor GPS direct from module does not exhibit the loss of sign.

Tested with SatGenNMEAFree GPS Simulator above issue only occurs if either longitude or latitude monitored is Negative ie South or West.

If the latitude or longitude monitored is either North or East ie positive problem is not seen.

Displayed Raw GPS vs Sent from Naze32 at same time.

set blah=foo

PID defaults are quite different between PID controllers. Multwii has PID controller dependant defaults (EEPROM.cpp https://code.google.com/p/multiwii/source/browse/trunk/MultiWii_shared/EEPROM.cpp#143).

Nothing to see here.

If sonar is enabled, can not connect with configurator until reflash, this is not new with latest version.

If you save a configuration with sonar enabled can no longer connect to configurator until reflash if restored.

Model: VTail4
Enabled features: PPM VBAT SOFTSERIAL GPS POWERMETER

I suggest that

define SPEK_MAX_CHANNEL 7

be replaced with

define SPEK_MAX_CHANNEL 8

in file src/spektrum.c in order to match the number of channels supported between ppm and spektrum (satellite direct connect).

Angle mode not working on pid contoller 1 (not flyable).
it will lock into what ever angle the craft is on when its activated, so failsafe on naze for example kicking in while doing acro flips etc well you get the picture on what will happen.....

TPA not working on Pid controller 1 (it does nothing)

I have made a fork and implemented Smart Port telemetry, it's involves a hardware hack and is only lightly tested so far, but I would like to discuss this with somebody.

code, details, instructions, are on my GitHub, where I forked the original baseflight project

https://github.com/frank26080115/baseflight/
https://github.com/frank26080115/baseflight/wiki

a picture of the hack http://i.imgur.com/jBnxzSu.jpg

a short terrible sounding shaky demo video https://www.youtube.com/watch?v=Mfp7t7hi_TE

Do you like it? Do you think this can be implemented into the master branch? What are the requirements?

In MW 2.3 the specification of MSP changed. From a first fast look I found the following changes:

• the amperage is added to MSP_ANALOG
• headFreeModeHold has been removed from MSP_ATTITUDE

Are there any plans to update to mw 2.3 or should I just create a pull request with the changes I found?

Hi
I have been looking through the PID functions and have found a few things that I would like to ask about.

In pidRewrite() I see this line (~382)...
errorAngle = (constrain(rcCommand[axis] + GPS_angle[axis], -500, +500) - angle[axis] + cfg.angleTrim[axis]) / 10.0f; // 16 bits is ok here
I found the division by 10.0f at the end a bit odd as the rest of the variables (including where the result is placed) are integers. Shouldn't the divisor just be 10?
Also, if the division by 10 is required, wouldn't it be better to do it after it has been multiplied by the constants, so as to lose less resolution?
I'm thinking that it might also be worth doing some rounding before the division as well.

On the same line, I see the constants -500 and +500, used as limits for the setpoint angle. Shouldn't mcfg.max_angle_inclination be used as the limit as it is in the other PID function?

I got to wondering about the division by 10.0f, and when it was added into the code, and it turns out that it was added with commit b32cc09 (25 May 2014) that has this associated comment.
"move code around to fix some gcc error that doesn't occur with real compilers"

In the code this commit replaced, there was no division by 10, and mcfg.max_angle_inclination had been used in place of the constants -500 and 500.

The comment doesn't explain the addition for the division by 10.0f or the replacement of mcfg.max_angle_inclination with the constants either. On my machine at least,
I get no strange gcc warnings, and the original C code doesn't look convoluted enough to cause the compiler to emit any dodgy instructions. Is this what was happening?

I thought I would do a little more digging, and it appears that this line was taken from a different PID function (pidBaseflight) that was first introduced with commit b996b26, which was made before the mcfg.max_angle_inclination setting was added, which probably explains why the constants are used. This other function also used floats rather than integers, which also explains the division by 10.0f.

Anyway, the upshot of this is that I'm wondering if the commit that added this line to pidRewrite was done in error.

I've also had an idea about the calculation of the D term in pidRewrite. I see that at the moment that the D term is determined from changes in RateError, which is determined
from the input variable and also from changes in the setpoint (rcCommand[axis]). What this means is that changes in setpoint (even small changes) will result in a kick in the D term.
Is this what you're after? Changes in setpoint can act a little bit like noise and create an undesirable D term.
What can be done to avoid this is to calculate the D term from changes to the input variable only, and not changes to the error. You can see that if the setpoint is constant,
changes in error have the same value as changes in the process variable, so there would be no difference to the calculate D term if the setpoint is constant.
However, if the D term is calculated from changes in the process variable only, changes in the setpoint will not result in large kicks in the D term.
This is often a good thing, although I'm not sure that's what's needed with a flight controller.
Looking at the code, it seems that this sort of approach might only be useful when in ANGLE mode, which determines the error from the angle[axis] variable (and the stick positions).
Changes in the angle[axis] variable could be used directly rather than changes in the error to determine the D term, leaving rcCommand[axis] out of it.
Anyway, just a thought.

Afro32 CLI version 2.3 Oct 1 2014 / 07:45:46

SONAR needs some idiot-proofness in case pulse missed... ie within its 3 meter usefulness if no response NAZE should not stop processing other routines etc

Enter CLI...
set mag_hardware = 3
save
exit

Then when returning to CLI, the mag_hardware is reset to zero. It should remain at whatever value it was. I couldn't find where in the code it was being reset.

open keil, click build, some errors prevent compilation.

got compiling hex (not verified) by enclosing the following blocks with #ifndef CJMCU

https://github.com/multiwii/baseflight/blob/master/src/main.c#L166-184

https://github.com/multiwii/baseflight/blob/master/src/mw.c#L462-481

When i enable telemetry and then arm the board it freezes completly. Happens since new Firmware (29-sep-2014) this happens even when nothing connected to the battery and telemetry pins.

Steps:
Install on naze32 rev5 board the new FW:
CLI:
feature ppm
mixer quadx
set mincommand = 1000
set minthrottle = 1100
set maxthrottle = 2000
set mincheck = 1020
set maxcheck = 1980
set looptime = 2800
set midrc = 1500
feature motor_stop
feature telemetry
feature vbat
save

The issue is there.

Feature -telemetry
Save

and issue is gone.

So after some testing (big thanks to) @creyc, it seems that the BOXSERVO1, 2, 3, activation boxes are only displayed in custom airplane mode, since the servo mix is much more universal now, i think these boxes should be displayed for every model that support servos? (i am opening this for discussion)

Second (probably more pressing) problem, it seems that the smix isn't "live updated", so even when the data is sent to the FW, changes doesn't apply instantly and require reboot of the FW to take affect, i think this needs some fixing, anyway tell me what you think, you know where to find me.

Would be good to ensure telemetry not sent when MSP is in use, seems to cause mid-air reboot... fun times.

I'm experiencing an issue when I use motor spin when armed (motor_stop off) and the failsafe feature. When motor_stop is on the failsafe cuts output as soon as signal is lost, and the buzzer beeps, but if the motor spin when armed is enabled (motor_stop is off), then the motors stay on for about 10 seconds before shutting off, but the buzzer acts that same as before, so it obviously is in the failsafe state. Surely from a safety perspective the the motors should cut out as soon as the failsafe is invoked regardless of motor spin on armed?

I have tried to use the other adc pins for RSSI analog input but without success.
power_adc_channel is set to 1 in cli ( so pwm rx input channel 2 used as adc in ), but adcGetChannel(mcfg.power_adc_channel) always gives me 0.

Voltage reading works ok. Can't see what's wrong here.

There is what appears to be legacy code which exists because there is a single binary built for the NAZE target which includes all the sensors for all the different revisions of the Afroflight32 board.

From the code it appears that every NAZE board has had each different sensor chip always installed the same way round.

However this then precludes making a NAZE board with the same sensor chip as another board in a different orientation - the user would have to reconfigure the board or the arrow on the silkscreen would have to be printed differently.

The drivers should not have a default alignment for each sensor. They should not call alignSensors(). They should not repeat code.

Perhaps a table of supported hardware with a list of sensors and their orientation is required.

This could also be useful to cut down the code size and memory usage since if the user knows what revision board they have then the drivers used only on old boards do not need to be included in the binary.

Prefer a compile time solution.

Not sure whether one bug or several is useful, but I wanted to capture a few observations with a GPS I installed last night:

1. "GPS time" seems to be reporting system uptime.
2. GPS speed is not sent (was visible in OSD).
3. GPS alt is not sent (was visible in OSD).

Sample (stripped out some unused columns): http://www.sharecsv.com/s/d411516c7c8a65d5d77977b3aac6729e/data.csv

drv_ak8975.c is not defined in Makefile.

Build error after make clean:
/tmp/ccPiv6N7.ltrans1.ltrans.o: In function sensorsAutodetect': /home/ole/workspace/newest/baseflight/.//src/sensors.c:155: undefined reference toak8975detect'
collect2: error: ld returned 1 exit status
make: *** [obj/baseflight_NAZE.elf] Error 1

In the latest release changing the yaw_direction in the Cli has no effect on the Tricopter servo direction. I'm pretty sure this is bug.

Hi all!
Sorry if this is totally wrong place for this. Please remove it if so...
Well, I have a contribution for the baseflight project. It is an implementation of JR Propo's XBus serial receivers. Originally I did implement this by forking the "cleanflight" first and made a PR to that project. Then I started to work on the same contribution, but now for "baseflight" (as they differ a little). It was however not possible to create a new "fork" within GitHub as I had already forked the "cleanflight" (as this is a fork of "baseflight")... :(

So, I created a "copy" manually here on GitHub and did a branch called "xbus" and made a PR to my own repo.

Is it possible to send this to anyone manually as it seems impossible to have two different forks with the same base project as I tried? The private message function has been removed from github a few years ago and hence I thought that maybe I could post this as an issue for this project. Sorry if that was all wrong...

All in all...I am trying to create some kind of "manual pull-request" for this project. Please let me know if I can send this to anyone, or do this in a better way.

My cloned is repo here: https://github.com/GruffyPuffy/baseflight
The branch is called "xbus", there is also a pending PR for inside my repo here:
https://github.com/GruffyPuffy/baseflight/pull/1

Best regards
Stefan

This is more a feature request than an issue.
the mcfg.rssi_aux_channel only works for a ppm channel if PPM is enabled. We can't use channel 2 as pwm input ( this ones remains free to use ) for frsky rssi.

It only works if we use PWM input for radio channels( feature PPM not set ).

I installed LED ring from DF Robot but it not working.
The i2c is ok but LED indication is not .
On the LEdring i got the code for multiwii installed (used it on my crius board).
I check some coding but the code from LEDRING does not mach the code from baseflight for LED pattern selections.
Where can I find the matching ino file for the LEDRing itself working with baseflight?

This issue can be demonstrated in the 2015.02.12 firmware by setting the airplane mixer then changing any servo to 'Rate: -100%' in the servo tab then checking that servo's output in the Motor Testing tab. Expected output is MID setting, but instead getting MIN.

This issue first shows up in the Dev 2014.12.08 build, but was working correctly in Stable 2014.12.04 build.

Detailed and fixed in cleanflight, need backporting, see this commit:

hydra/cleanflight@3ed979e

Not sure if correct here, or at the HW-Vendor.
When connecting HoTT-Telemetry, as described in the Wiki, via a 1N4148 Diode to a SoftSerial-Port (regardless if Serial#1 or Serial#2) the Barometer jumps from 0m to 1000m and Back.

Some stuff here:

http://www.multiwii.com/forum/viewtopic.php?f=23&t=1947&start=800#p50774

The GPS coordinate output to the telemetry seems to be in the form of Decimal Degrees (DDD), where FrSky/OpenTx wants Degrees Decimal Minutes (DMM). Utilizing the DMM output, Companion9x can export directly to Google Earth and the Taranis would properly provide coordinates from the telemetry screens.

The modification of DDD to DMM seems to be a simple call of the proper variables in the Telemetry_FrSky.C code (starting at Line 125). As far as I've researched, standard NMEA messages use DMM and ublox conforms to this standard. This seems to be further corroborated in the ported multiwii code in GPS.C (Line 804) which describes the conversion from DMM to DDD for further GPS functionality.

FrSky's GPS Sensor v2 (without Naze32) was used to verify that DMM provides accurate coordinates to Taranis and telemetry logs.

I want to use sonar but i only have pwm receiver.
In current version I read in the code it only works with PPM receiver.
I want to use the motor 5/6 connection. sonar_pwm56
Why does it not work with pwm receiver on pwm56 ?
I tried to compare with cleanflight code but can not find the solution.
Does anyone has some hints so ican solve it for my setup?

0.52 - firmware 29 Sept 2014 - QuadX - SBus - there is a bug where the Offset of 1004 (needed to arm and achieve full range <1100 - 1500 - >1900 ) is being interpreted as a stick input. Works fine on a normal 6 wire Rx - The default offset for Sbus should be 1004 - but also fix the bug which is not carrying over the 16 points of offset and interpreting neutral stick position 1500 wrongly for Sbus ; resulting in motors winding up asymmetrically in Acro mode on Sbus.

minor: after setting "mixer quadp" and rebooting, the initial setup tab reports "quadx" until disconnect and reconnect, then reports correctly.

Conditions:
pid_controller = 1 (old school pid controller not tested)
horizon mode enabled
flip forwards or backwards

Expected behaviour:
Pitch flip should finish with pitch axis horizon "help"

Observed behaviour:
Roll is mixed into the flip instead of just pitch.

Hello,
There is an issue with tricopters in 3d mode. The only function missing is that the rudder servo needs to reverse when the throttle goes negative. This is because the thrust angle on the rudder motor changes 180 degrees off from what the flight controller expects when the motors reverse. Currently, once a tricopter is inverted it spins uncontrollably.
Thank you for your help!

I like to see support for more than 8 channels.
I realy ok, to have the small solution I show more than once.

This is even more than nothing like now

I've made a fork of baseflight at https://github.com/frank26080115/baseflight/ and I've made changes that will allow for the user to use GPS on softserial, and made each softserial individually configurable.

I use 19200 baud and it seems to work according to the baseflight GUI, that's all the testing I did so far.

What do you think? Something to be added to the master branch someday?

Although the V-Tail Configuration seems to work by swapping the rear motors we should have a separate A-Tail and V-Tail Mixer to allow for completion and ability for configurator to have proper visuals.

I've noticed that mincommand, yaw_control_direction amongst other things don't seem to live update any more. I think this could be related to servo changes, or perhaps some strange behaviour over MSP when using Baseflight Configurator, in any event, I was only able to get yaw_control_direction to change via the Servo's tab in Configurator and certainly not able to calibrate ESCs via mincommand in CLI.

Last git version - QuadX starts rotating after take-off. Rolled back on r466 svn - all fine.

There's enough outputs to do it (10) 2 motors, 6 servo, 2 camera.

See https://github.com/multiwii/baseflight/blob/master/src/mixer.c#L297

However, there is this:

https://github.com/multiwii/baseflight/blob/master/src/mixer.c#L473

It doesn't explain why, and certainly when the code at around 297 is changed to update the servos it means that the airplane servo outputs are overridden with the camera stabilisation values while 2 servo outputs are idle.

The slashes for 'mkdir' fail when running make on a windows machine. In order to fix it on windows (and it should still work on linux), I added the following macro:
ifeq ($(OS),Windows_NT)
MKDIR_OBJDIR = @if not exist $(OBJECT_DIR) mkdir $(subst /,,$(dir $@))
else
MKDIR_OBJDIR = @mkdir -p $(dir $@)
endif

and replaced the three lines (207,213,217) that contain a call to 'mkdir' with the following:
$(MKDIR_OBJDIR)

There are other issues with the makefile on windows but the above changes allow the project to be built.

Sadly, this App doesn´t work with Mac OS 10.10 Beta. Before it was running really well, but for now i can´t connect to my Naze32 running MultiWii.

Is there a fix coming ?

Multiwii 2.2/2.3 MSP_RESET_CONF only resets PIDs. Baseflight resets EVERYTHING with a resetConf() call. Including radio configuration, PID controller, mixer, map, everything. Wouldn't a MSP extension such as MSP_RESET_CONF_ALL be more suitable for "factory reset" vs PID reset for selected pid_controller?

Hello,

I currently use LEDRING, SONAR, LED and BUZZER so all of my channels are filled up. I would like to have RSSI injection on the 9th channel. I can't afford to lose any of the current functionality of the fuctions listed above.

Thanks.

Hello,
there is error in softserial code, fixed here: ledvinap/cleanflight@3b20b74

In my current project, I use baseflight as low-level flight controller. However, for high-level control I use a linux-based platform to do complex math (extended Kalman, etc). Communication to baseflight is via the serial interface. Currently I've modified baseflight to accept a new command, which is RC_CORRECTION to add offsets to the remote control calculated by the high-level controller. It would be nice to implement this command to base flight-master. Or, any other ideas to communicate to baseflight, because serial communication has quite a big latency? If interested, I can share the modification.

Hi. Could You advise please.
Got in Eclipse strange error
section .text' will not fit in regionFLASH'
region `FLASH' overflowed by 20528 bytes

A am new in Eclipse.... (use to MS Visual studio) and can't make hex for my quadr. What should do i?

I read some reports on fpvlab that their naze32 is noisy on the uhf band. I don't have any issues with my naze but it seems to be a thing... would you merge a pull request that allows the user to change the pll setup to increase the system clock from 72 to 80 MHz?