Skip to content
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

Support LeddarOne lidar #8409

Merged
merged 3 commits into from
Feb 8, 2018
Merged

Support LeddarOne lidar #8409

merged 3 commits into from
Feb 8, 2018

Conversation

zehortigoza
Copy link
Contributor

@zehortigoza zehortigoza force-pushed the leddar_one branch 2 times, most recently from dd7bb45 to d55f83b Compare December 4, 2017 22:10
@hamishwillee
Copy link
Contributor

@zehortigoza Can we add something for this in the docs?

Specifically Rangefinders should have an entry explaining what the rangefinder offers and how to enable it.

IF this won't be in any configurations and requires specific extra work to get going it might be worth creating a separate page below rangefinders as well (like this one for ulanding). That would cover where/how you add the driver, how you make sure it is started, any additional configuration.

Thoughts?

@zehortigoza
Copy link
Contributor Author

@hamishwillee Sure I will send a PR adding it to the documentation. I'm enabling it for AeroFC at least but I will also add instructions of how enable it for other boards.

@hamishwillee
Copy link
Contributor

Thank you very much!

@LorenzMeier
Copy link
Member

@zehortigoza Are these default tuning gains?

@zehortigoza
Copy link
Contributor Author

zehortigoza commented Dec 4, 2017

@LorenzMeier You mean the tuning parameter in LeddarOne? Yes, I'm using the stock parameters.
Or the PX4 tunings? The PX4 are also stock.
But in this video I'm flying with PX4 stable + this patches

@hamishwillee
Copy link
Contributor

Thanks for the docs @zehortigoza ! I have added a note up the top that this isn't in master yet: https://docs.px4.io/en/sensor/leddar_one.html
Will remove and do a final tidy/check when this is merged.

MAIN leddar_one
STACK_MAIN 1200
COMPILE_FLAGS
-Os
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optimization level is already set for the build overall.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I will remove it

@dagar
Copy link
Member

dagar commented Dec 6, 2017

The parameter usage is a bit unusual (board specific and placing it within the board support). We'd probably be better off shoving the baudrate setting into the new driver itself.

Longer term I want to generalize the serial port setup. #8302

@zehortigoza
Copy link
Contributor Author

The parameter usage is a bit unusual (board specific and placing it within the board support). We'd probably be better off shoving the baudrate setting into the new driver itself.

Longer term I want to generalize the serial port setup. #8302

That would be nice but it is target for 1.8v right?! Not sure if the merge window for 1.7v is still open for this.
If it is still open we could merge this as is(if the rest is in good shape for you) and then move to #8302 .
AeroFC is having some problems with Garmin Lidar(and other I2C sensors) and we would like to have that merged to recommend costumers to use this one instead.

@mhkabir
Copy link
Member

mhkabir commented Dec 6, 2017

What is the reason for the large, increasing timeslip in the logs?

@zehortigoza
Copy link
Contributor Author

zehortigoza commented Dec 6, 2017

What is the reason for the large, increasing timeslip in the logs?

Huum not sure yet but a quick test showed that I have this timeslip with our without this patches.

@dagar
Copy link
Member

dagar commented Dec 11, 2017

My only issue with this is putting params in the board support, but I don't have a better suggestion at the moment.

@dagar
Copy link
Member

dagar commented Dec 11, 2017

Ok, how about this. All the other lidar units follow the same pattern of being enabled by a param and then started in rc.sensors.
https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.sensors#L351
https://github.com/PX4/Firmware/blob/master/src/modules/sensors/sensor_params.c#L238

If you did this for the LeddarOne, then in the special aero mavlink handling you could either check the param, or even check if the LeddarOne is actually running.

You could then also add the leddar_one module across the board (px4fmu-v3, v4, v4pro, v5, auav-x21, mindpx).

@hamishwillee
Copy link
Contributor

I upvote #8409 (comment)

From a user point of view it would be far more consistent to be able to say that all sensors are enabled by setting a parameter. From a "guidance to developers" point of view it would be great to have a single mandated way to make the integration work (provided that way doesn't badly limit what can be done)
Some thoughts:

  • We have multiple serial ports but only one parameter. How does/would PX4 know that you have a rangefinder on a particular port? (I presume this does not matter for I2C which can have multiple things on bus)
  • What happens if a ROM is built without the rangefinder driver but the parameter is set.
  • Can/should we do something about misconfiguration - multiple parameters set, when only one thing can be on the port?

@dagar
Copy link
Member

dagar commented Dec 12, 2017

@hamishwillee very good points, we can try to address some of them in #8302. For now I'm simply pushing for consistency.

@LorenzMeier
Copy link
Member

Jenkins test this please

@zehortigoza
Copy link
Contributor Author

Sorry for the delay I was in vacation.

Ok, how about this. All the other lidar units follow the same pattern of being enabled by a param and then started in rc.sensors.
https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.sensors#L351
https://github.com/PX4/Firmware/blob/master/src/modules/sensors/sensor_params.c#L238

If you did this for the LeddarOne, then in the special aero mavlink handling you could either check the param, or even check if the LeddarOne is actually running.

You could then also add the leddar_one module across the board (px4fmu-v3, v4, v4pro, v5, auav-x21, mindpx).

I agree with the idea to add a parameter to start leddar_one driver but the idea to check if a UART lidar parameter was set to not start MAVLink sounds like a bad hack that will break easily.
The ideal would #8302 but until then for all other boards user can change SYS_COMPANION to disable MAVLink and for AeroFC user can change AEROFC_TELE_BPS. Maybe give a better name to this parameter like: AEROFC_EXT_TELE or AEROFC_TELEMETR

Let me know what you guys think so I can change/fix and rebase this.

@LorenzMeier
Copy link
Member

@ChristophTobler Could you chime in here? @zehortigoza It's really hard for me to predict the tradeoffs without testing it - could you do your best guess and rebase the PR?

printf("distance: %0.3fm\n", (double)report.current_distance);
printf("time: %llu\n", report.timestamp);

} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no way of stopping the driver

@ChristophTobler
Copy link
Contributor

I would also push for consistency and add a parameter to enable it

@ChristophTobler
Copy link
Contributor

@zehortigoza Is the Aero in this video using the optical flow app that we did? It holds position nicely 👍! Did you do any other modifications except dampening?

@zehortigoza
Copy link
Contributor Author

Okay I will fix and rebase it until monday.

@zehortigoza Is the Aero in this video using the optical flow app that we did? It holds position nicely 👍! Did you do any other modifications except dampening?

Yes it the aero-optical-flow.
Yep just the dampening but I guess for position hold it would work as good with the stock setup too.

@hamishwillee
Copy link
Contributor

@zehortigoza Ping - any plan to fix and rebase?

@zehortigoza
Copy link
Contributor Author

Rebased and fixed following the same approach did to Benewake TFMini.
Sorry for the delay

Copy link
Contributor

@ChristophTobler ChristophTobler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zehortigoza Thanks! Generally looks good to me. Could you check the comment and fix CI:

leddar_one/leddar_one.cpp:42:24: fatal error: nuttx/arch.h: No such file or directory

}

void
leddar_one::stop()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is being executed, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@zehortigoza zehortigoza force-pushed the leddar_one branch 2 times, most recently from 3b84f15 to 0b30917 Compare February 7, 2018 18:32
@zehortigoza
Copy link
Contributor Author

@ChristophTobler Fixed almost all CI errors, there is just one now caused by lack of flash memory in px4fmu-v2, should I remove the rangesensor's from px4fmu-v2?

@ChristophTobler
Copy link
Contributor

@zehortigoza Instead of removing all range finders we could add them individually.

@ChristophTobler
Copy link
Contributor

@zehortigoza I wouldn't remove all of them because this might brake some people's setup. Can you add them individually? drivers/distance_sensor/ll40ls etc.

We are running out of flash memory in px4fmu-v2 so removing all the
distance sensors from binary and adding then individually.
Right now only LeddarOne is not being buid.
@zehortigoza
Copy link
Contributor Author

@ChristophTobler Okay fixed and now all CI tests are passing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants