MultiWii port to STM8S105

[timecop]

I was bored and took 1.8p1 and ported it to STM8S -> http://www.st.com/internet/mcu/subclass/1244.jsp
This is NOT related to AVR or any Atmel-cpu.
I tried to keep most changes under #ifdef STM8, but maybe wasn't too careful in places.
My STM8 board uses analog gyros and adxl345 on SPI bus, so a couple changes were needed for that.
Gyros are 500deg/sec and adc is 10bit, I think I properly adjusted gyro factor and scale, but maybe an expert can take a look and check.

If I implement I2C to read sensors, this could theoretically run on something like $9 STM8SDiscovery + any current I2C sensor bob, with advantage of running at 3.3V

GUI looks OK, but not flight tested at all:
http://www.youtube.com/watch?v=Pq7WTRz4pkM

Modified source at http://code.google.com/p/afrodevices/so ... %2Fafrowii

Comments? Flames?

[Alexinparis]

Hi,

It's an interesting port exercise !
The code seems also well structured regarding the original one.

About the gyro concern:

For the ITG3200:
We use it with a 2000 deg/s setting.
It has a 16 bit resolution. (+/- 32768)
As we divide the output by 4 in the sensor code to avoid useless noise, the resulting unit from the sensor part is 8192 = 2000 deg/s

about the formula:
#define GYRO_SCALE ((2000.0f * PI)/((32767.0f / 4.0f ) * 180.0f * 1000000.0f) * 1.155f)

It converts the sensors output in rad/microseconds.
It is used latter to find a delta angle between 2 calls of the getEstimatedAttitude function:

1.155f is an empirical value
I don't know why we must exactly use it, but it's closer to the measurement with it.

dT in expressed in microseconds
deltaGyroAngle is expressed in rad
deltaGyroAngle = (output sensor gyro sensor) * dT * GYRO_SCALE

If you want to adjust your gyro, you have to find this magic number according to the resolution (500deg/s), the ADC outputs, and the voltage reference.

But there is a simple way to find it empirically via a test procedure:
1) use a very high GYR_CMPF_FACTOR value to decrease the influence of the ACC in the calculation. (50000 for instance)
2) rotate manually the boards, and see what happen in the GUI. The graph should indicate the right rotation angle. => adjust then the GYRO_SCALE value to correct any deviation.
Ignore the angle drift, it would be normal with a high GYR_CMPF_FACTOR. The important thing here is to adjust the rotation rate.

[timecop]

Cool, thanks for replying to my email here, maybe the info can help others as well.

I suspected /4 was happening somewhere but did not look much into it.

I'm going to try (I need to make another devboard as I think I fried analog inputs on the one on my desk - they're consistently less amplitude than the ones from the board on my copter and that could mean bad things.

So for 10bit adc, 500deg/sec, the formula SHOULD look like:
#define GYRO_SCALE ((500.0f * PI)/((1023.0f) * 180.0f * 1000000.0f) * 1.5f)
1.5 being magic, and I guess as long as I don't add /4 division in MY gyro code it should be fine without it.

I see gyro offset is handled during gyro calibration, when checking, it ends up at correct values (~480-ish for my hardware) so I think that part is working fine. I'll post my results here

[timecop]

OK, I ended up having GYRO_SCALE as this:
#define GYRO_SCALE ((500.0f * PI)/((1024.0f) * 180.0f * 1000000.0f) * 3.0f)

Without * 3.0 it was pretty laggy in rotation response, so I increased that until the angles were correct.

So now that I had correct angles in GUI with high acc factor, I put acc back to 310 or whatever was default. But there's still barely any motor response when tilting/rolling the board, at least not anything like I'm used to expect. I'm going to check to make sure my micros() algorithm is correct and that the loop time is actually what it should be - but cycletime displayed is correct, so it shouldn't be an issue.

I would imagine default PIDs should be OK, right?

Is there any other place in the code that assumes gyro data is 16bit? Should I worry/care about the analog gyro offset and take it out inside Gyro_GetADC, or does zeroing that occurs during arming takes care of that?

I suppose I better finish porting I2C code and try this thing with ATAVRSBIN1

[timecop]

Moving right along.
I2C code has been done, and I had ATAVRSBIN1 laying around from my XPlained board.
I defined the proper stuff, and the GUI is showing it correctly.

However there's a strange unexplained dip sometimes - the sensor jumps to -5000 or so for readings.
Is this something people seen with ATAVRSBIN1 or am I failing it?

Here's the current setup:


Not tried fly-testing it yet, but GUI looks OK.
If I try flying with this sensor board and it works, that means there's more magic 16bit gyro code somewhere that I haven't found yet

[copterrichie]

Moving right along.
I2C code has been done, and I had ATAVRSBIN1 laying around from my XPlained board.

My question is not related to this thread however, I would like to ask you being that you mentioned the XPlained Board. I am considering purchasing one, what is your opinion of it?

Thank you.

[timecop]

The board itself isn't worth it. It's ATXMega, and currently no code exists for it to do anything.
There's not enough headers on the board to use it as a multirotor controller, and its too big for that anyway.
However, the sensor boards (Inertial one / pressure one / inertial two?) are a decent deal.

Unless you really NEED a evalboard for ATXMega, I can't really recommend the Xplained board for anything useful
If y ou really want a XMega board, something like http://www.olimex.com/dev/avr-hx128a1.html would probably be better for prototyping things, since it has all the pins broken out etc...

[copterrichie]

Thank you. Scratch one items from my wish list.

[timecop]

OK, I guess its working with ATAVRSBIN1, so the issue is there's some 2000dps-ness in the code somewhere that assumes high-rate gyros.
Alex, any ideas?

Test flight with my STM8 board + ATAVRSBIN1:

http://www.youtube.com/watch?v=nYtuVukfcc4

I had to turn RC_Rate WAY up after this video, and there's still some unexplained yaw that happens in gyro only mode... What's up with that? Shouldn't there be a PID on yaw as well to avoid gyro drift?

Latest code has been posted to google code url in 1st post.

[timecop]

Everything works, I declare victory

http://www.youtube.com/watch?v=phOtpMJZah8

Can be configured to either use onboard gyro+accel or external i2c sensor board at 3.3V (tested with atavrsbin1, but should work with other junk too).

Latest code here http://code.google.com/p/afrodevices/so ... %2Fafrowii

[copterrichie]

Congradulations.

[timecop]

Looks like the strange yaw activity must have been due to dodgy/faulty yaw gyro on my prototype board.
I made a new smaller form factor PCB and loaded code with defaults, and yawing is (as good) as its going to get I guess.
I've also merged all changes up to multiwii 1.8_p2. I guess I'll match them with the new stable whenever that comes out.
Does it make sense to track _dev versions for updates, or are those too "unstable"?

Some boring line of sight flyaround on a small (~35cm) quad
http://www.youtube.com/watch?v=ZFWKUnmFUxw

http://i.imgur.com/bKYtP.jpg
left: new stm8s105 board running multiwii port, right: openpilot cc

[Alexinparis]

Hi,

It's an interesting realization.
Except if you plan to use other sensors (baro & mag) or other receivers, I think there is no reason for the moment to switch to dev versions. dev version offers currently some loop time optimization, but it wouldn't be useful here considering the power of the STM.
The corrected stable mode (if possible) will be anyway easy to port to 1.8.

[timecop]

OK, thanks for advice. I will wait until there's a new-stable or until there's some feature in _dev that I'm required. I do have a 3.3V I2C header but I don't think I'm going to be using any other sensors. I might use it for motor control and make motor 1-6 as PWM inputs, but thats not a high priority.

By the way, 'stable' seems to work OK here as far as I can tell. I don't very often use it.

[ciskje]

Sorry Alex you are wrong:

32767 is not 2000 deg/s

ITG3200 have a 14.375 LSB/(deg/s) (read the datasheet) so

32767/14.375 is 2279.44 deg/s

2000 is only a value for the reference scale.

[Alexinparis]

Sorry Alex you are wrong:

32767 is not 2000 deg/s

ITG3200 have a 14.375 LSB/(deg/s) (read the datasheet) so

32767/14.375 is 2279.44 deg/s

2000 is only a value for the reference scale.

Hi, you're right, my explanation was incorrect but the code is nearly correct

about the formula:
#define GYRO_SCALE ((2000.0f * PI)/((32767.0f / 4.0f ) * 180.0f * 1000000.0f) * 1.155f)

It converts the sensors output in rad/microseconds.
It is used latter to find a delta angle between 2 calls of the getEstimatedAttitude function:

1.155f is an empirical value
I don't know why we must exactly use it, but it's closer to the measurement with it.

2000 * 1.155 = 2310 is quite close to 2279
This is the explanation of this factor which should be 1.1395

[timecop]

It would be cool if in next version, the gyro scalefactor could be implemented, so things like 500deg/sec gyros (or any other rate really) could be easily used. Right now I just lucked out (somehow?) by multiplying my 500deg/sec output by 5 to get the values mwii wanted, but it would be nice to have a proper number.

[copterrichie]

How hard would it be to port the MultiWii to a STM32F4?

Thanks

[timecop]

Um, should be almost no effort based off the current stm8 base.
I was going to do it but got lazy. It'll be mostly touching stuff in sysdep.c and adjusting timer / pwm setup under #ifdef STM8 defines.

it'll also be kind of a waste of processor power, though

[timecop]

Just committed (non-flight tested) update for MPU6000.
Currently trying to figure out how to configure HMC5883L behind the SPI bus.
Reading seems straightforward, but initial configure seems to be lacking info.