ardupilot
ardupilot copied to clipboard
AP_Notify: allow split-standard LED pattern on serial LEDs
This is a simple little change that allows serial LED strips to easily be used as navigation / orientation lights. Drone registration in Japan appears to be requiring orientation indicators and this is an easy way to comply - either through a single strip or strips mounted on the arms. The change itself splits the LEDs into two banks, the first half shows the normal colours and the second swaps red and green so that when armed you get half red and half green.
I think this is really too much of a hack, its going to confuse everyone. Flashing green means I'm good to arm, except if I'm looking from the back in which case its flashing red? If I loose GPS fix then it all goes blue so I can no longer tell orientation at all?
Scripting really is great for such things.
Scripting is not good in this use case for three reasons:
a) All the copters I need this on (small copters) don't have scripting b) To implement in scripting you have to re-implement the whole of the notify standard patterns - complicated and laborious c) It's a pretty standard requirement and becoming more so legally
The confusion thing could be addressed by an armed only flag - so "Show navigation colours on arming".
b) To implement in scripting you have to re-implement the whole of the notify standard patterns - complicated and laborious
We have a binding to return the current notify color. LED:get_rgb() So you can mirror notify, or output notify colors on a subsection. I can't find a example vid of that, but this is this is our Hexsoon example script: https://youtu.be/X-kGiXX4AKU?si=OivIGhDyzKOcfvSa&t=1226
Edit: I found the notify demo https://youtu.be/qHUIMvzoF10
@IamPete1 we've had a user pop up and independently ask for navigation-style lights on F405. Could you re-evaluate based on that, please?
@andyp1per in what way is this a bug?! Definitely looks like a feature to me!
@IamPete1 we've had a user pop up and independently ask for navigation-style lights on F405. Could you re-evaluate based on that, please?
If we did want to support nav lights I don't think it belongs under notify. It just results in making the existing colors confusing.
The real problem with nav lights is that you need quite a bit of configuration, I just don't see a way to do that in parameters without needing lots and the end result being confusing. Other firmware have a config file for such things EG:
https://github.com/iNavFlight/inav/blob/master/docs/LedStrip.md#configuration
We could implement that, but its getting awfully close to just using scripting in the first place.
We could implement that, but its getting awfully close to just using scripting in the first place.
That is to say, I would rather see effort put in to getting scripting to run on the F405 boards. We have the new littlefs stuff now so SD card is no longer a requirement. Some work to make the scripting bindings more configurable would help, so we could have a GPS driver without having the GPS scripting bindings for example. That should allow scripting to fit if some other features are turned off.
We could implement that, but its getting awfully close to just using scripting in the first place.
That is to say, I would rather see effort put in to getting scripting to run on the F405 boards. We have the new littlefs stuff now so SD card is no longer a requirement. Some work to make the scripting bindings more configurable would help, so we could have a GPS driver without having the GPS scripting bindings for example. That should allow scripting to fit if some other features are turned off.
C'mon Pete, that's not realistic - scripting is 150k without even considering the CPU issues, simply a non-starter on F405 IMO
C'mon Pete, that's not realistic - scripting is 150k without even considering the CPU issues, simply a non-starter on F405 IMO
All scripting is more than 150K currently, that is because you get all the bindings, as I say if we turn off all the bindings it costs much less. CPU of course depends on what else you want to run, but scripting on a F405 was common when it was first added. Running scripting on periph is relatively common now often with less CPU and flash than a F405. I have used scripting on a periph G474, there it cost 115K, we could get it down to less than 100K if we removed more bindings. If we were to replicate a INAV style configuration file I think that would cost 20K or so. If we could get scripting to work it would be a much better solution.