Naze32 hardware discussion thread

alu · Post by **alu** » Sun Oct 13, 2013 1:45 pm

Hi,

maybe someone can help me with some issue. A couple of weeks ago I was able to compile and flash source code to my rev5 board successfully.
Now I updated my repository and everything is still compiling, but when I flash the board, it does not react to or do anything except blinking (blue always on, red and green alternating).

Any hints on why I can no longer flash my own code?

timecop · Post by **timecop** » Sun Oct 13, 2013 1:55 pm

red and green alternating = gyro not found = you either screwed up I2C code or broke hardware.
Did you touch 5V pad to 3.3V when shorting bootloader?

alu · Post by **alu** » Sun Oct 13, 2013 2:03 pm

Thats a little odd.
I re-flashed your last official baseflight.hex (September 4th, had to shorten bootloader) and this one is working, so hardware should be fine.
Also I did not modify code.

However, I am using a different toolchain/setup, which might be the reason, although I thought I had this one figured out as it was working a couple of weeks ago...

timecop · Post by **timecop** » Sun Oct 13, 2013 2:15 pm

For GCC, I would suggest using latest gcc-arm-embedded (https://launchpad.net/gcc-arm-embedded/+download)
Everyone who's developing on this code uses latest build of it. I, and a few other people use keil (currently 4.7 or 5.0)
These 2 configurations (keil/gcc-arm-emb) get a lot of testing, other toolchains/compilers might not generate good code etc.
You can try changing -Os to -O3 or -O2 in Makefile if your gcc sucks.

pacajeff · Post by **pacajeff** » Sun Oct 13, 2013 2:36 pm

@Crashpilot1000, subaru4wd, teslahed: many thanks for your replies and advices ! Things are more clear for me now !
I'll will try LOS flights first with the BT module to tune PIDs.
I was already thinking of using KVOSD after that. It's a nice firmware for MinimOSD.

My quad is ready to receive the board... Matter of days I hope ! I'll keep you inform !
Thanks !

alu · Post by **alu** » Sun Oct 13, 2013 4:28 pm

Thanks for the hint, but it seems like I'm getting the same result with gcc-arm-embedded.
I'm not using Keil, though, since I'm working under Linux.

timecop · Post by **timecop** » Sun Oct 13, 2013 4:35 pm

Well, you can always diff the revision you pulled from SVN with your code and see where the problem is?
Or play with -O options, though this has only been problem with older gcc-arm-embedded or codesuckery toolchains.

brm · Post by **brm** » Sun Oct 13, 2013 5:19 pm

timecop wrote:For GCC, I would suggest using latest gcc-arm-embedded (https://launchpad.net/gcc-arm-embedded/+download)
Everyone who's developing on this code uses latest build of it. I, and a few other people use keil (currently 4.7 or 5.0)
These 2 configurations (keil/gcc-arm-emb) get a lot of testing, other toolchains/compilers might not generate good code etc.
You can try changing -Os to -O3 or -O2 in Makefile if your gcc sucks.

ha - o3 Ends up with a compiler cegmentation error issue

Code: Select all

-Ilib/CMSIS/CM3/DeviceSupport/ST/STM32F10x src/sensors.c -o obj/src/sensors.o
src/sensors.c: In function 'ACC_getADC':
src/sensors.c:316:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [obj/src/sensors.o] Error 1

i use the latest from launchpad :mrgreen:

teslahed · Post by **teslahed** » Sun Oct 13, 2013 5:44 pm

I've just been trying the latest naze32 dev code (i think) R429

It flies great, acro is nice and smooth and auto-level works nicely too (not that i use it :-D

)

I can't get the barometer to work. I've tried accelerometer hardware set to 0, 1 and 2 and it doesn't seem to make a difference. I've set it to come on when i flip an auxillary switch but nothing happens when i use it. Is there anything i'm missing?

alu · Post by **alu** » Sun Oct 13, 2013 8:07 pm

Seems like my eclipse mixed up the PATH entries of different tools chains (summon arm tools, codesourcery and GNUArm) and managed to produce some bastard .hex or something that does not run properly.
However, now that this is fixed, everything is back to working status.
Sorry, my bad.

I've got one question concerning the new alignment: It looks like the orientation takes place in a horizontal plane. But what if I want to rotate my board in another plane (let the arrow on the board point into the air).
Is this not possible anymore?

Plus, I don't understand why there is a setting for each sensor. Don't they have to be always set to the same value?

timecop · Post by **timecop** » Mon Oct 14, 2013 1:08 am

Told you the problem was GCC.

Yes, new rotation only works in flat plane. It's (always been) intended for different hardware orientation on PCB, and not for rotating the board. This is why each sensor is individually allowed to rotate, because due to routing or other reasons, they don't all point into same direction when mounted.

The proper way to handle vertical board mounting would be to rotating final sensor output vector...(which isn't implemented, feel free to patch

alu · Post by **alu** » Mon Oct 14, 2013 11:30 pm

I think rev438 srewed up something with Alt and Mag values. They are not reacting in MultiWiiConf.
It's either that or my build is still screwed up. That would be ultimately weird, though...

timecop · Post by **timecop** » Mon Oct 14, 2013 11:42 pm

No, you're right.
Fixed in r441.

alu · Post by **alu** » Tue Oct 15, 2013 6:13 pm

I think there are still some problems. Alt is working now, but but Mag values are not.

timecop wrote:The proper way to handle vertical board mounting would be to rotating final sensor output vector...(which isn't implemented, feel free to patch

k, I attached a suggestion with most important transformations.

brm · Post by **brm** » Tue Oct 15, 2013 7:18 pm

alu wrote:I think there are still some problems. Alt is working now, but but Mag values are not.

timecop wrote:The proper way to handle vertical board mounting would be to rotating final sensor output vector...(which isn't implemented, feel free to patch

k, I attached a suggestion with most important transformations.

too complicated - add a Rotation Offset for each axis - done.
the ahrs-angles are: measured angles - Offset.

alu · Post by **alu** » Tue Oct 15, 2013 10:50 pm

brm wrote:too complicated - add a Rotation Offset for each axis - done.

I see your point, but that would be three command line arguments instead of one as well as more code and computation.
Plus, the order matters, so the user might have to take a look into the wiki anyway.

And then it is no fun to define proper rotations in an ill-defined system (Default orientation of X forward, Y right, Z up).
Just saying..

timecop · Post by **timecop** » Wed Oct 16, 2013 12:39 am

mag works - at least updates values. what are you seeing?
what's wrong with X forward, Y right, Z up? The recent sensor/imu reorganization/cleanup was to start using a standard system.
i like your orientation patch due to simplicity, but yeah, only 90" rotations/etc there.. hmm.. but I do like it.

alu · Post by **alu** » Wed Oct 16, 2013 8:01 am

timecop wrote:mag works - at least updates values. what are you seeing?

I don't know, since rev438 my Mag values are flatlining in MultiWiiConf. I rolled back and forth a couple of times with the same result.
Might be related to my MultiWiiConf version, though. It's been acting kind of quirky sometimes.

timecop wrote:what's wrong with X forward, Y right, Z up?

It's mathematically incorrect. Z should be the cross product of X and Y.
In this case it would mean that Z has to point down (which would be the classical North-East-Down configuration).
Alternatively Y could point point to the left (East-North-Up).

I know it needs getting used to having Z pointing down, but it yields a well-defined system with standard roll-pitch-yaw definitions and thus enables standard mathematical transformations.
The current version does not have/need those, since everything is working on a single-axis basis and I guess it would be a pretty bad idea to try and change it now. But it should be kept in mind.

brm · Post by **brm** » Wed Oct 16, 2013 7:08 pm

alu wrote:
timecop wrote:mag works - at least updates values. what are you seeing?

I don't know, since rev438 my Mag values are flatlining in MultiWiiConf. I rolled back and forth a couple of times with the same result.
Might be related to my MultiWiiConf version, though. It's been acting kind of quirky sometimes.

timecop wrote:what's wrong with X forward, Y right, Z up?

It's mathematically incorrect. Z should be the cross product of X and Y.
In this case it would mean that Z has to point down (which would be the classical North-East-Down configuration).
Alternatively Y could point point to the left (East-North-Up).

I know it needs getting used to having Z pointing down, but it yields a well-defined system with standard roll-pitch-yaw definitions and thus enables standard mathematical transformations.
The current version does not have/need those, since everything is working on a single-axis basis and I guess it would be a pretty bad idea to try and change it now. But it should be kept in mind.

timecop is right.
you prob. have seen to many code snippets when the sensor Fusion 'does' a cross product.
a cross product is the area between two vectors and has nothing to do with a coordinate System.

there are tons of Standards views aka coordinate Systems enu for example.
depends where you are ...

alu · Post by **alu** » Wed Oct 16, 2013 7:56 pm

brm wrote:you prob. have seen to many code snippets when the sensor Fusion 'does' a cross product.
a cross product is the area between two vectors and has nothing to do with a coordinate System.

guess again

brm · Post by **brm** » Wed Oct 16, 2013 8:18 pm

alu wrote:
alu wrote:you prob. have seen to many code snippets when the sensor Fusion 'does' a cross product.
a cross product is the area between two vectors and has nothing to do with a coordinate System.

guess again

what is ned?
http://en.wikipedia.org/wiki/North_east_down
Multi wii is not ned.

you missed the geometrical view of the cross product.

baseflight plus is ned for example.

alu · Post by **alu** » Thu Oct 17, 2013 8:46 am

@brm
Why do you keep criticizing my posts without even reading them?
I already posted your NED link in order to stress that both NED and ENU are right-handed coordinate systems.

All I wanted to do is to propose a new feature, which might prove helpful to some people (including me) and in the course I mentioned that the current baseflight implementation is using a left-handed system.

Have you checked some sensor datasheets, other projects or roll-pitch-yaw definitions? They all use right-handed coordinate systems.
You think that is a coincidence?

brm wrote:a cross product is the area between two vectors and has nothing to do with a coordinate System.

This is just wrong.

timecop · Post by **timecop** » Thu Oct 17, 2013 10:47 am

Well, the code went through one sensor unfucking undertaking, I wouldn't mind going through another one to fix it for good if it makes things better in the long run.
How much would it affect current shitty mwc algorithms if one was to fix it all?
Stop by the clan irc chat on freenode #multiwii and maybe we can discuss it?

crazyal · Post by **crazyal** » Thu Oct 17, 2013 11:01 am

alu wrote:@brm
Why do you keep criticizing my posts without even reading them?
I already posted your NED link in order to stress that both NED and ENU are right-handed coordinate systems.

All I wanted to do is to propose a new feature, which might prove helpful to some people (including me) and in the course I mentioned that the current baseflight implementation is using a left-handed system.

Have you checked some sensor datasheets, other projects or roll-pitch-yaw definitions? They all use right-handed coordinate systems.
You think that is a coincidence?

brm wrote:a cross product is the area between two vectors and has nothing to do with a coordinate System.

This is just wrong.

you know that the coordinate system used in baseflight is exactly the same as for the mpu6050 right ? btw it doesn't really matter where the axis point, as long as it's documented somewhere. Imho, if you aren't up to adapting the math for any coordinate system you shouldn't mess with it

alu · Post by **alu** » Thu Oct 17, 2013 11:43 am

crayzal wrote:you know that the coordinate system used in baseflight is exactly the same as for the mpu6050 right ? btw it doesn't really matter where the axis point, as long as it's documented somewhere. Imho, if you aren't up to adapting the math for any coordinate system you shouldn't mess with it

No, I did not know that they were the same. The MPU-6050 datasheet shows a right-handed coordinate system with z pointing up (aka ENU), whereas the cli wiki states "Default orientation of X forward, Y right, Z up", which is a left-handed coordinate system (y is pointing in the opposite direction).

Of course you are right that you could use any coordinate system. You could also define yaw to rotate around the x-axis. But why would you do that? It makes sense to stick to common definitions.

In this particular case I think it's a borderline decision whether it makes sense to change everything (requires work and is error-prone) or just stick with it since it is currently not causing any trouble (maybe causing trouble in future).
Btw, it would not be enough to invert y (ENU) or z (NED). Roll- pitch yaw definitions would also have to be changed. At the moment they are not even coherent with the current left-handed system...

Currently I'm at work, but maybe I can stop by in the channel later.
But keep in mind that changing this would probably be a major pain with signs at a lot of places in the source code...

P.S.: I just got another idea. Are you really sure that the current definition is as stated in the wiki: "Default orientation of X forward, Y right, Z up"?
I cannot check right now, but maybe it is really "X forward, Y left, Z up"?
This would be good news and explain why my first version of the patch was not working as expected. So far I was relying on the wiki statement, but crayzal's comment made me question this.

woozer · Post by **woozer** » Fri Oct 18, 2013 1:43 pm

Hi All,

I'm new here, and could not find a reason in the threads why there is a MMA8452Q accelerometer when the MPU6050 has one already....
Can someone enlighten me?

Thanks,
W

timecop · Post by **timecop** » Fri Oct 18, 2013 1:46 pm

Because you can switch to it and use it, if you want (actually it's default by firmware)

lunithy · Post by **lunithy** » Fri Oct 18, 2013 2:53 pm

timecop wrote:Thats what the rate next to PID for Yaw is.
Making it larger makes the quad spin faster. A lot faster.

It's the fast bit I can't slow down! looks like a UFO :oops:

so I turn the P and I down to 0 with no real effect I,m using version 5 with baseflight-20130719 it's like yaw is on steroids? strait flight until you touch the ruder and then all hell breaks lose :roll:

and yes I,m new to this place and this naze32 followed the guides thank you Timecop for all the work crazy little board it's a big step up from the KK so any help will be appreciated .
My test rig is a small 225mm diameter 240g with a 850mha 3s and really annoying 5030 props :twisted:

.

timecop · Post by **timecop** » Fri Oct 18, 2013 2:55 pm

I'd say upgrade to r429 wiping all flash and try it there, but there was only one yaw-related bug and that was introduced w/sensor axis realignment so.. you shouldn't be seeing that. But anyway, try r429 instead.

lunithy · Post by **lunithy** » Fri Oct 18, 2013 4:59 pm

timecop wrote:I'd say upgrade to r429 wiping all flash and try it there, but there was only one yaw-related bug and that was introduced w/sensor axis realignment so.. you shouldn't be seeing that. But anyway, try r429 instead.

Thank's was fun finding r429 I ended up copy pasting the hex i found at afro devices/Source ....noob alert :oops:

will give it a go.

alu · Post by **alu** » Fri Oct 18, 2013 7:39 pm

Okay, now that the handedness issue is cleared out, I had another go at the alignment patch.

crazyal · Post by **crazyal** » Fri Oct 18, 2013 11:20 pm

looks good imho.
btw baseflight allready uses a right handed coordinate system... Y points LEFT not right... check again

all that ruckus about nothing...

timecop · Post by **timecop** » Sat Oct 19, 2013 1:36 am

Looks good other than minor formatting crap, I'll merge this sometime today.

lunithy · Post by **lunithy** » Sat Oct 19, 2013 2:27 am

lunithy wrote:
timecop wrote:I'd say upgrade to r429 wiping all flash and try it there, but there was only one yaw-related bug and that was introduced w/sensor axis realignment so.. you shouldn't be seeing that. But anyway, try r429 instead.

Thank's was fun finding r429 I ended up copy pasting the hex i found at afro devices/Source ....noob alert will give it a go.

I have done as you said with no luck it calms down with the PID's turned down to 0 but still fly's like a UFO spinner toy with no center to the ruder

waiting for my flip to get here will try it on that frame.

alu · Post by **alu** » Sat Oct 19, 2013 8:26 am

crazyal wrote:btw baseflight allready uses a right handed coordinate system... Y points LEFT not right... check again all that ruckus about nothing...

Yes, you are right (see prior post).
Sure, I was relying on this one remark in the wiki for too long when I should have noticed/checked earlier, but like you hinted before, documentation is crucial

lunithy · Post by **lunithy** » Sat Oct 19, 2013 11:42 am

OK I'm getting the hang of this pid tuning and it's flying now and dam is it smooth

, the yaw is still really sensitive and I can still get a rate of spin that can exceed 1 a second.

hazmatNco · Post by **hazmatNco** » Sun Oct 20, 2013 6:57 pm

Not sure if this is the best place to ask, but I'm having an issue using my bluetooth module (http://www.multirotorsuperstore.com/pro ... etooth.htm) with a rev4 board. I've tried multiple android configuration apps and while they all correctly pair with the device, they all fail to actually read/write any data. The bluetooth module's default baud rate is 115200 so that shouldn't be an issue. Anyone have any ideas what the problem might be?

disq · Post by **disq** » Sun Oct 20, 2013 7:32 pm

hazmatNco wrote:Not sure if this is the best place to ask, but I'm having an issue using my bluetooth module with a rev4 board. I've tried multiple android configuration apps and while they all correctly pair with the device, they all fail to actually read/write any data.

Switch rx/tx lines and try again.

teslahed · Post by **teslahed** » Sun Oct 20, 2013 9:42 pm

timecop wrote:No, you're right.
Fixed in r441.

Where do i download r441?

I have been looking here; http://code.google.com/p/afrodevices/so ... &start=429

But only see as far as 429 which is the version i am running now without a working altitude hold flight mode.

QAV400 · Post by **QAV400** » Mon Oct 21, 2013 4:49 am

Hi all I was after some advise, I had the naze32 flying all pretty much perfect, then after a crash and breaking all my props and changing to a cheaper gemfan prop which is a lot more flexible my quad was oscillating very badly, and i have now fixed it by lowering the P value of pitch and roll from 4.0 to 2.0 I had to go to to get the problem to go away.
Is this quite normal with more flexy props to have to lower it that much?

Motors were not bent or anything like that.
Old props were hq e-prop 8x5
new props gemfan plastic slow flyer style 8x4.5

I am fairly new... go easy

teslahed · Post by **teslahed** » Mon Oct 21, 2013 5:28 am

Cheaper more flexible props will produce more vibrations that will negatively effect sensors on your flight controller. Dialing back the P value on pitch and roll will help compensate but the multirotor wont fly as well.

The HQ props are much better than the gemfans in my experience.

timecop · Post by **timecop** » Mon Oct 21, 2013 5:37 am

anything below 4 shouldn't be flying, so the problem is elsewhere.

> But only see as far as 429 which is the version i am running now without a working altitude hold flight mode.
complain to crazyal, its his recent althold mods.
"works for me" but the usual rules of covering baro etc apply

lunithy · Post by **lunithy** » Mon Oct 21, 2013 6:13 am

teslahed wrote:Cheaper more flexible props will produce more vibrations that will negatively effect sensors on your flight controller. Dialing back the P value on pitch and roll will help compensate but the multirotor wont fly as well.

The HQ props are much better than the gemfans in my experience.

I guess this is why I'm getting problems with yaw? I'm aware of the need to balance props and do it, I find my roll and pitch are sluggish with default settings running 429 but my yaw is ballistic and drifts.

QAV400 · Post by **QAV400** » Mon Oct 21, 2013 8:30 am

Thanks for the replies, I was also wondering if there was a way for me to tell what baseflight version is on my rev4 naze32 board?
I purchased it as the spiritfly32 board here in australia with firmware already loaded and have not needed to upgrade it yet, but was wondering if there was a way to find out what baseflight version was preloaded on it

timecop · Post by **timecop** » Mon Oct 21, 2013 8:48 am

'version' in cli.
anything shipped is currently w/firmware from 'downloads' page, which is dated july 2013.

QAV400 · Post by **QAV400** » Mon Oct 21, 2013 8:56 am

Thanks,

Mines says

# version
Naze32 cGiesen/Crashpilot Harakiri10Beta C May 12 2013 / 15:55:50

So thats not base flight i take it

My board is just the Standard version or acro no barro or mag

timecop · Post by **timecop** » Mon Oct 21, 2013 9:07 am

then that's what you got. no idea, post in their thread if you want more info

QAV400 · Post by **QAV400** » Mon Oct 21, 2013 9:15 am

ok, Its in another language so no help there for me really, would i be doing any harm in re-loading it with base flight?

Will it possibly work any better?

thanks again for helping I just dont want to "brick the board"

teslahed · Post by **teslahed** » Mon Oct 21, 2013 9:28 am

Read the naze32 manual;

http://www.abusemark.com/downloads/naze32_rev3.pdf

Look at the section on flashing the firmware. If it doesn't seem too tricky to follow then give it a go. You shouldn't 'brick' the board unless you do something seriously wrong.

The end result should be that you have the standard Naze32 firmware on your flight controller. This may make your life easier as the manual and threads are in english (mostly :lol:

)

QAV400 · Post by **QAV400** » Mon Oct 21, 2013 11:21 am

teslahed wrote:Read the naze32 manual;

http://www.abusemark.com/downloads/naze32_rev3.pdf

Look at the section on flashing the firmware. If it doesn't seem too tricky to follow then give it a go. You shouldn't 'brick' the board unless you do something seriously wrong.

The end result should be that you have the standard Naze32 firmware on your flight controller. This may make your life easier as the manual and threads are in english (mostly )

Ok thanks, I have now loaded baseflight-20130719.zip from the download page as it had a hex file,

In the naze32 manual pdf the link for the latest firmware just took me to the latest hex files "code" and i actually could not figure out how to get the baseflight.hex file from it

on the zip file i download it says "This build matches SVN r363" so does that mean i am now running baseflight r363?

as when i now type version into the CLI it tells me this:
# version
Afro32 CLI version 2.1 Jul 19 2013 / 15:11:44

and not an actually baseslight r363