Naze32 hardware discussion thread

LeoWie · Post by **LeoWie** » Sun Sep 09, 2012 3:53 pm

... almost off topic - question: I toasted one of my Rabbit GPS modules.
What could this be? ... red arrow on pic (now it is carbon and the other module is in use / mounted)

bug01.jpg: (107.17 KiB) Not downloaded yet

Thx
~~~ edit 1 ~~~
After 1+ hrs of googling + looking with the magnifying glass I ordered tantal-chip-cap 10V 10 µF (... 5 pcs :oops:

)
Thx to TC.

timecop · Post by **timecop** » Sun Sep 09, 2012 4:03 pm

Polarized tantalum cap, probably around 47uF.

a944734 · Post by **a944734** » Sun Sep 09, 2012 5:05 pm

Make that two users errors. I have the same Flytron module (defaults are 9600 and 1 Hz, changed defaults cannot be stored - chip limitation). Only way to change would be to find firmware 115200/10 Hz that fits. Not a road I would want to go really.
The module is designed to run on 5 V, tx and rx are 3.3 V

The module connects and works just fine in type=0 AND type=2 but ONLY at 9600 baud.

I certainly believe your pre-configured oharap works as type=0, as the code will not need to sent init strings ...

Unfortunately us other guys need init strings to work in type=2
These seem to work in Multiwii (taken from https://github.com/multiwii/multiwii-fi ... ed/GPS.ino)

Code: Select all

#if defined(GPS_SERIAL)
 #if defined(INIT_MTK_GPS) || defined(UBLOX)
  uint32_t init_speed[5] = {9600,19200,38400,57600,115200};
  void SerialGpsPrint(prog_char* str) {
    char b;
    while(b = pgm_read_byte(str)) {
      SerialWrite(GPS_SERIAL, b);
      #if defined(UBLOX)
        delay(4);
      #endif
      str++;
    }
  }
 #endif
 #if defined(UBLOX)
   prog_char UBLOX_INIT[] PROGMEM = { // PROGMEM array must be outside any function !!!
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x05,0x00,0xFF,0x19, //disable all default NMEA messages
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x03,0x00,0xFD,0x15,
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x01,0x00,0xFB,0x11,
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x00,0x00,0xFA,0x0F,
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x02,0x00,0xFC,0x13,
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x04,0x00,0xFE,0x17,
     0xB5,0x62,0x06,0x01,0x03,0x00,0x01,0x02,0x01,0x0E,0x47, //set POSLLH MSG rate
     0xB5,0x62,0x06,0x01,0x03,0x00,0x01,0x03,0x01,0x0F,0x49, //set STATUS MSG rate
     0xB5,0x62,0x06,0x01,0x03,0x00,0x01,0x06,0x01,0x12,0x4F, //set SOL MSG rate
     0xB5,0x62,0x06,0x01,0x03,0x00,0x01,0x12,0x01,0x1E,0x67, //set VELNED MSG rate
     0xB5,0x62,0x06,0x16,0x08,0x00,0x03,0x07,0x03,0x00,0x51,0x08,0x00,0x00,0x8A,0x41, //set WAAS to EGNOS
     0xB5, 0x62, 0x06, 0x08, 0x06, 0x00, 0xC8, 0x00, 0x01, 0x00, 0x01, 0x00, 0xDE, 0x6A //set rate to 5Hz
   };
 #endif

  void GPS_SerialInit() {
    SerialOpen(GPS_SERIAL,GPS_BAUD);
    delay(1000);
    #if defined(UBLOX)
      for(uint8_t i=0;i<=5;i++){
        SerialOpen(GPS_SERIAL,init_speed[i]); // switch UART speed for sending SET BAUDRATE command (NMEA mode)
        #if (GPS_BAUD==19200)
          SerialGpsPrint(PSTR("$PUBX,41,1,0003,0001,19200,0*23\r\n")); // 19200 baud - minimal speed for 5Hz update rate
        #endif
        #if (GPS_BAUD==38400)
          SerialGpsPrint(PSTR("$PUBX,41,1,0003,0001,38400,0*26\r\n")); // 38400 baud
        #endif
        #if (GPS_BAUD==57600)
          SerialGpsPrint(PSTR("$PUBX,41,1,0003,0001,57600,0*2D\r\n")); // 57600 baud
        #endif
        #if (GPS_BAUD==115200)
          SerialGpsPrint(PSTR("$PUBX,41,1,0003,0001,115200,0*1E\r\n")); // 115200 baud
        #endif
        delay(10);
      }
      SerialOpen(GPS_SERIAL,GPS_BAUD);
      for(uint8_t i=0; i<sizeof(UBLOX_INIT); i++) { // send configuration data in UBX protocol
        SerialWrite(GPS_SERIAL, pgm_read_byte(UBLOX_INIT+i));
        delay(4); //simulating a 38400baud pace (or less), otherwise commands are not accepted by the device.
      }
    #elif defined(INIT_MTK_GPS) // MTK GPS setup
      for(uint8_t i=0;i<=5;i++){
        SerialOpen(GPS_SERIAL,init_speed[i]); // switch UART speed for sending SET BAUDRATE command
        #if (GPS_BAUD==19200)
          SerialGpsPrint(PSTR("$PMTK251,19200*22\r\n")); // 19200 baud - minimal speed for 5Hz update rate
        #endif
        #if (GPS_BAUD==38400)
          SerialGpsPrint(PSTR("$PMTK251,38400*27\r\n")); // 38400 baud
        #endif
        #if (GPS_BAUD==57600)
          SerialGpsPrint(PSTR("$PMTK251,57600*2C\r\n")); // 57600 baud
        #endif
        #if (GPS_BAUD==115200)
          SerialGpsPrint(PSTR("$PMTK251,115200*1F\r\n")); // 115200 baud
        #endif
        delay(10);
      }
      // at this point we have GPS working at selected (via #define GPS_BAUD) baudrate
      SerialOpen(GPS_SERIAL,GPS_BAUD);
      SerialGpsPrint(PSTR("$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n")); // only GGA and RMC sentence
      SerialGpsPrint(PSTR("$PMTK220,200*2C\r\n")); // 5 Hz update rate
    #endif
  }
#endif

msev · Post by **msev** » Sun Sep 09, 2012 7:32 pm

Hehe thats the gps that I have..It works on my osd as it should at 5V, does he use it at 3.3V? I haven't tried it on afro32 yet. Hope.u guys make it work with the init sentences

ruffster · Post by **ruffster** » Sun Sep 09, 2012 9:03 pm

I've got it connected to one of the esc bec - do I need to get it powered up before firing up the naze32? I'll give it a go tomorrow and check the tx/rx lines for continuity. Any other ideas as to other things to try would be much appreciated

LeoWie · Post by **LeoWie** » Sun Sep 09, 2012 9:12 pm

The 1st "Naze32 Micro GPS-Module + KeyCam(?) - Heavy Lifter" - Video:
http://www.youtube.com/watch?v=5CWISUnl2hA 8-)

Details: viewtopic.php?f=22&t=2387&start=90#p22426

a944734 · Post by **a944734** » Sun Sep 09, 2012 9:20 pm

ruffster wrote:I've got it connected to one of the esc bec - do I need to get it powered up before firing up the naze32? I'll give it a go tomorrow and check the tx/rx lines for continuity. Any other ideas as to other things to try would be much appreciated

So there's three of us already, should be reason enough to get the inits working

Mine is taking 5 V from the receiver, just the same. It therefore starts the same time as the Naze. Works fine, sending data - but ONLY at 9600 baud in
type=0 and in type=2. Baud rate any higher = no worky
Definitely a problem with the inits in type 2 (type 0 does probably not send inits)

BrokenRotor · Post by **BrokenRotor** » Mon Sep 10, 2012 1:25 am

Hum, I have configured r209 with PWM and GPS. The weird thing is that if I do not map RTH in GUI I can arm the motors. If I map RTH under any AUX channel, the motors will not arm in the usual way, but if I select RTH active, the motors self arm?
All other channels and functions seem normal in the GUI. Using MultiWiiWin2.1 GUI.

Is this a code bug?

timecop · Post by **timecop** » Mon Sep 10, 2012 8:08 am

MTK init sequences ARE sent with gps_type=2. I haven't tested if MTK3329 (that FMP04 module I got) accepts them or not, but according to the datasheet/protocol PDF, it should.

gps_type=0 is for modules t hat do NOT need any external configuraion and you KNOW thier baudrate ahead of time - i.e. module outputting at 38400 will need that rate to be specified for gps_baudrate or it will NOT get any data.

BrokenRotor: there are no code paths for something like this to be happening.

DrEvil · Post by **DrEvil** » Mon Sep 10, 2012 12:32 pm

timecop wrote:MTK init sequences ARE sent with gps_type=2. I haven't tested if MTK3329 (that FMP04 module I got) accepts them or not, but according to the datasheet/protocol PDF, it should.

gps_type=0 is for modules t hat do NOT need any external configuraion and you KNOW thier baudrate ahead of time - i.e. module outputting at 38400 will need that rate to be specified for gps_baudrate or it will NOT get any data.

BrokenRotor: there are no code paths for something like this to be happening.

I have tested the Eagle Tree GPS V4 modul/dongle with the 209sw ang got it responding and giving data in MWIwin 2.1
Set it to gps_type=0 and 38400 in Cli.
It displayed a speed of 55kmt in my window post :roll:

with 6 satelites.

timecop · Post by **timecop** » Mon Sep 10, 2012 12:44 pm

I believe gps speed shown is in cm/sec, and if you're expecting accurate speed values from a module that's not moving, well, ...

DrEvil · Post by **DrEvil** » Mon Sep 10, 2012 4:35 pm

timecop wrote:I believe gps speed shown is in cm/sec, and if you're expecting accurate speed values from a module that's not moving, well, ...

Don't take it the wrong way TC, i was not expecting anything...
I just tought it was funny that the quadd was moving realy fast . . . . . in the windowpost..... LOL

At the moment i have no cloue about what to doe with gps and it's funktions, i hawe not been reading up on the subject.

Kai

Bhuwan · Post by **Bhuwan** » Mon Sep 10, 2012 6:06 pm

Finally back on here, I got my account reset (email wasn't working). Someone nearly convinced me to get the "AQ50d pro" FC, but I did my research on RCG and came across TC and, let's just say, i was enlightened (to not get it

).

I'm going to pick up the Naze32 once the cover is available again, but i had one question - anyone know if it'll work with my DJI fLame Wheel? :mrgreen:

LeoWie · Post by **LeoWie** » Mon Sep 10, 2012 8:37 pm

http://youtu.be/PojIzWpqtQY

a944734 · Post by **a944734** » Mon Sep 10, 2012 9:53 pm

timecop wrote:MTK init sequences ARE sent with gps_type=2. I haven't tested if MTK3329 (that FMP04 module I got) accepts them or not, but according to the datasheet/protocol PDF, it should.

May I suggest you do that test please, so we have facts

Just an idea - you are using pin 3 and 4 for GPS right ? Could one "listen" on pin 3 to see whats sent towards the GPS ?

BrokenRotor · Post by **BrokenRotor** » Mon Sep 10, 2012 11:44 pm

timecop wrote:BrokenRotor: there are no code paths for something like this to be happening.

Can someone test GPS usage with PWM receiver? It makes no sense that checking RTH would fire up the motors, plus the loss of normal motor start. I used gps_type = 0, 115200 baud with 3339 GPS chip.

rotary65 · Post by **rotary65** » Tue Sep 11, 2012 12:18 am

DrEvil wrote:I have tested the Eagle Tree GPS V4 modul/dongle with the 209sw ang got it responding and giving data in MWIwin 2.1
Set it to gps_type=0 and 38400 in Cli.
It displayed a speed of 55kmt in my window post with 6 satelites.

I am trying to get my Eagle Tree v4 GPS working with my Naze32 under 213. My Naze32 is running PPM. I set gps_baudrate=38400 and gps_type=0. I am running Multiwii Gui 2.1.

Which wires on the GPS did you use for TX and RX into the Naze (red, white, yellow, brown)? The pinout I found for the GPS cable was red=power, white=ground, yellow=tx (data to GPS), brown=rx (data from GPS).

A little bit more detail on what I'm attempting to do. I am splitting off the TX and RX from the GPS and have on set of TX/RX wires going to the Naze32 and the other set going to the V3 Logger (for the OSD). The GPS is being powered by the logger. This leaves two listeners (the logger and the Naze) and one talker (the V4 GPS)on the serial bus. The GPS is working fine with the logger/OSD. It may be that the output from the GPS can only effectively drive one listener.

Gruffy · Post by **Gruffy** » Tue Sep 11, 2012 5:43 am

BrokenRotor wrote:Hum, I have configured r209 with PWM and GPS. The weird thing is that if I do not map RTH in GUI I can arm the motors. If I map RTH under any AUX channel, the motors will not arm in the usual way, but if I select RTH active, the motors self arm?
All other channels and functions seem normal in the GUI. Using MultiWiiWin2.1 GUI.

Is this a code bug?

I saw that the function menus differ from MultiWii Configurator 2.1 and the MultiWii Gui. When you look into TC's code, you can see that the strings/names of the functions match the ones in MultiWii Configurator, but not in MultiWii Gui. My guess is that the MultiWii Gui does not read the strings properly, but instead they are hard coded to match the MultiWii 2.1 code. When I set the ALTHOLD in MultiWii Gui, this turned out to be MAG in the MultiWii Configurator. I am now using the MultiWii Gui for function mapping as that seems to be the correct info.
Maybe the RTH is ARM is one of these wrongly mapped functions in MultiWii Gui?

Ohh...an "Hi there" by the way. I just got here after getting a board from TC a few weeks ago. Quie new to the hobby, normally I fly single rotor helicopters and have a Logo 600 and a Protos 500. I do find this multilrotor thing very nice. Looking forward to flying/hacking with the Naze32 board!

timecop · Post by **timecop** » Tue Sep 11, 2012 6:22 am

Apparently, Gruffy is right.
MW-WinGui 2.1 uses hardcoded boxnames, so when I added angle/horizon modes, all boxes became shifted off by one.
Until EOSBandi fixes it, you can either use windows or android configs by nicodh or use the Java configurator.

DrEvil · Post by **DrEvil** » Tue Sep 11, 2012 7:34 am

rotary65 wrote:
I am trying to get my Eagle Tree v4 GPS working with my Naze32 under 213. My Naze32 is running PPM. I set gps_baudrate=38400 and gps_type=0. I am running Multiwii Gui 2.1.

Which wires on the GPS did you use for TX and RX into the Naze (red, white, yellow, brown)? The pinout I found for the GPS cable was red=power, white=ground, yellow=tx (data to GPS), brown=rx (data from GPS)..

I'm using Yellow kabel on pin 3 and Brown kabel on pin 4.
Power from free motor out pin's.

rotary65 · Post by **rotary65** » Tue Sep 11, 2012 3:54 pm

DrEvil wrote:I'm using Yellow kabel on pin 3 and Brown kabel on pin 4. Power from free motor out pin's.

@DrEvil: Thanks! That`s what I am using, but I wonder if the ET OSD Pro is sending initialization data that changes the output format. I`ll have to wait until I receive my USB-serial adapter to see.

@timecop: Nice job on the Naze32 manual update! Thank-you for all your work!

brm · Post by **brm** » Tue Sep 11, 2012 7:48 pm

hi tc,
i have a simple question.
in contrast to your suggestion not to fly a flamewheel i bought an f330.
the esc's are soldered to the bottom plate.
on real fast movements it seems i have a voltage drop and the esc
prob goes through a brown out.
question, do you know how it takes until the esc is back online?

timecop · Post by **timecop** » Wed Sep 12, 2012 1:12 am

Then get a higher C battery, you need it for that heavy piece of junk. 20C, preferably 40C, should do the job. Nothing to do with naze32 however.

timecop · Post by **timecop** » Wed Sep 12, 2012 3:16 am

Allright, MTK whiners rejoice. Found the problem and fixed it, confirmed working with my MTK GPS board.
Since I'm using interrupt-based uart code, I would write the buffer and start sending it at baudrate X, but CPU is too fast (not a problem in 8bitland), so while the buffer was still sending I'd already loop around to next baudrate and change to it, while there's some data left to transmit at previous baudrate. (was especially evident at 9600 baud). I guess 8bitland never hits this either because GPS uart is poll-based or maybe because it's just too slow the buffer makes it out before next configure loop iteration.

Here's how it looks. I added 30ms delays between each transmission as well, just to make sure.

a944734 · Post by **a944734** » Wed Sep 12, 2012 10:39 am

On certain occasions some whining is quite in order to help find bugs

Have now successfully connected my Flytron MTK GPS module using gps_type = 2 and gps_baudrate = 57600, receiving data and fix in GUI

Just to be very precise, in the meantime I had reflashed its firmware to 38400 / 5 Hz

No chance to test fly today, rain is pouring down

BTW - how much whining is needed to get an AfroOSD ?

BrokenRotor · Post by **BrokenRotor** » Wed Sep 12, 2012 12:49 pm

timecop wrote:Apparently, Gruffy is right.
MW-WinGui 2.1 uses hardcoded boxnames, so when I added angle/horizon modes, all boxes became shifted off by one.
Until EOSBandi fixes it, you can either use windows or android configs by nicodh or use the Java configurator.

Thanks TC / Gruffy. I guess it's back to the java app for configurations.
BTW> what does the angle / horizon modes control?

timecop · Post by **timecop** » Wed Sep 12, 2012 12:59 pm

https://www.google.com/search?q=multiwi ... angle+mode

its something alex came up with months ago. angle = old acc. horizon = something new.

a944734 · Post by **a944734** » Wed Sep 12, 2012 5:02 pm

Next little problem - feature GPS not "remembered"

Procedure as follows (feature GPS is set in CLI of course at the beginning)

- Power up Naze
- Connect to MultiWiiConf
- Open COM
- START
-> GPS data is received, compass blinks, sats are counting up
-> GPS BOX is NOT green, no GPS functionality e.g. no warning when switching to GPS HOLD before fix is achieved

Remedy as follows (Naze still powered on)
- MultiwiiConf Close COM
- Start Hercules, open COM
- type feature -GPS
-> feature GPS disabled
- type feature GPS
-> feature GPS enabled
- save (reboot)
- Close COM
- MultiwiiConf Open COM
- START
-> GPS data is received, compass blinks, sats are counting up
-> GPS BOX is NOW green, all GPS functionality available

As soon as NAZE is powered off / back on we start from point 1 unfortunately, no green GPS BOX

timecop · Post by **timecop** » Wed Sep 12, 2012 6:26 pm

Are you power-cycling the GPS during that time as well?
GPS will be disabled if there's no valid nmea data within 1 second, I should probably increase that timeout, otherwise the sequence you describe makes no sense, enabling/disabling GPS has no effect on whether it will be found or not next time its enabled.

brm · Post by **brm** » Wed Sep 12, 2012 7:19 pm

timecop wrote:Then get a higher C battery, you need it for that heavy piece of junk. 20C, preferably 40C, should do the job. Nothing to do with naze32 however.

measering the voltage drop is an interesting sub-project.
in case of fast esc's you can create an electronic braking system which works against the throttle :mrgreen:

i have a 25c battery with 110 amps burst - have not yet tested with 30c
before flying smooth you should know why it is fyling smooth

LeoWie · Post by **LeoWie** » Wed Sep 12, 2012 7:47 pm

Hi,
I saw that TC modis 2 r's ago affect all gps-communication (gpsprint).
So I re-tested my GPS modules (indoor only) on development version r218.

Tests procedure:
mod settings in CLI, check in MultiWiiConf_2_1 GUI [GPS] button green or not (close + open GUI).
No sats visible in my urban canyon apartment, no flight test possible today: rain is pouring down.

GPS Modules:
a) Rabbit GPS (ublox NEO-6M-0-001, worked on a Rabbit FC before)
b) Crius CN-06 GPS Receiver Module (out of the box)

Connection :
GPS in PWM input mode.
GPS:Rx-FC:3:TX + GPS:Tx-FC:4:RX (not Tx-Tx + Rx-Rx).
Gnd, +5V from Naze32's free CH5 or 6

Test result:

Code: Select all

set gps_type = 1 (not 0 + 2)          
set gps_baudrate = 
        a) Rabbit   b) Crius 
        r212 r218   r212 r218   
 19200    ok   ok      -   ok
 38400    -    ok      -   ok
 57600    -    ok      -   ok
115200   -    ok      -   ok

Thx TC.

PS: a " MediaTek MTK3329 GPS Module 10hz GPS With Antenna APM ACM Identification" will arrive soon.

Gruffy · Post by **Gruffy** » Wed Sep 12, 2012 8:47 pm

I can confirm that the MTK3329 GPS with ArduPilot adapter (yes...I am sorry, but I own one of those as well...) works with baudrate=38400, type=2 (MTK) and I get the green "GPS" symbol. I did not wait for "locked position" in this test (indoor without reach of signals) but I have high hopes on this, will let you know more.
Powered from 5V (on motor pin headers), the UART TTL level out with this adapter board is still 3.3V hence works nice and easy to connect. This was done with PWM receiver (skipping channel 3&4 as per manual). Have ordered myself a PPM-DSM2 receiver for future tests.

a944734 · Post by **a944734** » Wed Sep 12, 2012 9:15 pm

timecop wrote:Are you power-cycling the GPS during that time as well?
GPS will be disabled if there's no valid nmea data within 1 second, I should probably increase that timeout, otherwise the sequence you describe makes no sense, enabling/disabling GPS has no effect on whether it will be found or not next time its enabled.

I am not power-cycling the GPS. It is fed from the receiver and everything is on all the time.

I think increasing this timeout would be a good idea, have my doubts that the lame MTK GPS is able to send data within a single second from system start.
Obviously my remedy routine helps because there is a Naze reset in there - GPS being still powered it is ready to send even before Naze comes back up.

rotary65 · Post by **rotary65** » Wed Sep 12, 2012 11:54 pm

With r213, I have the Naze32 and my Eagle Tree V3 Logger/OSD Pro successfully sharing the same Eagle Tree GPS V4. The brown Tx line from the GPS is split and connects to pin 4 on the RC Header on the Naze. I set gps_type=0, gps_baudrate=38400 and feature gps (I had missed this last step before). All is working well.

DrEvil · Post by **DrEvil** » Thu Sep 13, 2012 11:48 am

rotary65 wrote:With r213, I have the Naze32 and my Eagle Tree V3 Logger/OSD Pro successfully sharing the same Eagle Tree GPS V4. The brown Tx line from the GPS is split and connects to pin 4 on the RC Header on the Naze. I set gps_type=0, gps_baudrate=38400 and feature gps (I had missed this last step before). All is working well.

Nice to know you got the sharing of GPS data with ET-osd to work. :-)

Kai

Count · Post by **Count** » Thu Sep 13, 2012 12:59 pm

Just one quick question before I waste more time on this:

Is the flying wing mixer fully functional?

timecop · Post by **timecop** » Thu Sep 13, 2012 1:07 pm

Should be.
If you feel you are wasting your time at any moment, may I direct you towards DJI products.

rotary65 · Post by **rotary65** » Thu Sep 13, 2012 1:10 pm

DrEvil wrote:
rotary65 wrote:With r213, I have the Naze32 and my Eagle Tree V3 Logger/OSD Pro successfully sharing the same Eagle Tree GPS V4. The brown Tx line from the GPS is split and connects to pin 4 on the RC Header on the Naze. I set gps_type=0, gps_baudrate=38400 and feature gps (I had missed this last step before). All is working well.

Nice to know you got the sharing of GPS data with ET-osd to work.

Kai

Thanks for your help in confirming details Kai. I have also just changed from a FreeFlight board to timecop`s latest v4 Naze32 with the dev firmware. The new hardware and firmware is completely AWESOME! The new sensors on the v4 (MPU6050, MMA8452Q, MS5611) are so, so much better performing than the ones of the FreeFlight (MPU3050, BPM085, ADCL345). Now it`s just about fine tuning, not coarse adjustments with poor results as it was with the FreeFlight.

@Timecop: After checking around a bit, I really appreciate your approach with baseflight. You maintain enough control to ensure good quality while quickly porting over selected bits from the MWC trunk. Open, readily available (to those who don't need handholding) and supported (with good, quick updates and response to bugs and enhancements). Many Naze32 and baseflight extras. Very cool.

kipkool · Post by **kipkool** » Thu Sep 13, 2012 3:36 pm

Hi there.

Just for info guys, this dude has just ported OpenPilot to STM32F4 ( Discovery board ), and MPU6050 PiOS is done.

https://github.com/lilvinz/OpenPilot/wi ... s-is-about

What's difference do we have between STM32F3 and F4 ? I'm just giving a look on PiOS stuff to check what works involved for a simple port ( no baro + compass yet ). Seems too hardcore for me but who knows...

I don't have the new Naze32 rev, mine is still ADXL345 based and never could make it works correctly in level mode on my different frames, but I think I'll order TC a new one. All mpu6050 based units I've tested always worked really well here.

rotary65 · Post by **rotary65** » Thu Sep 13, 2012 4:42 pm

kipkool wrote:Hi there. Just for info guys, this dude has just ported OpenPilot to STM32F4 ( Discovery board ), and MPU6050 PiOS is done.

The OpenPilot project perspective on porting. In a nutshell, they rely on flight controller hardware sales to keep the project going. They write the code and they generally do not wish for it to be ported.

timecop · Post by **timecop** » Thu Sep 13, 2012 5:14 pm

kipkool wrote:I don't have the new Naze32 rev, mine is still ADXL345 based and never could make it works correctly in level mode on my different frames, but I think I'll order TC a new one. All mpu6050 based units I've tested always worked really well here.

high acc_lpf, fixed loop time at 3000 or so, should be fine on defaults without too much vibration.

porting - yea, not gonna happen, not by me, for sure.

Bhuwan · Post by **Bhuwan** » Thu Sep 13, 2012 5:23 pm

timecop wrote:Should be.
If you feel you are wasting your time at any moment, may I direct you towards DJI products.

LOL

a944734 · Post by **a944734** » Fri Sep 14, 2012 9:21 am

a944734 wrote:
timecop wrote:Are you power-cycling the GPS during that time as well?
GPS will be disabled if there's no valid nmea data within 1 second, I should probably increase that timeout, otherwise the sequence you describe makes no sense, enabling/disabling GPS has no effect on whether it will be found or not next time its enabled.

I am not power-cycling the GPS. It is fed from the receiver and everything is on all the time.

I think increasing this timeout would be a good idea, have my doubts that the lame MTK GPS is able to send data within a single second from system start.
Obviously my remedy routine helps because there is a Naze reset in there - GPS being still powered it is ready to send even before Naze comes back up.

Can I please have a version with this timeout increased ? Maybe you want to make this a CLI variable, so I could find out how much is needed for the Flytron version. Might also come in handy when other MTKs come into use.

timecop · Post by **timecop** » Fri Sep 14, 2012 9:27 am

timeout is not really a solution since it owuld affect other gps users.
I'll think of some proper way to detect GPS, as well as handle disconnection of GPS mid-flight which mwc currently fails it.
this will fix the autodetect part as well.

kipkool · Post by **kipkool** » Fri Sep 14, 2012 9:30 am

The OpenPilot project perspective on porting.[/url] In a nutshell, they rely on flight controller hardware sales to keep the project going. They write the code and they generally do not wish for it to be ported.

Seems they're a little bit more flexible now, the STM32F4 + mpu6050 patch is in review for Git merge.
They just don't want company to make buisness with OP code, but hobby port is not forbidden.

Code: Select all

porting - yea, not gonna happen, not by me, for sure.

Wants to try myself just as an exercise.

high acc_lpf, fixed loop time at 3000 or so, should be fine on defaults without too much vibration.

I 've not touched my naze32 since May ( was playing with OP, and have to say I love the software ), so didn't followed latest baseflight evolution There was no looptime tuning yet if I remember. Will check that thanks.
I'm actually building a new test frame for it and giving a look to baseflightplus code.

Cheers.

Count · Post by **Count** » Fri Sep 14, 2012 9:59 am

timecop wrote:Should be.
If you feel you are wasting your time at any moment, may I direct you towards DJI products.

No thanks, I am perfectly pleased with how my Naze boards perform in my copters.
I just tried to install one them in one of my planes (a flying wing) and could not seem to get the setup right.
I needed to reverse the servo directions and alter the mix, because one servo arm is pointing up and the other one down.
With the default flying wing mixer this gets me parallel elevon movement with roll and opposit movement with pitch and the Naze board was correcting in the wrong way
First I set wing left max to 1050 and min to 2000. This caused the left elevon to go to the negative endpoint and stay there, only moving with full right roll input.
I then saw the pitch and roll reverse settings. I set the min max values back to default and altered one reverse setting (can´t remember which). This also caused one elevon to move to the endpoint. For some reason the elevon did not move back to the middle position after I set the value to default again.
Only setting the Naze board to defaults got it working again.

timecop · Post by **timecop** » Fri Sep 14, 2012 10:21 am

Yes, I agree, the servo stuff is a giant mess now.
Different min/max endpoints between gimbal, airplane, flyingwing mixes. Need to refactor that into a single way to configure any attached servo.

Usually if things are weird, resetting to defaults is first thign to do - some firmwares change config struct wihtout bumping version# so it doesn't get cleared and weird stuff happens.

a944734 · Post by **a944734** » Fri Sep 14, 2012 2:29 pm

Ok, here results of first flight test with Flytron MTK GPS working and active.
Conditions fine, small breeze

Attempt 1 (waited for full GPS fix with 7 satellites)
Started in mode man -> fine as ever
Switched to mode angle -> fine as ever, well trimmed
Switched to GPS Hold -> nothing bad, quad is visibly trying weakly to stay on the spot. Bringing it back to the spot by gently nudging sticks
However after about 20 seconds in GPS hold, quad flips violently to the left - lands upside down on tarmac - two motors running full blast. No reaction to TX commands, had to unplug power. No major damage, just a blade tip

Attempt 2 (again after fix with 6 satellites)
Start in mode man -> no problem
Switche to mode angle -> no problem, stable
Switching to GPS Hold -> same behaviour, trying to hold position. Again after 30 seconds, snap into 90 degree angle to rear/left, crash again - this time into grass. Two motors again running WOT, no reaction to TX - needed to unplug power. This time all blades gone

Don't get me wrong, am not moaning here. This is my heavy metal beater quad - crashing is part of beta testing, no sweat

What IS bothering me is the fact that TX control was lost both times immediately and totally. Be assured I was expecting things, fingers on the switch. Within split seconds I had throttle off and switched back to MAN - it did not react at all even before it was on ground. The FC was totally frozen until I unplugged

timecop · Post by **timecop** » Fri Sep 14, 2012 2:36 pm

Great, sounds like time for you to dig into the code and start figuring stuff out - I've spent about as much time as I'm willing to spend on something that doesn't interest me (GPS).

Incase there's a hardfault, all motors stop btw.

a944734 · Post by **a944734** » Fri Sep 14, 2012 5:22 pm

Relax, I thought feedback was welcome to help advance your product.
I'm a buyer and tester, not a coder

Over to others, may they be more successful