MultiWii

BTW here http://www.rcgroups.com/forums/showpost ... ostcount=1
is a port of openpilot to naze32. I will not give it a try when my naze arrives because i fear bricking my naze right away. I guess i will get me a ST-LINK to be on the safe side.....

Unfortunately NAZE32 with sensors on relatively slow I2C bus will never reach performance level of the native OP hardware. If You can afford buying OP CC3D or third party CC3D, just do it.

I doubt that the I2C bus will seriously harm flightperformance.

So long
Kraut Rob

It's be pretty hard to brick a ROM bootloader.

hehe bricking a ROM is really no easy task. Damn, my naze is still on the way ......

TC...rember me?
May I join your project?:)
Have some ideas and yagarto toolchain configured and running...

Yeah. Didn't I tell you to switch to ARM few years ago?
You can send me email at the usual places.

You did,you did:)
Ok,I'll send you my thoughts today.
Maybe with some sourcecode already...

a quick Q about xbee/3dr radio.. it seems not working with baseflight yet? i tried to hook a 3dr like BT.. but doesnt seem working

if it has TTL serial I don't see any reason why it wouldn't work.

I am trying to get the rushduino/minim osd boards to work with the TX/RX out on the naze board. Most of the things like GPS, altitude and the angles work just fine.
But if you arm the copter and the motors start spinning the OSD is not getting a signal to arm and stay's in disarmed mode.
As far as i can tell the armedmode should be on pos 32 in the TX stream as this is the default(#define ARMEDMODE 32 // OK)

Is this different on the naze board or is this data not being sent?

wut?
Is that some old serial protocol?
This stuff uses the new protocol with MSP packets etc.

Hello TC, I am not sure about the protocol. As far as i know the rusduiono osd get it's data form the LCD_TELEMETRY.
As most of the data is displayed correct i presumed it was the same for the naze board. On my crius board it works OK and arms the OSD.
It would be nice to get this working, a minimosd bord is only about $18 and it's using all the existing hardware.

Perhaps time to rewrite rushduino to use proper protocol then.
LCD "telemetry" is not supported on naze as it has a properly functioning serial console where all the settings can be configured.
There's a MSP_STATUS or so in multiwii serial protocol that shows armed status. I don't see a reason why anyone would want to use any other method of getting this info.

Thanks, but It seems the new Rushduino software is already using the new MSP Protocol.
I will check in the Rusduino thread if they know why the naze board does not arm.

a quick question.. it was said beseflight has some problem when using on v-tail ... is it fixed now?

Never had any.
If there's any issues with mixing, you can always calculate your own proper mix using the custom mixer.

where can i find Y6.hex

Try reading the manual.
Mixer is set in console, you don't need to compile anything.

tnx TC, still in MW

Naze32AIO is really cool, just what I'm looking for, next on my wish list is sbus, it's not possible to get cppm from futaba r2008 and i would like to access the other port's and I'm kind a stuck with futaba but if anybody know a small suitcase friendly 8ch cppm system I'm all ear

Hi!
I did some changes (codebase r239) to the althold and implemented the pt1 element thing (viewtopic.php?f=23&t=2624) to support better descent.
I called it harakiri, because i expected my first coding on naze would kill my copter - but it didn't.... Since Naze is coming from Timecop in Japan i called it harakiri - really no offense.
Harakiri01: Didn't work at all - endless loop at the beginning
Harakiri02: I coded without having the Naze, it works but not very good. I already posted that code.
Harakiri03: Good working version
Harakiri03b: Added pt1 element stuff. I post it here.

I included 3 zip files.
1) The source (original r239 and harakiri03b so easy CSdiff can be done, i will not do some github stuff now.)
2) Harakiri03b_Auto.zip Hexfile for all Naze with baro. If you have no MPU you should select this. Some predefined settings (see below)
3) Harakiri03b_MPU.zip Hexfile preconfigured for Naze rev4. So MPU is already selected ("set acc_hardware = 2"). This version is tested on rev4 and works nice.

What is predefined?
looptime = 3000
deadband = 10
yawdeadband = 15
alt_hold_throttle_neutral = 50
acc_lpf_for_velocity = 10
acc_lpf_factor = 100;
minthrottle = 1150
maxthrottle = 1950
Mixer: QUAD X

Installation:
Flash with "Global erase" option and redo acc-calibration in gui. Do your other settings like normal. Powercycle naze before flight.

Hardware:
Put some foam on your baro and shield it from (sun)light. No usable baro function without doing so!

Usage:
When entering althold it will start holding hight and wait for you reaching the middleposition with the throttlestick. THAN it will accept your hightchange commands relative to throttlestickmiddle. You change the speed of rise or fall (ca +-5m/s). Wait for the reaction don't go beserk on the throttlestick until you get a feel for it.

Alt PID tuning:

P: Is the only parameter wich "knows" the targethight. It can lead to oscillation.
I: Is the variometerbrake, it will suppress the oscillations. It makes the air "thicker"-
D: Is the throttleanglecorrection. It will take effect in forward flight and increase the basethrottle with the tiltangle of the copter to compensate a hightdrop in advance.

Cheers

Kraut Rob

so I manage this:

compiling printf.c...
src\printf.c(136): warning: #1293-D: assignment in condition
src\printf.c(146): warning: #1293-D: assignment in condition
linking...
Program Size: Code=59832 RO-data=6448 RW-data=1052 ZI-data=6748
FromELF: creating hex file...
".\obj\baseflight.axf" - 0 Error(s), 9 Warning(s).

guess it's something, will not giveup until I've got sbus running...........

Anders

Hi!

I did another Version. This time it is called 3c because the althold is not altered from the previous version. I put the whole mwii main PID controller to more precise float variables and introduced a proper "delta time". It flies so well and locks so good on my rig i just want to make you take part. Take your normal PIDs and take it for a spin. It will fly like you will expect. Than add "1" to your normal Nick/Roll P Pids and you will see what i mean. LOL STM does that for free! It flies like on steroids. Besides that i included the Spektrum fix so it is based on r240. This flies so ridiculously good i have to post it, sorry .
Just flies/locks better, Althold unchanged good .

Cheers
Kraut Rob

does anyone know if the MMC10 is the rebranded FF?

thx

jy0933 wrote:does anyone know if the MMC10 is the rebranded FF?

thx

I never figured that out since they became too expensive.
From what others said in FF thread on RCG, it is same/mostly same, but schematic for this stuff never appeared, so I didn't bother investigating further. It's still stm32 so its probably just a matter of mapping correct PWM pins and you can use it.

Gimbal wrote:tnx TC, still in MW

Naze32AIO is really cool, just what I'm looking for, next on my wish list is sbus, it's not possible to get cppm from futaba r2008 and i would like to access the other port's and I'm kind a stuck with futaba but if anybody know a small suitcase friendly 8ch cppm system I'm all ear

I am using a FRSky TFR4-B receiver with my Futaba T12FG. Using a single CPPM connection cable - working just fine

Well god for you, FG uses FASST, unfortunately t8j has a different system S-FHSS so they are not compatible
and there is no chance to get CPPM from that system, any way thnx for the tip.
Have looked at S-BUS to PPM converter with 328p(do have working code and layout)
but system on system is not appealing, has an working progress with S-BUS implementation to
Baseflight, just need to get my heading right(started yesterday with Baseflight so i got some homework to do)

Anders

Hi except from Afroflight32 i also got one Abusemark STM32 dev board, tried to get it to work as a FC but after successful flashing Baseflight.hex i got blinking green led but no communication with Naze32 AIO, what did i miss ?

Did you hookup a random sensor board to I2C, add pullups etc? devboard has no sensors on it, and (repeatedly blinking) red/green sequence = panic code for no gyro detected.

Nop just did a dry bench test, the green blink is apr 1sec on off, will try with a GY86, think it has pullups

Hi !

I did a little improvement of the althold. When descending it will not do an initial hight gain anymore. Just a small update. "Harakiri04" has the 03c changes as well. Feel free to test.

Cheers
Kraut Rob

Hi, still doing some tests to get the minimosd working with my naze32 board. Almost everything works now fine, GPS, PID, Altitude and artificial horizon.
But if i arm the motors the osd freezes if i unarm everything works again. I tested this also with the MW-WinGUI all sensors are read correct but if you arm the board everything stops?

Does someone use the FrSKY Telemetry adapter that TC sells, it should have the same problem if you arm the motors?

Disable the "telemetry" feature, then the OSD should work when the copter is armed.

arne wrote:Disable the "telemetry" feature, then the OSD should work when the copter is armed.

Thanks, can't believe it was that simple I spent hours going through the osd code .

Sorry for my spam but i did a further improvement to Harakiri04 so it is called Harakiri04b!
Please read this for installation, tuning, already preset parameters and the "logic" of althold: viewtopic.php?f=23&t=1947&start=110#p28742
I added an nice autolanding feature that is the difference between 04 and 04b.
Function:
You fly in baromode and pull the Throttlestick to the lowest position will engage Autolanding in several automatic steps.
1. Copter will hold hight for 2 seconds
2. Copter will descent with approx 40cm/sec
3. After touchdown copter will disarm itself when motorspeed is on idle for 3 seconds (you will have to re-arm to launch again)
You can stop autolanding by putting the throttlestick up or by turning off althold.
You can use this as an failsave landing just set your rx to the following on signal loss:
Baro & Angle mode on, Nick/Roll/Yaw to middle, Throttlestick down.
Have fun testing !

Cheers
Kraut Rob

Hi Guys, this is my first post here on MultiWii forum.

I need a little info to smooth my path. I've recently loaded up Baseflight firmware on a FreeFlight FCB (which is like a Nase32 Rev2 I think). Converting to Baseflight was fairly straight forward, no real issues encountered.
The board has a BMP085 baro sensor added and I expect I'll be adding a mag sensor very soon (as an aside, I notice Bosch now have the BMP280 baro sensor that is more sensitive than the old one).
Currently I dabbling with a GPS module fitted to the AUX serial input on the unused Ch3/Ch4 servo input pins (RX is CPPM).

A couple of questions about Baseflight, MultiWii GUI and my board...

The GPS is a Ftec FMP04 which uses a MediaTek chipset. The default baudrate seems to be 38400, and I matched Baseflight via CLI and it works sort of. MultiWiiConfig GUI shows the GPS is giving Lat Lon and Alt and SV data. However the GPS indicator box on the GUI does not light up green like the ACC and BARO sensors.
I gather it should show green (active), can anyone suggest a reason or remedy ?

I notice on various posts here and on the Nase32 board thread too that there are references to a CLI setting called 'gps_type =' with values of 0-2. Odd thing is that on my Baseflight FW I can't see a setting for that parameter listed. I only have 'gps_baudrate =' (which I set to 38400). I used the Aftroflight32 Baseflight version 20120726 which I assumed was fairly current. Can someone let me know what the story is in regards to that setting or if I need a different firmware version or fork ?

Last query is about Mag sensors and GPS Return to Home function. I assume that I'd need a Mag sensor fitted for that to work (as GPS is unaware of heading while stationary). Would I be correct ?

Thanks,
Martin

GPS link
http://www.f-tech.com.tw/modules/publis ... p?itemid=5

You need to download latest svn baseflight build (r249 or 250 of this writing) from google code. the firmware posted for download from 201207 is really old). as for gps, good luck! and yes, if it finds gps talking within first second or so, the gps box should light up

Thanks I'm not familiar with the svn system so I'll go and learn up.

Yes I gather you have no interest in GPS control, so I'll ask others about that stuff...

Cheers,
Martin

Loaded r250 OK. Found the gps_type setting now listed via CLI.

I found these notes in github about gps_type
where X=0 if NMEA (no special config), X=1 if UBX (enters ubx binary mode), X=2 if MTK (sets up MTK for 5Hz operation).

Two questions.
Is the github the best place to go to find info about changes between versions and get specific info about Baseflight ?

I noticed that 3 is also listed as value for gps_type in the set list. Is there actually there a valid gps_type = 3 ?

Cheers,
Martin

mr.sneezy wrote:Loaded r250 OK. Found the gps_type setting now listed via CLI.

I found these notes in github about gps_type
where X=0 if NMEA (no special config), X=1 if UBX (enters ubx binary mode), X=2 if MTK (sets up MTK for 5Hz operation).

Two questions.
Is the github the best place to go to find info about changes between versions and get specific info about Baseflight ?

I noticed that 3 is also listed as value for gps_type in the set list. Is there actually there a valid gps_type = 3 ?

Cheers,
Martin

Hi Martin,

the github repo is a 1:1 mirror of the SVN repo. Mr. timecop here still refuses to move over
Right now there are only those 3 config options if you take a look at the GPS init method: https://github.com/multiwii/baseflight/blob/upstream/src/gps.c#L48

If you still have problems/questions I suggest you swing by #multiwii on FreeNode and bug timecop yourself. But I'm sure other folks there will be able to help, too

-- Andy

what did you change?
tc has not much time at the moment.
this is the reason he is quite silent.
are you doing gps related things?
when yes how to get it?

fiendie wrote:
Hi Martin,

the github repo is a 1:1 mirror of the SVN repo. Mr. timecop here still refuses to move over
Right now there are only those 3 config options if you take a look at the GPS init method: https://github.com/multiwii/baseflight/blob/upstream/src/gps.c#L48

If you still have problems/questions I suggest you swing by #multiwii on FreeNode and bug timecop yourself. But I'm sure other folks there will be able to help, too

-- Andy

Thanks Andy. Not sure what FreeNode is
I'd rather not bug TC anyway as GPS is not his interest, but I'm happy that guys here who do use BaseFlight with GPS can chime in.

brm wrote:what did you change?
tc has not much time at the moment.
this is the reason he is quite silent.
are you doing gps related things?
when yes how to get it?

Not sure if the ? was directed at me.

I changed the gps_type in CLI to type 2 for MTK. I verified that the GPS output rate changed from 10Hz to 5Hz, so I guess the GPS is using MTK protocol.
Not sure if 5Hz is better (less serial load perhaps) but since the change to r250 and the gps_type change the GPS indicator box on MultiWii GUI is lighting up green right away now.

My desire for GPS on this Quad is mainly for 'Return To Home' when I loose orientation while flying it. Getting it to fly a course of two or more waypoints would be good eventually for some videoing tasks.
Currently I'm happy to have debugged a switch to Baseflight this weekend and debugged attaching a GPS module I had laying around doing nothing better.

I've not actually flown it today with r250, but it was very nice on the previous old version I had before (July version I think).

Regards,
Martin

mr.sneezy wrote:Thanks Andy. Not sure what FreeNode is
I'd rather not bug TC anyway as GPS is not his interest, but I'm happy that guys here who do use BaseFlight with GPS can chime in.

FreeNode is an IRC (Internet Relay Chat) server where many open source projects maintain channels (chat rooms).
You can join by either using a dedicated client like XChat or mIRC, or by using their web chat: http://webchat.freenode.net/

And you can bug him all day, he loves that ;P

-- Andy

http://youtu.be/tv73kWezRwc
my quad flies not that bad - even with bended motorshafts and the gopro is just taped to the frame.
no vibration absorber inbetween.
should also be a good base for my fpv trials...

yes, the next thing is a safe return to home function.

brm wrote:yes, the next thing is a safe return to home function.

My own aspirations of eventual RTH took a dive today. Powered up the quad and GPS tonight, and no output from the GPS at all. Power is good, data wires fine. I wonder if the firmware in the FMP04 (MTK 3329) is stuffed. Anyone had that happen ?

Guys, I resurrected the FMP04 GPS module (MTK MT3329). I opened up the RF shield and had a poke around. Turns out the battery is stone dead, or at least very nearly at 0.1V on it. I took a punt and shorted it out completely for a few seconds then applied power to the GPS to see if it had any change on the battery voltage (like charging). Nope, no change, but then I noticed the current to the module was pulsing like it used to, and yep now it's sending data again.

So, looks like I need to graft on a 3V lithium cell to restore the battery backup, and being dead or mostly dead may have stopped it working or at least corrupted some settings...
Martin

Hi TC, is there some kind of current consumption estimation implemented for the naze? On arduino there was powermeter but I didn't see this option in the cli or manual
Thanks in advance

There isn't, as there's no reasonable way to calculate that just based on motors spinning.
A feature returning random numbers would make more sense than whatever "poweremeter" is implemented in current 8bit multiwii.

But there's also the option to add a current sensor
Could vbat be modified to do so? Current sensors have voltage output in correspondence with current used ...or am I wrong with that?

There is no reasonable way to add a current sensor, so no.

Ok, thank you