Upcoming changes in nav code

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Upcoming changes in nav code

Post by EOSBandi »

HI Folks,

I started to work on the navigation code, Just code completed the mission planner part (which is the most important part) and now comes the code in MultiWii.
I'll collect here those changes in the MW code (including revision numbers) that will impact functionalities of current GUI implementations, to help maintainers of these GUI's. (MSP_SET_WP, MSP_WP command structures, waypoint numbering)
Since MultiWiiConf does not use WP commands, it won't be impacted.

Non developers, please keep away from this topic,it is not for whishes or petitions There is no ETA for the first beta, but there will be a separate topic when first test version became available.

Changes

hold position WP number will be changed to 255 - not commited yet into _shared
The last 1K of the EEPROM will be allocated to missions - not commited yet into _shared

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Upcoming changes in nav code

Post by Hamburger »

EOSBandi wrote:Changes
The last 1K of the EEPROM will be allocated to missions - not commited yet into _shared

this would conflict with the PERMANENT_LOGging of flights data. If you could exclude the last couple of bytes,please?

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

Sure, not yet digged into the EEPROM code, but I plan to use ~700 bytes for the nav (50 waypoints) so it will left the last 300byte intact.

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Upcoming changes in nav code

Post by nhadrian »

Hi,

I suggest to use nr0 for home, nr1 for hold.
Because than any number of WP could be set. So for less WP less memory is needed.

What do you think on my idea that using integers for storing WP datas instead of EEPROM/other attached memory? (can be found in my r22 code).
On this way the chance of having false WP datas couldn't be rest, because all the WP datas would uploaded after power on.

Anyway, it's time to rethink the nav routine, GOOD IDEA!

BR
Adrian

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

nhadrian wrote:Hi,

I suggest to use nr0 for home, nr1 for hold.
Because than any number of WP could be set. So for less WP less memory is needed.

What do you think on my idea that using integers for storing WP datas instead of EEPROM/other attached memory? (can be found in my r22 code).
On this way the chance of having false WP datas couldn't be rest, because all the WP datas would uploaded after power on.

Anyway, it's time to rethink the nav routine, GOOD IDEA!

BR
Adrian


Mission storage must be non-volatile. Storing them in the RAM will tie you to your notebook. We can check the distance of the first WP before starting mission and if it's more than let's say 100meters then don't start the mission. On the other hand RAM is a scarse resource (even on the AtMega2560).
254 waypoint is waaaay more than needed...

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Upcoming changes in nav code

Post by nhadrian »

EOSBandi wrote:
nhadrian wrote:Hi,

I suggest to use nr0 for home, nr1 for hold.
Because than any number of WP could be set. So for less WP less memory is needed.

What do you think on my idea that using integers for storing WP datas instead of EEPROM/other attached memory? (can be found in my r22 code).
On this way the chance of having false WP datas couldn't be rest, because all the WP datas would uploaded after power on.

Anyway, it's time to rethink the nav routine, GOOD IDEA!

BR
Adrian


Mission storage must be non-volatile. Storing them in the RAM will tie you to your notebook. We can check the distance of the first WP before starting mission and if it's more than let's say 100meters then don't start the mission. On the other hand RAM is a scarse resource (even on the AtMega2560).
254 waypoint is waaaay more than needed...


Agree. And also, maybe a flag should be made for storing the number of WPs uploaded last time. It could be checked at every arm, so than it would impossible to call a higher WP number than updated last time.

And what about altitude controller?
The current Multiwii is not capable of any altitude controlling, only can hold current altitude via PID, not more.
I have a basic solution for this purpose, with somne good feedback from users. But MUST be checked and rethinked before committing to MWI.
Anyway, I'm sure some good alt control method is really neccessary for WP navigation.
Since the descending is a problematic flight period, it must be controlled, via some vario based controller.

BR
Adrian

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Upcoming changes in nav code

Post by Hamburger »

EOSBandi wrote:Sure, not yet digged into the EEPROM code, but I plan to use ~700 bytes for the nav (50 waypoints) so it will left the last 300byte intact.

thank you. The struct is about 20 bytes plus the last 4 bytes of eeprom should never be touched in case someone uses those for counting #flashes according to avrdude - so it should be safe even when you extend things over time

cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: Upcoming changes in nav code

Post by cGiesen »

Dear Developers,

I want to put some oil to the fire.
The following question drive me around:
a) I create a list of way points, put them to the FC, start my copter and activate the way point procedure. BUT I#m at an complete different location?
b) There is an altitude flag in way points. I add perhaps 20 but my actual high is 100?
c) I add way points that are far away. What should the be the maximum?
d) Should there be a MAX POINT OF RETURN?

And by the way in germany this is not allowed ;)

Regards
Carsten

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

:D:D

1. If your home position is not within lets say 200 meters of the first waypoint, then the mission wont started
2. Altitude is always relative to home position altitude (not absolute, but AGL)
3. Well, there should be a limit for the farest waypoint in user settings
4. Ho do you define the MAX POINT OF RETURN ?

cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: Upcoming changes in nav code

Post by cGiesen »

1. agreed
2. agreed, but there should be a minimum high?!?!
3. not agreed, because User can do stupid thinks!
4. Thats the problem! Whe have to calculate the way and the time.

Perhaps it's a good idea to have, next to failsafe, a option come home, when you LiPo have only power to come directly home?!?!

And by the way, how fast do we go from one WP to the next,

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

cGiesen wrote:1. agreed
2. agreed, but there should be a minimum high?!?!
3. not agreed, because User can do stupid thinks!
4. Thats the problem! Whe have to calculate the way and the time.

Perhaps it's a good idea to have, next to failsafe, a option come home, when you LiPo have only power to come directly home?!?!

And by the way, how fast do we go from one WP to the next,

Max speed is still governed by the navi settings...

Well, people have the right to be stupid. MultiWii is not a plug and play system and never intended to be so. It is the eyewash that those guys are telling who trying to monetize this project.
If somebody put together a mission which is not flyable and his copter falls, then it is his problem. If somebody override the max distance and his copter lost, then its also his fault and problem.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Upcoming changes in nav code

Post by Sebbi »

cGiesen wrote:And by the way in germany this is not allowed ;)


It is allowed as long as you keep flying line of sight and can take over at ANY point (MultiWii should do both by default). I imagine it is similar in other EU countries. Of course it is not like there is an RC police which constantly monitors such things, but if something happens, well - as EOSBandi put it - "people have the right to be stupid" and it could get expensive pretty fast :D

My suggestions:
- there should be a way to define which way a copter is pointing to while on route to the next waypoint. Either a heading or a point of interest. Ideally this would also take care of gimbal angles (e.g. the point of interest having a height)
- speed should also be setable (not only max speed) in case you want to fly slowly from one point to another
- also take airplanes into account which can't hover in one place, but might achieve far greater speed than copters

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Upcoming changes in nav code

Post by Alexinparis »

Hi,

Some comments on this subject

@EOS: I would be happy if you take the lead on nav code :)

MSP_SET_WP and MSP_WP can be entirely modified, even POS HOLD WP number.
To my knowledge, only ezio apps and yours are impacted by this change, and we always mentioned it’s currently a “temp” code. So no problem.
I think code size constrain should still be a requirement for basic POS HOLD & HOME like today.
I understand the whole WP navigation extension should take much more flash or RAM and could be dedicated to 2560 or more spec procs.
As I understand the need to dedicate a fix portion of EEPROM for permanent log purpose, I see no reason to dedicate a fix portion of EEPROM for nav. Why not take any part following the conf portion ?
I’m agree with this: mission storage must be non-volatile. We should be able to enter a mission and run it later after a power off/on without the ground station. We could imagine a sort of permanent nav conf where the mutli is configured to navigate always on the same field with the same WPs in EEPROM storage.

I don’t think it’s up to MW FC board to check the integrity of WPs (coherent distance/alt/limit/… law topics and so on). This “brain” should stay in the ground station part.
I think EEPROM and communication checksum should be enough to ensure the data integrity.

@Adrian: The ALT & VARIO can be included in WP. But the way to control it is another debate.

cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: Upcoming changes in nav code

Post by cGiesen »

Alexinparis wrote:To my knowledge, only ezio apps and yours are impacted by this change


I finished my Way Point shit 3 Weeks ago.
http://fpv-treff.de/download/file.php?mode=view&id=2904&sid=9e64cf6b6698b80e183de4c74e3cbc1d

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Upcoming changes in nav code

Post by nhadrian »

Hi All,

one short question.
Will the nav development have a unique branch inside MWI code, or will be committed to the MWI_shared?

BR
Adrian

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

nhadrian wrote:Hi All,

one short question.
Will the nav development have a unique branch inside MWI code, or will be committed to the MWI_shared?

BR
Adrian

It will be committed into _shared
(And the RABBIT FC code as usual... :S)

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Upcoming changes in nav code

Post by Hamburger »

:)

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Odp: Upcoming changes in nav code

Post by ezio »

Could you also add a commnad to check if the waypoint is reached?

Bart

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Upcoming changes in nav code

Post by nhadrian »

EOSBandi wrote:It will be committed into _shared
(And the RABBIT FC code as usual... :S)



Unbelievable what they are doing. :(
Why not join us instead of stolen code parts?!?!?!
Maybe they could have good ideas or whatever...

BR
Adrian

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Upcoming changes in nav code

Post by timecop »

Chinese, good ideas? ha ha.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Upcoming changes in nav code

Post by shikra »

Pesky rabbits

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Upcoming changes in nav code

Post by brm »

i am in doubt if this ends up positively... ;)

the angle boost function is one of your latest rip ofs.
not the best at all - causes a lot of sideeffects.
what does the function do when flying upside down?
with the latest development in the esc area not unusual ...

before thinking of doing waypoints you should consider a 3d-box to fly in.
crossing the border of this fence causes the return to home function to kick in.

i am just waiting for a lawyer to get a so called developper in charge.
because the sw does crazy things.

i mean - most of the videos show illegal behaviour.
line in sight means a virtual box to fly in.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

brm.
I admire your work on Naze, but not really tolerate how you communicate. Anyway.

At this moment the copter is not supposed to fly upside down in angle or horizon mode. in rate mode angle boost is disabled.
What other side effects are you thinking of?

Lawyers are supposed to read licenses and will understand what section 16 of the GPL says about limitation of liability.
ATM I'm not interested in the fencing implementation, could be a future development, or a challenge for the Naze guys.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Upcoming changes in nav code

Post by brm »

oscilations causes a problem.
angle mode upside down with the new esc's is ok.
that is even possible for me :)

a no go to me is having multiple actors to manipulate the throttle.
this will confuse altitude hold for example - both control function might/will work against each other.
sooner or later you will have a navigation throttle ...
a human eye will correct small changes in height - no need for a seperate controler.

licensing is not the problem and never will be.
you cannot deny any liabilty just by mentioning it in a license - this is wrong thinking
you should take actions!

i have some experience with bad navigation sw.
therefore a geo fencing box is the first point on the list.
even if it is a stupid function like gps asssisted altutide hold.

if i see more of these cloud surfing fpv videos, then i can imagine that only sealed firmware is allowed.
means the end of creating sw ...
if i am right, then there are locations where flying is only allowed with gps loggers.
or in pre-defined areas.

as usual - security is for others bur not for me.
a copter is not a toy.

a few days ago i completed the work on a mavlink connection.
will see what is better ...

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Upcoming changes in nav code

Post by Hamburger »

brm wrote:i am in doubt if this ends up positively... ;)

the angle boost function is one of your latest rip ofs.
not the best at all - causes a lot of sideeffects.
what does the function do when flying upside down?
with the latest development in the esc area not unusual ...

If you do not like it then do not activate it.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Upcoming changes in nav code

Post by brm »

it is not a question of not liking it but security.
multiple controlers are a pain.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Upcoming changes in nav code

Post by Hamburger »

a no go to me is having multiple actors to manipulate the throttle.

Your choice. Many pilots enjoy using a governor for helis. Activating acc+mag will influence motor outputs. In all those cases it requires a conscious effort to enable a feature. When I buy a freshly brewed coffee in my world people expect it to be hot. Good enough for me. Lawyers may think differently.

it is not a question of not liking it but security.
multiple controllers are a pain

I will not engage in a discussion about pain through hardware choice and layout.
The whole multicopter thing is a security issue all the way (for evidence see photos of smashed fingers from calibrating ESCs the wrong way - copter has not even flown by then). No software could take the burden of responsible considerate use of the copter away from the pilot.

@EOSbandi
sorry for the off topic rant. I will stop now. Back to nav code.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Upcoming changes in nav code

Post by brm »

thanks!
btw, the talk is about sw controlers.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

OK,
So EEPROM usage will be calculated at compile time, based on the number of configuration profiles and PLOG usage, So no need to track and recalculate when the conf structure (or the plog) changing.
WPs will take up the avail space between the conf profiles and the plog. The max number of possible waypoints is going to be communicated to the GUI. Upper limit is 254.

code for checking space for WP-s is something like this.

Code: Select all

uint8_t getMaxWPNumber() {
#ifdef LOG_PERMANENT
    #define PLOG_SIZE sizeof(plog)
#else
    #define PLOG_SIZE 0
#endif
#ifdef MULTIPLE_CONFIGURATION_PROFILES
    #define PROFILES 3
#else
   #define PROFILES 1
#endif

   uint16_t first_avail = PROFILES*sizeof(conf) + sizeof(global_conf)+ 1; //Add one byte for addtnl separation
   uint16_t last_avail  = E2END - PLOG_SIZE - 2;                                //keep the last 2 bytes intakt
   uint16_t wp_num = (last_avail-first_avail)/sizeof(wp);
   if (wp_num>254) wp_num = 254;
   return wp_num;
}

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Upcoming changes in nav code

Post by Hamburger »

from avrdude man page:
-y Tells avrdude to use the last four bytes of the connected parts' EEPROM
memory to track the number of times the device has been erased. When

I will move the default for LOG_PERMANENT to accomodate that as well.
I am not sure whether your code would take that into consideration already - just saw one comment stating keep the last 2 bytes intakt - not sure if related at all.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

Hamburger wrote:from avrdude man page:
-y Tells avrdude to use the last four bytes of the connected parts' EEPROM
memory to track the number of times the device has been erased. When

I will move the default for LOG_PERMANENT to accomodate that as well.
I am not sure whether your code would take that into consideration already - just saw one comment stating keep the last 2 bytes intakt - not sure if related at all.


So it has to be four bytes instead of two... ok, i'll change that. Did you consider using the E2END definition instead of directly entering memory addresses into config.h ?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Upcoming changes in nav code

Post by Hamburger »

EOSBandi wrote:Did you consider using the E2END definition instead of directly entering memory addresses into config.h ?

No. I do not know about E2END. Does it get set for all relevant mcu types, I presume? For 328p would E2END equal 1023 or 1024?

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: Upcoming changes in nav code

Post by Mis »

Simply use formula:
E2END - 4 - sizeof(plog) and you get right start address for pllog writing independent of mcu type, and last 4 bytes of eeprom should be free.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Upcoming changes in nav code

Post by Hamburger »

ok, will do. Thank you.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

First commit...
updated EEPROM.INO... more updates fill come...
dev goes slower than expected, since i have to dev three codes in paralell (MW, GUI, I2C)

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Upcoming changes in nav code

Post by Sebbi »

Either my script failed or this commit breaks compilation ... hmmm http://sebbi.de/multiwii/

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Upcoming changes in nav code

Post by EOSBandi »

Sebbi wrote:Either my script failed or this commit breaks compilation ... hmmm http://sebbi.de/multiwii/

Sorry, fixed

Post Reply