New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flight - Add GPS waypoint support #530

Closed
matbogdan79 opened this Issue Feb 19, 2015 · 52 comments

Comments

Projects
None yet
@matbogdan79

Please consider implementing GPS waypoints so we can build a fly patern with our drones.

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Feb 22, 2015

Contributor

@hydra, just curious, what's the state of GPS right now? I asked a couple of months ago and someone mentioned that the entire stack was being rewritten by someone (just slowly/casually), but I think that was just so that RTH was more stable/better and to clean up some messy math.

Have waypoints and/or other pixhawk-like features been discussed? Is there even enough leftover CPU power to do it? (ie, how much time does the naze spend idling when the cycle time is set to 3500)

Contributor

dkisselev commented Feb 22, 2015

@hydra, just curious, what's the state of GPS right now? I asked a couple of months ago and someone mentioned that the entire stack was being rewritten by someone (just slowly/casually), but I think that was just so that RTH was more stable/better and to clean up some messy math.

Have waypoints and/or other pixhawk-like features been discussed? Is there even enough leftover CPU power to do it? (ie, how much time does the naze spend idling when the cycle time is set to 3500)

@matbogdan79

This comment has been minimized.

Show comment
Hide comment
@matbogdan79

matbogdan79 Feb 22, 2015

Processing GPS should be not a problem for naze32. GPS usually update 5 times per second possition from what I know.
Considering there has been implementations of GPS waypoints on poor arduino, should be no trouble with processing power to implement in a 32 bit modern processor.

Also there are many I2C GPS devices ( i have one from my ex arduino multiwii ) that should be supported. I think there is a way to make the secondary arduino that do the I2C connection to do all the processing required for GPS and just give the results to naze32 already processed.
So, devs. should first consider adding support for I2C GPS than go to GPS waypoints and so on.

Processing GPS should be not a problem for naze32. GPS usually update 5 times per second possition from what I know.
Considering there has been implementations of GPS waypoints on poor arduino, should be no trouble with processing power to implement in a 32 bit modern processor.

Also there are many I2C GPS devices ( i have one from my ex arduino multiwii ) that should be supported. I think there is a way to make the secondary arduino that do the I2C connection to do all the processing required for GPS and just give the results to naze32 already processed.
So, devs. should first consider adding support for I2C GPS than go to GPS waypoints and so on.

@bcdebusk

This comment has been minimized.

Show comment
Hide comment
@bcdebusk

bcdebusk Feb 26, 2015

GPS Waypoints and RTL should not be that difficult, but many designs need the magnetometer on a mast to sit above all the electrical noise. I can't find the answer to two questions:

  1. Is the I2C bus used by the on-board HMC5883L magnetometer the same I2C bus as exposed on pads located on the underside of the Naze32 Rev 5 board? If they aren't, users should be able to purchase a commonly available GPS + HMC5883L magnetometer combination (CGS Shop has them) and just direct the compass reads to the other I2C bus. The GPS would still use the serial connection.

  2. If they are sharing the same bus, a steady hand could cut the SDA trace on the on-board HMC5883L, and connect the GPS + compass combo in the same was as described in (2).

Has anyone played with this? Ideally a Naze32 Rev6 board would just have a jumper block that allowed for an external compass. I'm a huge fan of RTL because I don't care how good of a pilot you are, we've all lost orientation or sight of our vehicles before. Being able to simply flip a switch and know your investment is coming home is a critical feature.

GPS Waypoints and RTL should not be that difficult, but many designs need the magnetometer on a mast to sit above all the electrical noise. I can't find the answer to two questions:

  1. Is the I2C bus used by the on-board HMC5883L magnetometer the same I2C bus as exposed on pads located on the underside of the Naze32 Rev 5 board? If they aren't, users should be able to purchase a commonly available GPS + HMC5883L magnetometer combination (CGS Shop has them) and just direct the compass reads to the other I2C bus. The GPS would still use the serial connection.

  2. If they are sharing the same bus, a steady hand could cut the SDA trace on the on-board HMC5883L, and connect the GPS + compass combo in the same was as described in (2).

Has anyone played with this? Ideally a Naze32 Rev6 board would just have a jumper block that allowed for an external compass. I'm a huge fan of RTL because I don't care how good of a pilot you are, we've all lost orientation or sight of our vehicles before. Being able to simply flip a switch and know your investment is coming home is a critical feature.

@hydra

This comment has been minimized.

Show comment
Hide comment
@hydra

hydra Feb 26, 2015

Contributor

Let's keep this conversation specifically about GPS Waypoint support. Discuss sensors in other topics please.

Good GPS PH is key, once that is better we can start getting all fancy with RTH and Waypoints.

Blocking this until GPS PH is improved, see #197

Contributor

hydra commented Feb 26, 2015

Let's keep this conversation specifically about GPS Waypoint support. Discuss sensors in other topics please.

Good GPS PH is key, once that is better we can start getting all fancy with RTH and Waypoints.

Blocking this until GPS PH is improved, see #197

@hydra hydra added the blocked label Feb 26, 2015

@hydra

This comment has been minimized.

Show comment
Hide comment
@hydra

hydra Feb 26, 2015

Contributor

Please also search and comment on the other topics before starting new topics too since there is much duplication in the tickets right now.

See #61 #197 #270 #363 #251 #113 #234 #251 #476 #490

Contributor

hydra commented Feb 26, 2015

Please also search and comment on the other topics before starting new topics too since there is much duplication in the tickets right now.

See #61 #197 #270 #363 #251 #113 #234 #251 #476 #490

@bcdebusk

This comment has been minimized.

Show comment
Hide comment
@bcdebusk

bcdebusk Feb 27, 2015

My apologies.

Is there a specific thread I could go to and address the separation of the on-board HMC5883L and the integration of an alternative one on a mast? I am inherently distrustful of a magnetometer buried between two sheets of carbon fiber and mounted below a fairly large battery.

I have an extra Naze32 Rev5 board and am thinking about doing the trace-cutting and magnetometer spoofing proposed above. I have the CGS Shop M8 with integrated HMC5883L handy, I just don't want to run a fool's errand if there is something I'm overlooking here. Any insight would be appreciated.

My apologies.

Is there a specific thread I could go to and address the separation of the on-board HMC5883L and the integration of an alternative one on a mast? I am inherently distrustful of a magnetometer buried between two sheets of carbon fiber and mounted below a fairly large battery.

I have an extra Naze32 Rev5 board and am thinking about doing the trace-cutting and magnetometer spoofing proposed above. I have the CGS Shop M8 with integrated HMC5883L handy, I just don't want to run a fool's errand if there is something I'm overlooking here. Any insight would be appreciated.

@hydra hydra changed the title from GPS waypoints to Flight - Add GPS waypoint support May 15, 2015

@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Aug 2, 2015

@hydra What's the state now of the waypoint support on the naze32?

@hydra What's the state now of the waypoint support on the naze32?

@alvins82

This comment has been minimized.

Show comment
Hide comment
@alvins82

alvins82 Aug 2, 2015

An FYI - there is a GPS re-write taking place in this branch - https://github.com/digitalentity/cleanflight/tree/navigation-rewrite

alvins82 commented Aug 2, 2015

An FYI - there is a GPS re-write taking place in this branch - https://github.com/digitalentity/cleanflight/tree/navigation-rewrite

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Aug 11, 2015

Contributor

No, @digitalentity is working on re-writing the Cleanflight navigation stack so that position hold and return to home work better. The code-in-progress is available in his fork in the branch linked above.

Cleanflight currently does not support waypoints, but once the forked changes are merged in, it will be much easier to add that support if the demand and developer resources are there (the current code is too messy, but the rewrite is taking the long-term goal of waypoints into consideration)

So to answer your question, the current support does not exist, but work is being done towards maybe getting it in some number of months (First the core rewrite needs to be done, then the waypoint support needs to be added).

My barely guess is around 6 months from now for waypoints since most people working on this project are volunteers with dayjobs, but I mostly made that number up so don't count on it. Might be sooner, might be later, might be never.

Contributor

dkisselev commented Aug 11, 2015

No, @digitalentity is working on re-writing the Cleanflight navigation stack so that position hold and return to home work better. The code-in-progress is available in his fork in the branch linked above.

Cleanflight currently does not support waypoints, but once the forked changes are merged in, it will be much easier to add that support if the demand and developer resources are there (the current code is too messy, but the rewrite is taking the long-term goal of waypoints into consideration)

So to answer your question, the current support does not exist, but work is being done towards maybe getting it in some number of months (First the core rewrite needs to be done, then the waypoint support needs to be added).

My barely guess is around 6 months from now for waypoints since most people working on this project are volunteers with dayjobs, but I mostly made that number up so don't count on it. Might be sooner, might be later, might be never.

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Aug 12, 2015

Contributor

@louisdelooze
Indeed, there is no waypoint support in CleanFlight yet. My nav-rewrite will soon reach "flyable" milestone - that would mean that poshold, althold and return-to-lauch is working. After that I'll start working on improvements - waypoint support is one of my long-term goals. Development speed in my case is mostly dependent on ability to flight-test the changes. Currently https://github.com/digitalentity/cleanflight/issues/4 is a priority. If you wish to help, please write a comment, I'll give you a hex-file to flash and test.

Contributor

digitalentity commented Aug 12, 2015

@louisdelooze
Indeed, there is no waypoint support in CleanFlight yet. My nav-rewrite will soon reach "flyable" milestone - that would mean that poshold, althold and return-to-lauch is working. After that I'll start working on improvements - waypoint support is one of my long-term goals. Development speed in my case is mostly dependent on ability to flight-test the changes. Currently https://github.com/digitalentity/cleanflight/issues/4 is a priority. If you wish to help, please write a comment, I'll give you a hex-file to flash and test.

@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Aug 12, 2015

@digitalentity i'l like to help en test, is there any risk of using a beta code, I mean that my drone fly's away or something else?

@digitalentity i'l like to help en test, is there any risk of using a beta code, I mean that my drone fly's away or something else?

@smiling-Jack

This comment has been minimized.

Show comment
Hide comment
@smiling-Jack

smiling-Jack Aug 12, 2015

I am also interested for testing.
Hardware is Flip32 with NEO-8M

Edit: SP racing F3 Deluxe is on the way

I am also interested for testing.
Hardware is Flip32 with NEO-8M

Edit: SP racing F3 Deluxe is on the way

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Aug 13, 2015

Contributor

@louisdelooze, @smiling-Jack
Please grab the latest HEX (currently cleanflight_NAZE.navigation-rewrite.Aug12) here: https://www.dropbox.com/sh/4r5374mos7471q2/AACppn0Mphw45p-4TJ7lZLlOa?dl=0
Currenty finding new default values for PIDALT, PIDVEL, PIDPOS, PIDPOSR are a priority.

A BIG WARNING FOR TESTERS! The current code is in "beta" stage, it might not work as expected (might crash, might attemt to fly-away), so execute extreame caution and be prepared to switch to manual control at all times. Also trying the new code at low altitudes and over some firm grass is a good idea. Also, a cood compass calibration is a "must do" thing. NAV_PH mode won't activate

Contributor

digitalentity commented Aug 13, 2015

@louisdelooze, @smiling-Jack
Please grab the latest HEX (currently cleanflight_NAZE.navigation-rewrite.Aug12) here: https://www.dropbox.com/sh/4r5374mos7471q2/AACppn0Mphw45p-4TJ7lZLlOa?dl=0
Currenty finding new default values for PIDALT, PIDVEL, PIDPOS, PIDPOSR are a priority.

A BIG WARNING FOR TESTERS! The current code is in "beta" stage, it might not work as expected (might crash, might attemt to fly-away), so execute extreame caution and be prepared to switch to manual control at all times. Also trying the new code at low altitudes and over some firm grass is a good idea. Also, a cood compass calibration is a "must do" thing. NAV_PH mode won't activate

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Aug 13, 2015

Contributor

A new hex file is available - cleanflight_NAZE.navigation-rewrite.Aug13.hex
Now new PID and config defaults. Did several flights with this hex and new PIDs - all seem to work fine on my setup. Please test and report your findings.

Contributor

digitalentity commented Aug 13, 2015

A new hex file is available - cleanflight_NAZE.navigation-rewrite.Aug13.hex
Now new PID and config defaults. Did several flights with this hex and new PIDs - all seem to work fine on my setup. Please test and report your findings.

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Aug 13, 2015

Contributor

Just curious, while we're on this topic,

Have any of you thought about how we are going to implement waypoints?

@digitalentity has a PR(#806) open that implements minimal mavlink, I figure we could expand that to include the GPS/waypoint commands, but is that the intended direction? Mavlink would probably be the best solution as a first-pass because there's already a lot of apps and infrastructure around it.

But the goal of Cleanflight isn't really to clone everything that APM is doing, so if we were to do it ourselves (possibly as part of MSP), what could we do better/differently?

Edit:

Upon reviewing the docs, MSP already has support for sending upto 16 waypoints to the FC. I'm not sure if we've implemented those function calls, but the protocol has the commands and message ID's set aside already.

Unfortunately, the other problem of lack of infrastructure still stands. The way I see it, it shouldn't be hard to implement Mavlink waypoints first to make use of existing apps, and add support for MSP as new cleanflight-compatible apps are written, but I just threw this out there to see if anyone else had cool ideas.

Contributor

dkisselev commented Aug 13, 2015

Just curious, while we're on this topic,

Have any of you thought about how we are going to implement waypoints?

@digitalentity has a PR(#806) open that implements minimal mavlink, I figure we could expand that to include the GPS/waypoint commands, but is that the intended direction? Mavlink would probably be the best solution as a first-pass because there's already a lot of apps and infrastructure around it.

But the goal of Cleanflight isn't really to clone everything that APM is doing, so if we were to do it ourselves (possibly as part of MSP), what could we do better/differently?

Edit:

Upon reviewing the docs, MSP already has support for sending upto 16 waypoints to the FC. I'm not sure if we've implemented those function calls, but the protocol has the commands and message ID's set aside already.

Unfortunately, the other problem of lack of infrastructure still stands. The way I see it, it shouldn't be hard to implement Mavlink waypoints first to make use of existing apps, and add support for MSP as new cleanflight-compatible apps are written, but I just threw this out there to see if anyone else had cool ideas.

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Aug 13, 2015

Contributor

@dkisselev FYI, there is already an MSP_SET_WP command to upload waypoints to CF. Currently this command mostly does nothing. I'm planning on implementing a function to get/set waypoints as a part of my nav code. How waypoints should work in general is one questions. How this to-be-done function will be exposed to the outside of flight controller is a totally different question. To get things right, we must think about both.

Contributor

digitalentity commented Aug 13, 2015

@dkisselev FYI, there is already an MSP_SET_WP command to upload waypoints to CF. Currently this command mostly does nothing. I'm planning on implementing a function to get/set waypoints as a part of my nav code. How waypoints should work in general is one questions. How this to-be-done function will be exposed to the outside of flight controller is a totally different question. To get things right, we must think about both.

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Aug 13, 2015

Contributor

Yeah, I made an edit as I realized a few of those things.

The big downside to MSP WP is that it's limited to 16 waypoints as far as I can tell, and also doesn't support waypoint types (such as spline flight paths), but I'm basing this off of the original Multiwii wiki doc which might not be synced up to what were doing. (have we been expanding on/fiddling with the MSP protocol)

Contributor

dkisselev commented Aug 13, 2015

Yeah, I made an edit as I realized a few of those things.

The big downside to MSP WP is that it's limited to 16 waypoints as far as I can tell, and also doesn't support waypoint types (such as spline flight paths), but I'm basing this off of the original Multiwii wiki doc which might not be synced up to what were doing. (have we been expanding on/fiddling with the MSP protocol)

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Aug 13, 2015

Contributor

Waypoint number in MSP_SET_WP is an uint8_t, we could have up to 256 waypoints or perhaps use several higher bits as a waypoint type. The protocol also has a dedicated uint8_t for flags. We can reuse this. I think I'll drop MAVLink in favor of LTM-telemetry (much smaller footprint). We are already short on flash on most targets, I don't think we should bloat the code with something only few people would ever use. We can stay with MSP WP and make a hardware/software MAVLink/MSP proxy for waypoint protocol.

Contributor

digitalentity commented Aug 13, 2015

Waypoint number in MSP_SET_WP is an uint8_t, we could have up to 256 waypoints or perhaps use several higher bits as a waypoint type. The protocol also has a dedicated uint8_t for flags. We can reuse this. I think I'll drop MAVLink in favor of LTM-telemetry (much smaller footprint). We are already short on flash on most targets, I don't think we should bloat the code with something only few people would ever use. We can stay with MSP WP and make a hardware/software MAVLink/MSP proxy for waypoint protocol.

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Aug 13, 2015

Contributor

Sounds great, thanks again for all your contributions.

Just an FYI in case you haven't seen this before, people have used Arduino nanos to convert mavlink to FrSky Telemetry. We would probably need two-way conversion, but these sketches might give us a decent groundwork for at least reading and parsing mavlink packets.

https://github.com/kwikius/mavlink_to_frsky

Contributor

dkisselev commented Aug 13, 2015

Sounds great, thanks again for all your contributions.

Just an FYI in case you haven't seen this before, people have used Arduino nanos to convert mavlink to FrSky Telemetry. We would probably need two-way conversion, but these sketches might give us a decent groundwork for at least reading and parsing mavlink packets.

https://github.com/kwikius/mavlink_to_frsky

@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Aug 13, 2015

@digitalentity I have just a question about the modes in cleanflight, Is NAV ALTHOLDthe same as Barometer, because I don't see the barometer option.
Another question, I see the Nav WP option, so if I upload some waypoints will it work ?

What should I use for the modes ? For testing.

@digitalentity I have just a question about the modes in cleanflight, Is NAV ALTHOLDthe same as Barometer, because I don't see the barometer option.
Another question, I see the Nav WP option, so if I upload some waypoints will it work ?

What should I use for the modes ? For testing.

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Aug 13, 2015

Contributor

If I remember correctly, althold is a combination of Baro and Sonar alt hold. It'll use the sonar when lower down and switch to Baro once that's out of range.

There is no code what-so-ever that does waypoint navigation, so it will not work. The mode was probably written in just to implement that feature of the Multiwii protocol, but we don't have anything there right now. At best it will do nothing, at worst it will crash or flyaway.

-------- Original Message --------
From: louisdelooze notifications@github.com
Sent: Thursday, August 13, 2015 08:48 AM
To: cleanflight/cleanflight cleanflight@noreply.github.com
Subject: Re: [cleanflight] Flight - Add GPS waypoint support (#530)
CC: Denis Kisselev denis@dkisselev.net

@digitalentityhttps://github.com/digitalentity I have just a question about the modes in cleanflight, Is NAV ALTHOLDthe same as Barometer, because I don't see the barometer option.
Another question, I see the Nav WP option, so if I upload some waypoints will it work ?

Reply to this email directly or view it on GitHubhttps://github.com/cleanflight/cleanflight/issues/530#issuecomment-130734768.

Contributor

dkisselev commented Aug 13, 2015

If I remember correctly, althold is a combination of Baro and Sonar alt hold. It'll use the sonar when lower down and switch to Baro once that's out of range.

There is no code what-so-ever that does waypoint navigation, so it will not work. The mode was probably written in just to implement that feature of the Multiwii protocol, but we don't have anything there right now. At best it will do nothing, at worst it will crash or flyaway.

-------- Original Message --------
From: louisdelooze notifications@github.com
Sent: Thursday, August 13, 2015 08:48 AM
To: cleanflight/cleanflight cleanflight@noreply.github.com
Subject: Re: [cleanflight] Flight - Add GPS waypoint support (#530)
CC: Denis Kisselev denis@dkisselev.net

@digitalentityhttps://github.com/digitalentity I have just a question about the modes in cleanflight, Is NAV ALTHOLDthe same as Barometer, because I don't see the barometer option.
Another question, I see the Nav WP option, so if I upload some waypoints will it work ?

Reply to this email directly or view it on GitHubhttps://github.com/cleanflight/cleanflight/issues/530#issuecomment-130734768.

@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Aug 13, 2015

@dkisselev Should I use althold for RTH and for POSHOLD ?

@dkisselev Should I use althold for RTH and for POSHOLD ?

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Aug 13, 2015

Contributor

Digitalentity will have to answer that one for Poshold, but RTH should take over altitude control without you needing to engage althold.

Contributor

dkisselev commented Aug 13, 2015

Digitalentity will have to answer that one for Poshold, but RTH should take over altitude control without you needing to engage althold.

@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Aug 13, 2015

@digitalentity What will precisely be activated with NAV ALTHOLD and do i need to use it with NAV RTH

@digitalentity What will precisely be activated with NAV ALTHOLD and do i need to use it with NAV RTH

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Aug 13, 2015

Contributor

@louisdelooze, @dkisselev
I've removed sonar support at the moment, but in nearest future NAV ALTHOLD will take all available sources of altitude. Barometer is manadatory, sonar will be optional.
NAV WP is there for future support of waypoints, this mode currently does nothing.
NAV ALTHOLD will hold only altitude
NAV POSHOLD will hold only horizontal position, to get a full position hold in 3d-space, you need to activate both ALTHOLD and POSHOLD.
NAV RTH is a stand-alone mode, it takes care of altitude on its own.

There is also no need to acticate any other modes (MAG, ANGLE whatever), the firmware will take care of that on its own. I.e. if you need to get your copter back - activate RTH, that's it.

Sensors, required for all this to work:
for ALTHOLD: barometer
for POSHOLD: barometer, gps, accelerometer, compass
for RTH: same as for POSHOLD

Contributor

digitalentity commented Aug 13, 2015

@louisdelooze, @dkisselev
I've removed sonar support at the moment, but in nearest future NAV ALTHOLD will take all available sources of altitude. Barometer is manadatory, sonar will be optional.
NAV WP is there for future support of waypoints, this mode currently does nothing.
NAV ALTHOLD will hold only altitude
NAV POSHOLD will hold only horizontal position, to get a full position hold in 3d-space, you need to activate both ALTHOLD and POSHOLD.
NAV RTH is a stand-alone mode, it takes care of altitude on its own.

There is also no need to acticate any other modes (MAG, ANGLE whatever), the firmware will take care of that on its own. I.e. if you need to get your copter back - activate RTH, that's it.

Sensors, required for all this to work:
for ALTHOLD: barometer
for POSHOLD: barometer, gps, accelerometer, compass
for RTH: same as for POSHOLD

@varoudis

This comment has been minimized.

Show comment
Hide comment
@varoudis

varoudis Aug 14, 2015

@digitalentity i might be able to help you as im plannin to work with cleanflight on indoor navigation. Sonar and depth camera assisted.
Maybe we could have a chat about your targets, ideas and plans so i might give you a bit of help.

Tasos

@digitalentity i might be able to help you as im plannin to work with cleanflight on indoor navigation. Sonar and depth camera assisted.
Maybe we could have a chat about your targets, ideas and plans so i might give you a bit of help.

Tasos

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Aug 14, 2015

Contributor

@varoudis, have you heard of/seen Optical Flow sensors? They're the easiest solution to holding position indoors.

You won't be able to navigate on OF, but that in itself is a huge task that would need to be developed completely from scratch and require specialized software every step of the way.

Optical flow sensors offload all of the positional tracking data and just return a vector for where the craftvhas moved in the last time period, this will make ot rrally easy to integrate into the navigation stack once that's complete.

Contributor

dkisselev commented Aug 14, 2015

@varoudis, have you heard of/seen Optical Flow sensors? They're the easiest solution to holding position indoors.

You won't be able to navigate on OF, but that in itself is a huge task that would need to be developed completely from scratch and require specialized software every step of the way.

Optical flow sensors offload all of the positional tracking data and just return a vector for where the craftvhas moved in the last time period, this will make ot rrally easy to integrate into the navigation stack once that's complete.

@varoudis

This comment has been minimized.

Show comment
Hide comment
@varoudis

varoudis Aug 14, 2015

@dkisselev I;ve never seen a dedicated OF camera but I have done OF with openCV in the past.
My project is a bit bigger than holing position. Overall Im aiming for autonomous movement but breaking up this project into pieces it probably has some common areas with function that exist in CF or @digitalentity might be working on.

Ill check for OF cameras though! There is also one little 360 laser scanner that I;ve seen building 'isovists' on the fly!

screen-shot-2012-10-15-at-10 46 45

My very 'alpha' plan is to use sonar for all but forward facing and some depth camera (some PI2 or something is also needed of course, no sure yet).

Ideas and tips for nice and cheap sensors/hardware are more than welcome.

Thanks
Tasos

@dkisselev I;ve never seen a dedicated OF camera but I have done OF with openCV in the past.
My project is a bit bigger than holing position. Overall Im aiming for autonomous movement but breaking up this project into pieces it probably has some common areas with function that exist in CF or @digitalentity might be working on.

Ill check for OF cameras though! There is also one little 360 laser scanner that I;ve seen building 'isovists' on the fly!

screen-shot-2012-10-15-at-10 46 45

My very 'alpha' plan is to use sonar for all but forward facing and some depth camera (some PI2 or something is also needed of course, no sure yet).

Ideas and tips for nice and cheap sensors/hardware are more than welcome.

Thanks
Tasos

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Aug 14, 2015

Contributor

Optical flow is a sensor you point at the ground the tracks floor patterns to maintain position and accurately move in 2D space. There are a few semi-commercial models out, here's a summary page from Ardupilot that might help: http://copter.ardupilot.com/wiki/common-optional-hardware/common-optical-flow-sensors-landingpage/

This discussion is technically off-topic for this issue, so we shouldn't continue it here, but I'll leave some additional information for you, and feel free to send me an email if you'd like to chat about it further (my email's on my profile).

Cleanflight overall is pretty rudimentary, even once waypoints are implemented, the best you will get out of CF is the ability to tell it to "fly to this coordinate, go", so it doesn't sound like it will match your needs.

Have you looked at Pixhawk? It's a much more powerful controller that will let you plug in any sensors you could ever need, and has a framework already in-place that lets you execute arbitrary code and alter its functions based on your logic. Here's a "hello world" example from their dev pages: https://pixhawk.org/dev/px4_simple_app.

Basically, with Cleanflight, all you get is flight control and some basic automaton of "fly to here", but with PIxhawk you can do anything from controlling the output to a single motor, to executing custom logic and telling it to navigate to certain places, fly in certain ways, or do anything else you wish do to.

Edit: If you search around, there have also been a lot of efforts already made to do indoor positioning with Pixhawk, here's one example: https://pixhawk.ethz.ch/software/computer_vision/flight

Contributor

dkisselev commented Aug 14, 2015

Optical flow is a sensor you point at the ground the tracks floor patterns to maintain position and accurately move in 2D space. There are a few semi-commercial models out, here's a summary page from Ardupilot that might help: http://copter.ardupilot.com/wiki/common-optional-hardware/common-optical-flow-sensors-landingpage/

This discussion is technically off-topic for this issue, so we shouldn't continue it here, but I'll leave some additional information for you, and feel free to send me an email if you'd like to chat about it further (my email's on my profile).

Cleanflight overall is pretty rudimentary, even once waypoints are implemented, the best you will get out of CF is the ability to tell it to "fly to this coordinate, go", so it doesn't sound like it will match your needs.

Have you looked at Pixhawk? It's a much more powerful controller that will let you plug in any sensors you could ever need, and has a framework already in-place that lets you execute arbitrary code and alter its functions based on your logic. Here's a "hello world" example from their dev pages: https://pixhawk.org/dev/px4_simple_app.

Basically, with Cleanflight, all you get is flight control and some basic automaton of "fly to here", but with PIxhawk you can do anything from controlling the output to a single motor, to executing custom logic and telling it to navigate to certain places, fly in certain ways, or do anything else you wish do to.

Edit: If you search around, there have also been a lot of efforts already made to do indoor positioning with Pixhawk, here's one example: https://pixhawk.ethz.ch/software/computer_vision/flight

@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Aug 14, 2015

Just a question, is for example the camera underneath the Ar Drone 2.0 from
parrot used to guard the position ?

Just a question, is for example the camera underneath the Ar Drone 2.0 from
parrot used to guard the position ?

@varoudis

This comment has been minimized.

Show comment
Hide comment
@varoudis

varoudis Aug 14, 2015

@dkisselev thanks for the info, more on this off-list.
I like something simple like CF. Ill code the rest myself as I need to build my own experimentation platform for a number of 'theory' tests.
Thats what I do in my everyday work :) (check my other github projects)
Tasos

@dkisselev thanks for the info, more on this off-list.
I like something simple like CF. Ill code the rest myself as I need to build my own experimentation platform for a number of 'theory' tests.
Thats what I do in my everyday work :) (check my other github projects)
Tasos

@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Aug 15, 2015

I did some testing.. After a number of tries it works better than the last
stable one.

But now I have a question, if I manualy change the throttle what will the
fc do
?

I did some testing.. After a number of tries it works better than the last
stable one.

But now I have a question, if I manualy change the throttle what will the
fc do
?

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Aug 15, 2015

Contributor
Contributor

digitalentity commented Aug 15, 2015

@sppnk

This comment has been minimized.

Show comment
Hide comment
@sppnk

sppnk Aug 21, 2015

Contributor

@digitalentity thanks for your efforts in this development.

When you say:

"Sensors, required for all this to work:
for ALTHOLD: barometer
for POSHOLD: barometer, gps, accelerometer, compass
for RTH: same as for POSHOLD"

I think you refer to multicopters, but what for AIRPLANE? In original 8bits MultiWii (now 2.4), there is a branch form PatrikE that supports RTH for airplane, without baro and compass. I think he has made the same thing for Baseflight. For Fixedwings there is no necessary the precision of barometer, you could take the value from GPS readings.

I would be a great thing if you could implement RTH for airplanes, so we could have it in next versión (1.10?) of CF.

This is because there are some really cheap 32bit controllers w/o baro and mag that would be great for our airplanes (as CC3D). Having them with RTH also... uhhhh

Thx.

Contributor

sppnk commented Aug 21, 2015

@digitalentity thanks for your efforts in this development.

When you say:

"Sensors, required for all this to work:
for ALTHOLD: barometer
for POSHOLD: barometer, gps, accelerometer, compass
for RTH: same as for POSHOLD"

I think you refer to multicopters, but what for AIRPLANE? In original 8bits MultiWii (now 2.4), there is a branch form PatrikE that supports RTH for airplane, without baro and compass. I think he has made the same thing for Baseflight. For Fixedwings there is no necessary the precision of barometer, you could take the value from GPS readings.

I would be a great thing if you could implement RTH for airplanes, so we could have it in next versión (1.10?) of CF.

This is because there are some really cheap 32bit controllers w/o baro and mag that would be great for our airplanes (as CC3D). Having them with RTH also... uhhhh

Thx.

@iforce2d

This comment has been minimized.

Show comment
Hide comment
@iforce2d

iforce2d Aug 31, 2015

Contributor

Just wondering, has any of this nav re-write code been pulled into the official cleanflight repo yet?

I have been using the GPS features with regular 1.9.0 and all default PIDs and everything works very well for me, even waypoints (I hardcoded some points into the source code to test).

Alt-hold, GPS hold, RTH: https://www.youtube.com/watch?v=NABt7PQxpkA#t=8m32s
Hardcoded waypoints test: https://www.youtube.com/watch?v=ze9HIRFB9rs

If I understand it correctly the standard 1.9.0 that I'm using in those videos (cloned from main repo on July 7) does not have the nav re-write yet, so I'm kinda wondering what the re-write is intended to improve apart from making the source code tidier. From looking at the re-write source, there seems to be a lot of changes for something that was working pretty well already.

fwiw the main improvement I would like is better position estimation (using sensor fusion) and perhaps and auto-land or auto-launch.

Contributor

iforce2d commented Aug 31, 2015

Just wondering, has any of this nav re-write code been pulled into the official cleanflight repo yet?

I have been using the GPS features with regular 1.9.0 and all default PIDs and everything works very well for me, even waypoints (I hardcoded some points into the source code to test).

Alt-hold, GPS hold, RTH: https://www.youtube.com/watch?v=NABt7PQxpkA#t=8m32s
Hardcoded waypoints test: https://www.youtube.com/watch?v=ze9HIRFB9rs

If I understand it correctly the standard 1.9.0 that I'm using in those videos (cloned from main repo on July 7) does not have the nav re-write yet, so I'm kinda wondering what the re-write is intended to improve apart from making the source code tidier. From looking at the re-write source, there seems to be a lot of changes for something that was working pretty well already.

fwiw the main improvement I would like is better position estimation (using sensor fusion) and perhaps and auto-land or auto-launch.

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Aug 31, 2015

Contributor

@iforce2d
No nav-rewrite code is in the official cleanflight yet. The main problem with current cleanflight code is that is pretty much monolythic, nothing can be added or removed without much effort. Adding better position estimation would be a pain.
Main goal of nav-rewrite is to make code cleaner and modular and if possible to make some improvements on the way. In nav-rewrite code doing actual navigation is completely separated of code doing position estimation, this will greatly simplify adding something like Kalmann filtering in future.

What is done:

  • basic position estimation (not much sensor fusion is done)
  • multirotor altitude hold (working much better than 1.9.0 for me)
  • preliminary position hold and navigation (some tuning and bugfixing is ongoing)
  • preliminary RTH logic (climb, go home, land)
    What is pending:
  • waypoint support
  • fixed wing navigation
Contributor

digitalentity commented Aug 31, 2015

@iforce2d
No nav-rewrite code is in the official cleanflight yet. The main problem with current cleanflight code is that is pretty much monolythic, nothing can be added or removed without much effort. Adding better position estimation would be a pain.
Main goal of nav-rewrite is to make code cleaner and modular and if possible to make some improvements on the way. In nav-rewrite code doing actual navigation is completely separated of code doing position estimation, this will greatly simplify adding something like Kalmann filtering in future.

What is done:

  • basic position estimation (not much sensor fusion is done)
  • multirotor altitude hold (working much better than 1.9.0 for me)
  • preliminary position hold and navigation (some tuning and bugfixing is ongoing)
  • preliminary RTH logic (climb, go home, land)
    What is pending:
  • waypoint support
  • fixed wing navigation
@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Sep 1, 2015

Hello, I use as ground station a android app called "EZ-GUI". I see there an
option follow me (the phone sends gps coordinates to the fc) will it work ?

Hello, I use as ground station a android app called "EZ-GUI". I see there an
option follow me (the phone sends gps coordinates to the fc) will it work ?

@sppnk

This comment has been minimized.

Show comment
Hide comment
@sppnk

sppnk Sep 1, 2015

Contributor

Hi, I also use EZGUI, but I havent tested the follow me option with CF. I dont know if it works here.

Contributor

sppnk commented Sep 1, 2015

Hi, I also use EZGUI, but I havent tested the follow me option with CF. I dont know if it works here.

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Sep 1, 2015

Contributor

@louisdelooze, @sppnk
Not yet. It will work when waypoint support will be implemented.

Contributor

digitalentity commented Sep 1, 2015

@louisdelooze, @sppnk
Not yet. It will work when waypoint support will be implemented.

@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Sep 1, 2015

I tested the beta, but when I am in poshold it does move in circles (bigger and
bigger) so I tought that it has some interferance problems, but when I rose, it
has still the same problem, does somebody now a solution?

I tested the beta, but when I am in poshold it does move in circles (bigger and
bigger) so I tought that it has some interferance problems, but when I rose, it
has still the same problem, does somebody now a solution?

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Sep 1, 2015

Contributor

@louisdelooze
Do you have a blackbox? Can you send me a log for analysis? Also verify that compass is well calibrated - when connected to configurator heading on main screen shouldn't change much (5-10 deg is fine) when copter is tilted.
Also try lowering PH PIDS, defaults are probably too high (I've experienced same problem as you yesterday, but didn't have a laptop with me to reconfigure the copter):

set gps_pos_p = 20
set gps_pos_i = 0
set gps_pos_d = 0
set gps_posr_p = 30
set gps_posr_i = 5
set gps_posr_d = 10

Contributor

digitalentity commented Sep 1, 2015

@louisdelooze
Do you have a blackbox? Can you send me a log for analysis? Also verify that compass is well calibrated - when connected to configurator heading on main screen shouldn't change much (5-10 deg is fine) when copter is tilted.
Also try lowering PH PIDS, defaults are probably too high (I've experienced same problem as you yesterday, but didn't have a laptop with me to reconfigure the copter):

set gps_pos_p = 20
set gps_pos_i = 0
set gps_pos_d = 0
set gps_posr_p = 30
set gps_posr_i = 5
set gps_posr_d = 10

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Sep 8, 2015

Contributor

Full waypoint navigation implemented in my navigation-rewrite branch (16a3cb5) - a total of 15 waypoints numbered 1 to 15 supported for compatibility with existing MSP clients where waypoint 0 is home and waypoint 16 - current hold position. EzGUI's follow me should work but code is completely untested.

Contributor

digitalentity commented Sep 8, 2015

Full waypoint navigation implemented in my navigation-rewrite branch (16a3cb5) - a total of 15 waypoints numbered 1 to 15 supported for compatibility with existing MSP clients where waypoint 0 is home and waypoint 16 - current hold position. EzGUI's follow me should work but code is completely untested.

@louisdelooze

This comment has been minimized.

Show comment
Hide comment
@louisdelooze

louisdelooze Sep 8, 2015

Is it already with the updated gps settings ?

Is it already with the updated gps settings ?

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Sep 8, 2015

Contributor

Please don't test waypoint stuff yet! It looks like MultiWii waypoint protocol has evolved since baseflight/cleanflight was forked. I need to catch up with MultiWii!

Contributor

digitalentity commented Sep 8, 2015

Please don't test waypoint stuff yet! It looks like MultiWii waypoint protocol has evolved since baseflight/cleanflight was forked. I need to catch up with MultiWii!

@GilDev

This comment has been minimized.

Show comment
Hide comment
@GilDev

GilDev Oct 23, 2015

Is there any news for this? Waypoints are awesome!

GilDev commented Oct 23, 2015

Is there any news for this? Waypoints are awesome!

@dkisselev

This comment has been minimized.

Show comment
Hide comment
@dkisselev

dkisselev Oct 23, 2015

Contributor

Check digitalentity's CF branch (and issue tracker there), things are coming a long, there's just a lot to it :)

Contributor

dkisselev commented Oct 23, 2015

Check digitalentity's CF branch (and issue tracker there), things are coming a long, there's just a lot to it :)

@GilDev

This comment has been minimized.

Show comment
Hide comment
@GilDev

GilDev Oct 23, 2015

Thanks, I can't wait to try that. ^^

GilDev commented Oct 23, 2015

Thanks, I can't wait to try that. ^^

@digitalentity

This comment has been minimized.

Show comment
Hide comment
@digitalentity

digitalentity Oct 23, 2015

Contributor

@GilDev
Waypoint are coming right after good and reliable PosHold and RTH.
You can speed things up a little by participating in discussion and testing on RCG here: http://www.rcgroups.com/forums/showthread.php?p=33014511

Contributor

digitalentity commented Oct 23, 2015

@GilDev
Waypoint are coming right after good and reliable PosHold and RTH.
You can speed things up a little by participating in discussion and testing on RCG here: http://www.rcgroups.com/forums/showthread.php?p=33014511

blckmn pushed a commit to blckmn/cleanflight that referenced this issue Jun 16, 2016

Merge pull request #530 from martinbudden/bf_acc_1g
Cleanup of acc device drivers extern usage - CF PR#2117
@dantheman213

This comment has been minimized.

Show comment
Hide comment
@dantheman213

dantheman213 Jul 12, 2016

What's the state of the rewrite of GPS/navigation for Cleanflight? Are GPS waypoints coming up?

What's the state of the rewrite of GPS/navigation for Cleanflight? Are GPS waypoints coming up?

@jaecktec

This comment has been minimized.

Show comment
Hide comment
@jaecktec

jaecktec Aug 15, 2016

There is the iNav fork wich works realy great, I wonder why its not merged into the main branch.

There is the iNav fork wich works realy great, I wonder why its not merged into the main branch.

@Floyer007

This comment has been minimized.

Show comment
Hide comment
@Floyer007

Floyer007 Sep 6, 2016

@jaecktec where I can find it?

@jaecktec where I can find it?

@jaecktec

This comment has been minimized.

Show comment
Hide comment

@hydra hydra closed this Feb 25, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment