MultiWii

EOSBandi,

Just curious but I'm guessing that the I2C variant will require a combination of Co-ordinated I2C Gps (Navigatron in my case) and MultiWii sketches to function correctly.
One to provide the GPS co-ordinates and one to act on them, how much can you offload to the second processor?
Can the Atmega328 based GPS and I2C Bus provide sufficient resolution? (here's hoping)

Hi,
it should be an option to decide wheter the copter should rotate nose/back to home direction om rth or not.

I use RTH as a panic function to retrieve my copter when I am about to loose it or when I lost orientation.

So for me it would be best to return to me with the nose facing away from me to regain control.

But if you want a cool approch or a cam approch to home you would prefer nose ahead.

Gaijin wrote:EOSBandi,

Just curious but I'm guessing that the I2C variant will require a combination of Co-ordinated I2C Gps (Navigatron in my case) and MultiWii sketches to function correctly.
One to provide the GPS co-ordinates and one to act on them, how much can you offload to the second processor?
Can the Atmega328 based GPS and I2C Bus provide sufficient resolution? (here's hoping)

In order to fit into the memory constraints of the 328 based flight controllers, I would like to offload as much calculations as possible to the i2cgps proc. All PID controls and most of the navigation calculations wil run on the i2cgps. The i2cgps will output a nav_lat and nav_lon which is the desired banking according to the lat/lon coordinate system. The only calculation which has to be on the FC is the rotation of this desired banking into a copter's frame of reference. (1sin,1 cos and same multiplications).

jevermeister wrote:Hi,
it should be an option to decide wheter the copter should rotate nose/back to home direction om rth or not.

I use RTH as a panic function to retrieve my copter when I am about to loose it or when I lost orientation.

So for me it would be best to return to me with the nose facing away from me to regain control.

But if you want a cool approch or a cam approch to home you would prefer nose ahead.

OK, input taken... this will be someting like this..

#define GPS_NAV_CONTROLS_HEADING //Copter heading is controlled by the navigation process, heading towards destination
#deifne GPS_NAV_YAW_REVERSE //Tail towards destination

Really looking forward to testing the i2c gps - keep up the good work.

EOSBandi wrote:OK, input taken... this will be someting like this..

#define GPS_NAV_CONTROLS_HEADING //Copter heading is controlled by the navigation process, heading towards destination
#deifne GPS_NAV_YAW_REVERSE //Tail towards destination

+1

+1

EOSBandi wrote:

jevermeister wrote:Hi,
it should be an option to decide wheter the copter should rotate nose/back to home direction om rth or not.

I use RTH as a panic function to retrieve my copter when I am about to loose it or when I lost orientation.

So for me it would be best to return to me with the nose facing away from me to regain control.

But if you want a cool approch or a cam approch to home you would prefer nose ahead.

OK, input taken... this will be someting like this..

#define GPS_NAV_CONTROLS_HEADING //Copter heading is controlled by the navigation process, heading towards destination
#deifne GPS_NAV_YAW_REVERSE //Tail towards destination

u rock mate!

Hi EOSBandi,
nice to see you back and thanks for your great work!
I'm another one who can't wait for testing of new navigation functions but having 328 based FC and separate I2C GPS board I have to wait for I2C version .
So +1 for it !
Roman

Awesome progress. Looking forward to testing soon.

In pos hold, is it possible to hold orientation in any direction - set by yaw input - for the AP guys...

I think in RTH, having in come in head first or tail first seems the natural way to go.

If this is as good as the GUI - will be great!!

@EOSBandi, thanks for your work on this new NAV thinking! I think you are on the the right course...

I've applied your new functions to dev20120504 (with the library functions APM_PI and AC_PID) and will test in the morning.
As I am using a serial GPS, for debuging the port to dev20120504, I needed to "see" (in the GUI) distance to home and direction to home....
So, in order to serialze the data, I added some original code:

In your GPS_NewData() function...



The GUI will, no doubt, change to suit your new variables, you can then decide how to display them.

Howard.

And, I can now see the benefit of going to I2C for GPS...
My cycle-time has increased from 2800-3200 up to 3100-4500 !

Is anyone, other than Flytron making a I2C GPS board?

My 2 cents:
When the copter reach its holding position, the copter should disable head first(or tail first) in order to avoid spinning around its tail.

dramida wrote:My 2 cents:
When the copter reach its holding position, the copter should disable head first(or tail first) in order to avoid spinning around its tail.

Exactly, in addition to that there must be two sets of navigation controls, one for the pos hold, and one for the navigation between two points. Now as the pos hold is ok, i'll add the second one.

howardhb wrote:And, I can now see the benefit of going to I2C for GPS...
My cycle-time has increased from 2800-3200 up to 3100-4500 !

Is anyone, other than Flytron making a I2C GPS board?

In flight you will not notice the inceased cycle time... (or at least I did not noticed...)

I just want to double check.
I'm working on RTH for Fixed wing and would like to use Gps for altitude, speed and heading.

I find in mwii file.

static int16_t GPS_altitude,GPS_speed; // altitude in 0.1m and speed in 0.1m/s

And in the GPS code.

varptr = (uint8_t *)&GPS_altitude; // altitude in meters for OSD

BaroAlt seems to use cm.
Can anyone confirm if meters is the Unit for GPS?

I found out that it's meters for Gps.

Next question...
Does this mean Gps altitude between 0 & 512 meters?

varptr = (uint8_t *)&GPS_altitude;

In that case this would be more correct.

varptr = (int16_t *)&GPS_altitude;

No,
the gps altitude is an int16, but since we read it out byte by byte, we need a byte pointer, the cast just make sure that the varptr will point to the first byte of the GPS_altitude variable, then we read the first byte to the position where varptr points, and increase the pointer and read the second bye.

Ok Thanks.

A video of Bandi's GPS serial patch working on atmega 328.
It is a big improvement over the MWC 2.0 but isn't perfect yet. Of corse, i played a little with PI velocity controller but those are my best results.

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

Note that alt hold works good, but also, not perfect.

your video is great
i think the code work 1000% better than the old GPS PH Code
Cant wait to test it with my new board (my old board with the Flip proplem is now Totaly Crash)

witch GPS did you use and with how many hz ?

@EOSBandi, today applied your new code (with Library functions APM_PI and AC_PID) to DEV20120504. I think you are on the right track with this way of thinking about NAV...
I flew my copter today and did not notice any difference in flying characteristics, even with cycle time increase.

Positon hold is ok, but I need to tune the PID's.
I found the initial hold good (straight after switching Hold on), but after a minute, slow, lazy oscillation became more and more like over-shoot and over-compensation.
Which parameter should I change first?

I've added the new NAV PID's (HOLD and HOLD_RATE) to EEPROM and also to LCD config.
Now I will be able to easily / quickly tune the parameters

A question about NAV - return to home
The direction that the NAV indicator in the GUI shows.... (see below a snap-shot of GUI when my copter is facing directly towards a memorised HOME position)
Is this correct? (I recall a discussion about TO home or FROM home.....)

Hi,
The gui shows a correct values... toward home and 7 meters.
If it start oscillating then you should lover the HOLD P and increase the D a little bit.. my current parameters for my dev tri are

#define POSHOLD_P .11
#define POSHOLD_I 0.0
#define POSHOLD_IMAX 20 // degrees

#define POSHOLD_RATE_P 1.2 //
#define POSHOLD_RATE_I 0.2 // Wind control
#define POSHOLD_RATE_D 0.005
#define POSHOLD_RATE_IMAX 20 // degrees

It's still not rock solid, but stays within a couple of meters.

Btw, I just pushed a huge update to the repo. Now added navigation PID and RTH speed control with a cross track error correction. Now when RTH is activates it flies direcly towards the home position (controlling only the speed and the bearing) and when approaches the position it slows down and switch to POShold.

Unfortunately the code now is bigger than 32K.
Please note that the last update was not flight tested yet and it's very likely that there are some errors...
A

Yes, I saw your latest pushed update.... Nice!
You're developing it faster than I can adapt it to DEV20120504..... so think I'll stop doing that, for now.
I'm using a MEGA2560, so size is ok.
Thanks! I will try your PID's tomorrow.

LuFa wrote:your video is great
i think the code work 1000% better than the old GPS PH Code
Cant wait to test it with my new board (my old board with the Flip proplem is now Totaly Crash)

witch GPS did you use and with how many hz ?

Thank you, Bandi did the codding, i just film the results.
I was using an NMEA serial GPS @38400 baud and 10 Hz update from an old remzibi OSD (mediatek chipset patch antenna, smd, GTPA010)
I hope that will be a MWC GPS version witch fits on 328 boards also.

howardhb wrote:Yes, I saw your latest pushed update.... Nice!
You're developing it faster than I can adapt it to DEV20120504..... so think I'll stop doing that, for now.
I'm using a MEGA2560, so size is ok.
Thanks! I will try your PID's tomorrow.

Hi ,

Once algorithms are working, i'll adopt it to latest dev (including the i2c_gps) but first I have to have a working code (pos hold is OK now, and i'm closing on the RTH (waypoint navigation)...

Btw, I increased POSHOLD_RATE_D to 0.008 and it's siginificantly better.

Just test code R8, position hold is 'ok, but RTH seems worse than before. Maybe the RTH PID need to adjust more . THe R8 code still can be used on 328 board with serial port GPS ,"Binary sketch size: 28994 bytes (of a 30720 byte maximum)"

EOSBandi, I have tried your "multiwii-gps-work" SVN package and have a few weird issues.

My test copter is a standard home brew flat HEX with a Seedstudio Mega1280 board, FFIMU V2, and serial MTK PA6C GPS. Running the standard MW 2.0 code it flies OK, and the GPS presents data correctly to the WM-GUI.

However, when I load up your code, the GUI shows the GPS # of satellites found, but the course is locked at 180 degrees at 0 Meters to home and does not change. When I attempt to fly (with GPS disabled) it lifts off straight, but then starts spinning around like a top as soon as it lifts off.

I am doing the normal "config.h" settings. Is there something I am missing here?

ygl611 wrote:Just test code R8, position hold is 'ok, but RTH seems worse than before. Maybe the RTH PID need to adjust more . THe R8 code still can be used on 328 board with serial port GPS ,"Binary sketch size: 28994 bytes (of a 30720 byte maximum)"

check r9, there was an error in r8 which prevents the copter to enter into poshold once it arrived home..
Also Nav pid's have to lowered significantly...I flight tested R9 and it's working quite qood. Porting to I2cgps right now.

THere are also some issues when entering into poshold or RTH with too much speed. I still need to work in it... What I recommend for testing RTH, try to minimalise horizontal speed then enter into poshold for a couple seconds, then activate RTH.

BrokenRotor wrote:EOSBandi, I have tried your "multiwii-gps-work" SVN package and have a few weird issues.

My test copter is a standard home brew flat HEX with a Seedstudio Mega1280 board, FFIMU V2, and serial MTK PA6C GPS. Running the standard MW 2.0 code it flies OK, and the GPS presents data correctly to the WM-GUI.

However, when I load up your code, the GUI shows the GPS # of satellites found, but the course is locked at 180 degrees at 0 Meters to home and does not change. When I attempt to fly (with GPS disabled) it lifts off straight, but then starts spinning around like a top as soon as it lifts off.

I am doing the normal "config.h" settings. Is there something I am missing here?

Gui is not updated yet, so it's normal if you not see distance and speed. If it's spinning that means that gps rth is enabled. Check RC settings. And check out R9, I fixed the spinning issue with RTH.

Tried R9, RTH works great!! When activate RTH ,Copter head turns back to home automaticly, It's realy funy and helpful when you get use to this . There is a obviously "brake" when the copter get close to home position(5 or 6 meter), Is it possible to select head to home or tail to home ,even like CF ,no tail or head when copter come home?

very much looking forward to testing this out - will it be relatively simple to do the i2c version once serial is working or is that another huge chunk of work?

any news on win-gui ?

Katch wrote:very much looking forward to testing this out - will it be relatively simple to do the i2c version once serial is working or is that another huge chunk of work?

Not as big as the poshold/rtl code. (I had to re-learn trigonometrics )
I can declare the algorithm finished now. I flew three packs (45min) in light breeze with good poshold and quite good rth. Will push the update R10 to google code and finish the integration to i2c codebase till monday. Then I take a look into winGui and the new serial protocol.
EOSBandi

BTW, What is the consesus? Is it OK to fly the post MW2.0 dev code ?

EOSBandi wrote:
BTW, What is the consesus? Is it OK to fly the post MW2.0 dev code ?

I've flown quite a few packs on the 5th may dev version with i2c GPS enabled (but obviously not with usable RTH or POS) - absolutely no issues with it. I think quite a few other people are flying the latest dev.

Massive thanks and respect for all your work at this time. I wish there was more that I could contribute to the hard parts of this project - I have made some small additions to shared lately though.

Looking forward to trying your i2c code

Katch wrote:

EOSBandi wrote:
BTW, What is the consesus? Is it OK to fly the post MW2.0 dev code ?

I've flown quite a few packs on the 5th may dev version with i2c GPS enabled (but obviously not with usable RTH or POS) - absolutely no issues with it. I think quite a few other people are flying the latest dev.

Massive thanks and respect for all your work at this time. I wish there was more that I could contribute to the hard parts of this project - I have made some small additions to shared lately though.

Looking forward to trying your i2c code

Seconded, Sunday looks fine and dry here,it's a bit cheeky but any chance of I2C GPS by then?

P.s What is the method used to set the home position in your current codebase, is it the Gyro Cal stick combo?

EOSBandi wrote:...

BTW, What is the consesus? Is it OK to fly the post MW2.0 dev code ?

if you mean the 20120430 and newer DEV i will say yes
this DEV is working very well i think. had no problems with both quads.

good work andras !!!

Hi Eosbandi,

Thanks for doing such a great job on the i2c-gps code. Well done! I made a little mod that turns the STATUS light (pin 13) into a GPS lock status light. It:
* blinks once per second if gps is sending data but no position lock yet
* blinks twice fast, then off for a second if gps 2D position is available
* blinks 3 times fast, then off for a second if gps 3D position is available
* or goes on for a second, off for a second, (long pulse) if not getting any NEMA sentences for over 5 seconds

First, add this block before "loop()"


Then add the call to blink_update() to the main loop (like before the watchdog check):


and this line just after the GPS_newFrame() call returns. I had to create a lastframe_time variable so I could know when the last NEMA sentence came through.

So I have the i2c GPS working, using latest R10 eosbandi release, and also using MultiWii 2.0 May5th dev (latest). I configured the GPS HOME and GPS HOLD switched. But I have no idea what those switches actually do? I flight tested and flipped the switches but no response. I cant find info on how to RTH or gps hold.

So if someone can enlighten me:
1. How do we set the HOME position?
2. How do we tell the copter to RTH?

Thanks guys, I am sure it's been answered somewhere in the big list of messages, but I cant find it.

Colin

guru_florida wrote:So I have the i2c GPS working, using latest R10 eosbandi release, and also using MultiWii 2.0 May5th dev (latest). I configured the GPS HOME and GPS HOLD switched. But I have no idea what those switches actually do? I flight tested and flipped the switches but no response. I cant find info on how to RTH or gps hold.

So if someone can enlighten me:
1. How do we set the HOME position?
2. How do we tell the copter to RTH?

Thanks guys, I am sure it's been answered somewhere in the big list of messages, but I cant find it.

Colin

i2c gps does not work with the r10, it's a dev version for testing the algorithms and works only with serial gps. Currently i'm porting it to the i2c gps and to latest dev MultiWii code... stay tuned

Already flash your code.
Changed the DECLINIATION, and some parameter.
Which GUI do you use or can I use?
Is there something special, to test GPS Pos Hold or Return To Home?
Normal switch config?

Thanks
Peter

OK, it's for R10 with serial GPS. Please note again it's a DEV/Proof of Concept so fly it on your own risk

Normal switch config is fine. Use v2.0 gui or 1.04 WinGUI.
I recommend to use headfree mode, in case you lost orientation...

First test poshold then RTH.
Home position is set when copter is armed. So plug your battery and fly to your home position (I recommend at least 5/10 meters away from you) land, disarm and arm again. This sets the home position. Copter must be well trimmed and in level mode. Good mag is also a must, if you can, check your mag orientation with a compass, it must be dead on.

Now takeoff, and try pos hold. It works best if there is minimal horizontal speed when activating. If copter is moving you should exept a couple of swings before copter settles. You can try increasing poshold_rate D only by 0.001-0.002 at a time. If hold is not good enough you can increase P terms, also by 0.01-0.02 at a time. if copter swings or circles thet lower it, or increase D.

Once Poshold is ok, then you can try RTH.
There are three defines which controls orientation during RTH
#define NAV_CONTROLS_HEADING true // copter faces toward the navigation point, maghold must be enabled for it
#define NAV_TAIL_FIRST false // true - copter comes in with tail first
#define NAV_SET_TAKEOFF_HEADING true // true - when copter arrives to home position it rotates it's head to takeoff direction
It's working when magHold is enabled, so if your copter start spinning just disable magHold and take over the yaw. (having headfree mode is very usefull, i managed to bring home a constantly spinning copter during an earlier test)

So fly away some distance and at first try activate poshold, let the copter settle for a couple of seconds, and then activate RTH. With the above settings your copter should turn towards the home point and start approaching. Once it's arrived it will change to a poshold and rotate it's head to the same direction as it was when armed.

I'm progressing with i2c port, expect to have it flight tested during the weekend.

woop woop!

i2c gps does not work with the r10, it's a dev version for testing the algorithms and works only with serial gps. Currently i'm porting it to the i2c gps and to latest dev MultiWii code... stay tuned

I think I misunderstand something. R10 is the release version of the i2c-gps-nav project right? Is it the i2c-gps-nav project that needs updating/porting, or is it the MultiWii algorithms that need updating (to talk to i2c-gps-nav)?

MultiWii reports a good GPS position and approx 9 satellites. Do you mean the MultiWii RTH algorithms only work with a directly connected serial unit (on a Mega)? I have a serial gps (Trimble - Condor C2626) hooked into an atmel running your i2c-gps-nav code (r10), then that hooked into MultiWii using the i2c.

Thanks,
Colin

guru_florida wrote:

i2c gps does not work with the r10, it's a dev version for testing the algorithms and works only with serial gps. Currently i'm porting it to the i2c gps and to latest dev MultiWii code... stay tuned

I think I misunderstand something. R10 is the release version of the i2c-gps-nav project right? Is it the i2c-gps-nav project that needs updating/porting, or is it the MultiWii algorithms that need updating (to talk to i2c-gps-nav)?

MultiWii reports a good GPS position and approx 9 satellites. Do you mean the MultiWii RTH algorithms only work with a directly connected serial unit (on a Mega)? I have a serial gps (Trimble - Condor C2626) hooked into an atmel running your i2c-gps-nav code (r10), then that hooked into MultiWii using the i2c.

Thanks,
Colin

I2C GPS requires code on the Arduino on the GPS board to do all the POS hold and RTH calculations. r10 is only implementing serial GPS at the moment. EOSBandi needs to port that code across to be a stand alone sketch that runs on the I2C GPS board .

Last Edit: I was wrong about R10, my setup was faulty. Excuse me.

Upgrading from R6 to R10 Eos_Bandi GPS serial Nav branch.
The good results of GPS position Hold R6 vanished........................
Hardware:
Crius SE 328 multiwii board with NMEA serial GPS @ 10HZ MediaTek cipset from remzibi OSD and R10 Bandi MWC 2.0 branch.

Hi everybody, i have a quesion. I have this BT GPS module. It is possible to make it working with MWC ? I wanna try features that GPS offers on my hexa, but i dont wanna buy a new GPS module if there is a way to make it works with this BT module. So, it is possible? Thanks.
Jonit

Yes, I used my TinyGPS chip with a bluetooth GPS once. Most BT GPS devices are just plain old serial GPS receivers with an additional BT module slapped on. If you can identify the TTL-TX wire inside the device, you can just use it like any serial GPS.

Tested MWC R10 GPS pos Hold on windy day, it has a maximum error radius about 5. If there is no wind, the results are better.
Also there is a small bug, giro calibration dosen't work anymore if done from the sticks.
Now i am preparing to go on the field and make a few movies with GPS RTH and Pos Hold.

5m at Wind is brilliant !
cant wait to see a video from your PH and RTH

edit : wich GPS Modul did you use ?