Hi,

Anyone succeeded to install external LEDs on Pixhawk?

On APM we could configure the param Led_mode to a binary value representing which actions turn LEDs on A5 and A6.

Is there an equivalent feature on Pixhawk? Found nothing in the wiki about it.

Thx for any info,

Hugues

Views: 18313

Replies to This Discussion

Driver integrated LED panels are now generally available and cheap. It would be a good time for somebody to help APM catch-up to with CleanFlight/Naze32 and it's support for programmable RGB LED support (including the status/location relative settings).

http://www.banggood.com/Diatone-WS2812-WS2812B-RGB-LED-Board-5050-F...

For anybody who is interested in more bling on their copter or plane I have made a simple external lighting controller that can be used with APM. It is based on the LED driver in Cleanflight and connects to a Mavlink serial telemetry channel.

It's called Mavpixel. It uses an Arduino Pro Mini 5v 16Mhz and can control up to 4 strips of 8 WS2812 LEDs each.

Mavpixel can control up to 32 RGB LEDs, with functions including:

  • Flight modes
  • Arming status 
  • Warnings like low battery and failsafe
  • Indicators
  • Throttle position
  • GPS status with number of satellites
  • Orientation
  • Fixed colours
  • Animation effects
  • Thrust ring

I have only just finished the firmware and it seems to work, but is totally untested and not ready for general release.

However, early adopters can try the source code on GitHub. Documentation is scarce at the moment. The configuration interface, MavpixelGUI, is nearly ready as well.

Anybody who is interested in helping me with the task of getting Mavpixel tested, documented and ready would be most welcome.

Setting it up is pretty easy. Download and flash the firmware to a Pro Mini using Arduino version 1.0.6 and an FTDI programmer. Open the Serial Monitor at 57600 baud and use the CLI to set up the new Mavpixel's LED strips with Cleanflight style commands.

Hooking it up is fairly straightforward too. Connect a free telemetry port on the flight controller to Mavpixel's serial port through it's programming connector using four wires +5v, gnd, txd->rxd and rxd->txd. Power the LED strips from the servo rail or a 5v UBEC. Run the data line from each strip to the Mavpixel pins A1(leds 1-7), A2(leds 8-15), A3(leds16-23), and A4(leds 24-31).

Configuring the Mavpixel can be done through Mavlink, through the built-in serial CLI using the FTDI or over a secondary software serial CLI. In the future configuration will be handled mostly by MavpixelGUI. This windows application is undergoing heavy development and is only available upon request right now but if you really want to try it let me know.

Note that Mavpixel has been developed against and currently works best with copter 3.3.

For some reason in copter 3.4-rc1 Mavpixel heartbeats are not making their way through to the ground station leaving configuration over Mavlink unavailable. The cause for this is yet to be determined.

So, time to start getting that bling on.

Good job @Nick

Why don't you have a word with Scott, and join forces with him for an existing project http://openbrainiacs.com/tiki-index.php?page=Teensy%20Telemetry%20L...  ??



Nick said:

For anybody who is interested in more bling on their copter or plane I have made a simple external lighting controller that can be used with APM. It is based on the LED driver in Cleanflight and connects to a Mavlink serial telemetry channel.

It's called Mavpixel. It uses an Arduino Pro Mini 5v 16Mhz and can control up to 4 strips of 8 WS2812 LEDs each.

Mavpixel can control up to 32 RGB LEDs, with functions including:

  • Flight modes
  • Arming status 
  • Warnings like low battery and failsafe
  • Indicators
  • Throttle position
  • GPS status with number of satellites
  • Orientation
  • Fixed colours
  • Animation effects
  • Thrust ring

I have only just finished the firmware and it seems to work, but is totally untested and not ready for general release.

However, early adopters can try the source code on GitHub. Documentation is scarce at the moment. The configuration interface, MavpixelGUI, is nearly ready as well.

Anybody who is interested in helping me with the task of getting Mavpixel tested, documented and ready would be most welcome.

Setting it up is pretty easy. Download and flash the firmware to a Pro Mini using Arduino version 1.0.6 and an FTDI programmer. Open the Serial Monitor at 57600 baud and use the CLI to set up the new Mavpixel's LED strips with Cleanflight style commands.

Hooking it up is fairly straightforward too. Connect a free telemetry port on the flight controller to Mavpixel's serial port through it's programming connector using four wires +5v, gnd, txd->rxd and rxd->txd. Power the LED strips from the servo rail or a 5v UBEC. Run the data line from each strip to the Mavpixel pins A1(leds 1-7), A2(leds 8-15), A3(leds16-23), and A4(leds 24-31).

Configuring the Mavpixel can be done through Mavlink, through the built-in serial CLI using the FTDI or over a secondary software serial CLI. In the future configuration will be handled mostly by MavpixelGUI. This windows application is undergoing heavy development and is only available upon request right now but if you really want to try it let me know.

Note that Mavpixel has been developed against and currently works best with copter 3.3.

For some reason in copter 3.4-rc1 Mavpixel heartbeats are not making their way through to the ground station leaving configuration over Mavlink unavailable. The cause for this is yet to be determined.

So, time to start getting that bling on.

Thanks Luis, I hadn't seen that project. It looks similar to Mavpixel but appears to have a different set of features, has fixed patterns and uses a somewhat more expensive controller.

I feel a 3.3 volt microcontroller is not ideal for running WS2812 led strips due to their high data voltage requirement. Mavpixel does not require special voltages to power the strips. Using a Teensy seems a bit excessive to me anyway, like cracking a nut with a sledgehammer. I'm a nut myself that way.

Scott has done a great job but Mavpixel really is something else. Check it out! It has been implemented as a full Mavlink peripheral with support in Mission Planner for setting LED parameters in real-time over the telemetry channel.

However, I really like the idea of using the SPort channel to control a set of patterns. This would work even without a flight controller. Mavpixel is very dependent on it's host flight controller.

I think we should indeed get in touch as it would appear we have much to offer each other. Cheers!

Yeah, the 3.3V of the Teensy could be a problem but is easily addressed, and Scott managed to explain alternatives. 

In general I feel that running plain Arduinos, while cheaper, brings unwanted limitations (code size and complexity) while the Teensy allows for multipurposing the same external device (therefore only occupying only one serial port) and having more functions.

The led patterns on Scott's project are programmable, using an external app.

I glanced on your github and I really like your approach of using Mavlink, but I couldn't identify which systemID/componentID you're using for your project.



Nick said:

Thanks Luis, I hadn't seen that project. It looks similar to Mavpixel but appears to have a different set of features, has fixed patterns and uses a somewhat more expensive controller.

I feel a 3.3 volt microcontroller is not ideal for running WS2812 led strips due to their high data voltage requirement. Mavpixel does not require special voltages to power the strips. Using a Teensy seems a bit excessive to me anyway, like cracking a nut with a sledgehammer. I'm a nut myself that way.

Scott has done a great job but Mavpixel really is something else. Check it out! It has been implemented as a full Mavlink peripheral with support in Mission Planner for setting LED parameters in real-time over the telemetry channel.

However, I really like the idea of using the SPort channel to control a set of patterns. This would work even without a flight controller. Mavpixel is very dependent on it's host flight controller.

I think we should indeed get in touch as it would appear we have much to offer each other. Cheers!

Hi Nick,

We haven't been advertising the project much, but I think the LED support is something that hasn't been done before.  You can customize the LEDs with a configurator script that you create in a text editor.  That script gets loaded by the firmware into the Teensy's NVRAM to run the LEDs.  You can create bars and other patterns triggered by flight modes, altitude, distance from home, hdop, current consumption, voltage, etc.  

It's described in more details at http://openbrainiacs.com/tiki-index.php?page=Teensy+Telemetry+LED+C...

It's true, the Teensy isn't the cheapest processor ($20) but we only support it so we won't run into limitations.  

Best,

Scott

 

Hi @Scott. Seems I need to take a closer look at your project, I did not realize it was configurable with the features you mention. A configurator script seems like a good idea. I love the Teensy, it is a great controller with oodles of features, check out my simple Teensy Audio Spectrum Analyzer if you are interested to see what I did with my last one.

Of course, Mavpixel will only support Arduino in it's current form as the code has been tuned to overcome the limitations of that platform. It would be fairly easy to port to Teensy though and would use a bare fraction of it's capability. 

Perhaps you would wish to implement parameters over Mavlink as well. I would be happy to assist with that, and I suspect it helps Mavpixel too as a broader ecosystem of Mavlink Lighting Controllers will improve support for all of us.

Mavpixel is specifically based on the Cleanflight system of LED control. If you are familiar with Cleanflight you already know the capabilities of, and how Mavpixel is configured, both through the Cleanflight compatible CLI and MavpixelGUI. The GUI is pretty much a copy of the LED Strip window in Cleanflight Configurator. There is already a great deal of documentation, mostly relevant, on Cleanflight LED strip configuration.

I would not like to think we are competing with each other, I feel we provide different choices to suit different needs. Your controller is unbounded in scope, Mavpixel only emulates Cleanflight. Yours is more featureful and evolving, Mavpixel will only ever have the fixed set of Cleanflight features. Yours provides many more leds, Mavpixel is simple to connect. Horses for courses wouldn't you say?

Hi @Luis. The firmware is finished and fully functional, all limitations overcome. It was a tight fit and required some careful coding but now all features work as advertised on a $2 processor. Sure, even though it can't do anything else but run LED strips it does that surprisingly well.

I am currently using a Mavlink component ID of 160 which is the next free after the QX1 gimbal. Perhaps @Randy could suggest if this is a good idea or not, maybe even help me get assigned a MAV_COMP_ID_LIGHTING_CONTROLLER or some such, that would be great!

I am also using MAV_TYPE_ONBOARD_CONTROLLER which is wrong but works well and MAV_AUTOPILOT_INVALID which I think is meant to make a ground station ignore the device's parameters but doesn't. Suggestions for better choices is the kind of reason I'm here now.

Right now Mission planner gets a bit bothered by a vehicle with a Mavpixel if it is emitting heartbeats. Usually Mission Planner works in a jumpy kind of way but sometimes it refuses to connect to anything at all. QGroundControl works flawlessly with Mavpixel.

Fortunately Mavpixel heartbeats are not required and are disabled by default as MavpixelGUI can do Mavpixel discovery and configuration using Mavlink pings with no apparent drawback over the regular system at all.

This is better anyway as Mission planner will totally ignore Mavpixel like this but happily forward it's messages to MavpixelGUI. This means less chance of upsetting the vehicle or being blamed for an upset vehicle.

I will try to get the licensing done for MavpixelGUI so I can release it soon.

Thanks for your interest guys!

Cheers,

Nick.

@Nick

The componentid #158 was created for generic devices, and I believe Mavpixel fits here.

If you mean MAV_TYPE #18, I also believe this is correct. If something is wrong we'll have a look at it. Let me know and perhaps we can discuss this on today's dev call.

Both projects are great and I only refered you both is because we have limited serial ports available on the PixHawks :) and would be great to have our community efforts more focused :)

What do you mean licensing ??

And, just to throw it out there so people can see the kind of thing I mean, here are some screenshots of windows from MavpixelGUI.

Connected to a Mavpixel on Copter 3.3.3 through Mission Planner.

Mavpixel's basic settings in MavpixelGUI.

Selecting colours for flight modes. All flight modes in Copter and Plane are supported, 21 in total.

 Interactive terminal for CLI mode.

Built in firmware downloader and flasher for easy setup.

Hi @Luis. Are you sure I should switch to #158? The Mavlink message set states: "Generic autopilot peripheral component ID. Meant for devices that do not implement the parameter sub-protocol." I do indeed support the parameter sub-protocol, 83 parameters no less.

MavpixelGUI will probably get confused if anything else also uses #158, but that does seem unlikely on a single vehicle.

MAV_TYPE #18 is OK then. Sweet.

Oh, and by licensing I mean applying the GNU general public license to the many source files in all it's details. A most procrastination inducing if simple task. I ended up making the installer instead, also needed and somewhat less dull. Unfortunately I have a life that leaves me only a couple of hours for this stuff each night so I try to make the best of it.

Luis Vale Gonçalves said:

@Nick

The componentid #158 was created for generic devices, and I believe Mavpixel fits here.

If you mean MAV_TYPE #18, I also believe this is correct. If something is wrong we'll have a look at it. Let me know and perhaps we can discuss this on today's dev call.

Both projects are great and I only refered you both is because we have limited serial ports available on the PixHawks :) and would be great to have our community efforts more focused :)

What do you mean licensing ??

@Nick, I'll ping Tridge/Randy regarding the #158 id, and will let you know.

Jani must be happy for reusing his jDrones boards :)



Nick said:

Hi @Luis. Are you sure I should switch to #158? The Mavlink message set states: "Generic autopilot peripheral component ID. Meant for devices that do not implement the parameter sub-protocol." I do indeed support the parameter sub-protocol, 83 parameters no less.

MavpixelGUI will probably get confused if anything else also uses #158, but that does seem unlikely on a single vehicle.

MAV_TYPE #18 is OK then. Sweet.

Oh, and by licensing I mean applying the GNU general public license to the many source files in all it's details. A most procrastination inducing if simple task. I ended up making the installer instead, also needed and somewhat less dull. Unfortunately I have a life that leaves me only a couple of hours for this stuff each night so I try to make the best of it.

Luis Vale Gonçalves said:

@Nick

The componentid #158 was created for generic devices, and I believe Mavpixel fits here.

If you mean MAV_TYPE #18, I also believe this is correct. If something is wrong we'll have a look at it. Let me know and perhaps we can discuss this on today's dev call.

Both projects are great and I only refered you both is because we have limited serial ports available on the PixHawks :) and would be great to have our community efforts more focused :)

What do you mean licensing ??

Yes, this isn't the first time I've used Jani's very nice jD-IOBoard code, just the first time I released anything I made with it.

I was intending to have Mavpixel be compatible with jD-IO but it soon became apparent there would not be enough flash left.

Thanks for your efforts on my behalf @Luis. Perhaps you could help me sort out Mavpixel's most pressing issue.

Something to do with Mavlink routing has changed from AC 3.3 to AC 3.4 which prevents messages from Mavpixel reaching the ground station. Communication with the flight controller itself is fine.

I have not been keeping up with AC development for a few weeks, is there perhaps a new parameter I have missed? Or conventions have changed? Or maybe my choices of TYPE and ID are no longer valid for the new AC? Perhaps Mavpixel has been doing it all wrong and the only reason it works at all is because of bugs in 3.3. I'm not sure.

Can anyone shed light on this? It's a show-stopper for Mavpixel if I can't get it sorted out.

Cheers,

Nick

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service