I am starting to test this on a test Pixhawk and a test Micropix (no AUX outputs) controllers with ArduCopter versions both beta and latest (I observe that lua calls are changing). I am watching outputs on an oscilloscope so as not to have level problems.
No outputs up to now.
On the test Pixhawk (beta): 22/03/2020 13:09:39 : RCOut: PWM:1-8 NeoP:9-12 PWM:13-14 22/03/2020 13:09:39 : fmuv3 004B0036 3436510A 32393637 22/03/2020 13:09:39 : ChibiOS: d4fce84e 22/03/2020 13:09:39 : ArduCopter V4.0.3 (ffd08628)
On the test Micropix (latest): 22/03/2020 10:53:30 : RCOut: PWM:1-12 22/03/2020 10:53:30 : fmuv3 003C002D 50485011 20323450 22/03/2020 10:53:30 : ChibiOS: d4fce84e 22/03/2020 10:53:30 : ArduCopter V4.0.4-dev (f4f2caee)
Since “NeoP” only appears on the Pixhawk, does that mean that WS2812 leds will not work on the Micropix, and on the Pixhauw only on AUX 1-4?
You can do all 6 aux on the Pixhawk, you need to set BRD_PWM_COUNT = 6. I am not failure with the Micropix, but it looks like a Pixhawk clone with no aux outputs. If this is the case then NeoPixels won’t work.
I left apart the Micropix. First I tried a Pixracer (outputs PE14/PE13/PE11/PE9/PD13/PD14 as Pixhawk AUX’s), obtaining: RCOut: PWM:1-6
(no NeoP indication), without success.
The Pixhawk, depending on version (beta, latest…) resets continuously, beeps or shows message “Lua: No scripts to run”, even reporting 2MB when programmed, so I wonder if it is an appropiate controller for WS2812’s.
It is not clear on the documentation which number to assign to SERVOx_FUNCTION’s: 94-109 or 120-123 for WS2812’s:
It depends what your trying to do, for notify you use the 120 - 123 for scripting you use the scripting outputs. To see them assigned you need to enable them in the NTF_LED_TYPE bit mask or set them to neopixels in your script.
So I started with notifying, and things began to work with latest Copter version: 25/03/2020 11:37:16 : Frame: HEXA 25/03/2020 11:37:16 : RCOut: PWM:1-8 NeoP:9-12 PWM:13-14 25/03/2020 11:37:16 : fmuv3 004B0036 3436510A 32393637 25/03/2020 11:37:16 : ChibiOS: d4fce84e 25/03/2020 11:37:16 : ArduCopter V4.0.4-dev (bfc4802b)
even not using level converters (direct connection).
I connected four 8x8 WS2812 panels on Pixhawk AUX1 to AUX4 with: BRD_PWM_COUNT=4 NTF_LED_LEN=64 NTF_LED_OVERRIDE=0 NTF_LED_TYPES=258 SCR_ENABLE=0 SERVO9_FUNCTION=120 SERVO10_FUNCTION=121 SERVO11_FUNCTION=122 SERVO12_FUNCTION=123
and got (4K):
(Note that trying 64 leds is not for flying; there are many problems).
Pixhawk led red and WS2812 leds yellow is easy to reproduce: disconnect and connect the USB cable to a USB power bank.
Trying all the same on a Pixracer didn’t work. It reported: 25/03/2020 12:17:33 : Frame: QUAD 25/03/2020 12:17:33 : RCOut: PWM:1-6 25/03/2020 12:17:33 : ArduCopter V4.0.4-dev (bfc4802b) 25/03/2020 12:17:33 : Pixracer 004F002F 34385108 35383135 25/03/2020 12:17:33 : ChibiOS: d4fce84e
but it didn’t work (leds off) even its outputs are the same as Pixhawk AUX’s (PE14/PE13/PE11/PE9/PD13/PD14).
With that working, I tried a lua script, changing: NTF_LED_LEN=8 SCR_ENABLE=1 SERVO9_FUNCTION=94
with the following lua script:
local num_leds = 5 local vez = 0 local chan = SRV_Channels:find_channel(94)
if not chan then gcs:send_text(6, “LEDs: channel not set”) return end
– find_channel returns 0 to 15, convert to 1 to 16 chan = chan + 1
function update_LEDs() serialLED:set_RGB(chan, 1, 127, 127, 127) serialLED:send(chan) gcs:send_text(6, “LEDs94: vez=” … tostring(vez)) vez = vez + 1 return update_LEDs, 2000 – run at 50Hz end
So there seems to be no problem on the two bold lines, but the panel on AUX1 (SERVO9_FUNCTION=94) was off all the time (the other three were on as before, with 8 leds each).
What am I missing to get lua script output on AUX1 and notifying on AUX2 to AUX4?
AUX1, 2, 3 and 4 are in the same group, because of the way it works you can only send whole group at a time. So notify is sending the group before the script has had a chance to tell the LED’s what color to be. Basically you need to update the whole group colors at once. I’m excited to see what your going to use those panels for, although I suspect the Pixhawk1 might struggle to do anything to fancy before it runs out of memory. There is a scrolling display example script, I should think you could get that working without too much effort.
I was trying with development versions after observing that lua objects calling syntax was being improved.
Edited: see forward post. The problem came because of having 94 scripting value duplicated on a MAIN and AUX output, having tested previously on the MAIN outputs, so desired AUX1 output was not found.
I had those panels before. Eventually they would be placed on this balance bot with Pixhawk (Barbie) but all AUX outputs are being used now, and with all these problems perhaps an Arduino or a companion computer should be used for these panels.
QGC reports 2MB when programming these Pixhawk’s. There seems to be no problems with 32 leds.
Memory is not the same as flash, memory is like your PC’s RAM, you already don’t have enough left to run the EKF.
The more things you turn off the more you can use for scripting, things like terrain and the second EKF you can turn off without much issue. If your planning on using a rover that will use less than copter from the start.
I had SERVOx_FUNCTION=94 forgotten aditionally on one of the MAIN inputs from a forgotten previous test, so that input with nothing connected and that seems not to work with WS2812’s was found.
For a thorough test I tried this script:
local chan
function update_SRV()
for i = 33, 38 do
chan = SRV_Channels:find_channel(i)
gcs:send_text(0, tostring(i) … " MAIN " … tostring(chan))
end
for i = 120, 123 do
chan = SRV_Channels:find_channel(i)
gcs:send_text(0, tostring(i) … " AUX " … tostring(chan))
end
function update_LEDs()
for i = 0, num_leds-1 do
serialLED:set_RGB(chan, i, vez+i, vez+i, vez+i)
end
serialLED:send(9)
gcs:send_text(6, “LEDs94: vez=” … tostring(vez) … " – " … tostring(chan))
if vez<(255-num_leds) then
vez = vez + 1
else
vez=0
end
return update_LEDs, 400
end
return update_LEDs, 400
that worked although with memory problems, with: BRD_PWM_COUNT=4 NTF_LED_LEN=64 NTF_LED_OVERRIDE=0 NTF_LED_TYPES=258 SCR_ENABLE=0 SERVO9_FUNCTION=94 SERVO10_FUNCTION=121 SERVO11_FUNCTION=122 SERVO12_FUNCTION=123
giving this video (4K):
Changing to NTF_LED_LEN=32
and also local num_leds = 32
on the script, gave this other video (4K):
with no memory problems.
Note that the script sends a different gray color for each of the 64 panel on AUX1, but it is only visible on both videos on the transitions from all leds fully on to RGB values 0…63 (i=0 on the for loop).
Note also the led numbering on the for loop: for i = 0, num_leds-1 do
which lights all 64/32 leds. Here mentions led numbering from 1.
I thought remembering a 2MB flash requirement somewhere. I don’t find ram requirements on the documentation. From ST documentation ST32F4x7 chips ram is 192K to 256K. I would have to open the case for knowing the exact chip on these Pixhawk’s.
As said, I wanted this initially for a balance bot, which has assigned for motors signals all AUX outputs as GPIO’s (encoders 4, direction 2). I may try on this rover, perhaps.
Thanks for this will ask him. But for now i also tried this one on Navio 2 without success. Does anyone know if this works on Navio2 and how? Also tried on Cuav v5 nano and worked like a charm but not on BBBlue and Navio2.
Is there a step by step guide how to use adressable RGB LEDs on Pixhaw? I only need some different colours but I am not a programmer and would like to use these WS2812B because there are much more high quality addressable PCB LEDs on the market than normal RGB (4pin). I do not like this large LED strips.
As this thread is covering Neopixel integration I hope I can jump in to get some advise regarding problems with adding a few Neopixel leds to a Mateksys H743 Slim FC.
I think I have read all the relevant docs and that the settings according to that should be the correct ones but the leds do not function. Hooking up the oscilloscope confirms that no PWM signal comes from the servo pad marked as “led”. My settings are:
Neopixels (3 in a row) connected to +5V, GND and LED ( = PWM13 according to Mateksys docs for Ardupilot mapping. Din has a suitable resistor)
Arducopter start-up messages show RCout DS600:1-6 PWM: 7-12 NeoP: 13
BRD_PWM_COUNT = 13
NTF_LED_TYPES = 257 (internal + Neopixel)
NTF_LED_LEN = 3
SERVO13_FUNCTION = 120
As far as I can understand these settings should make it work but, as already said, signal coming out on LED connection is not a PWM signal. It is just some low level noice.
Either I have overlooked something essential (most likely) or there might be a firmware problem (less likely) (firmware used is 4.0.7 on current Mission Planner ground station).
Everything else used by this FC works really well (a CineWhoop quad with GPS, FrSky receiver and telemetry etc).
I am very grateful for any assistance, this problem has caused many hours of reading and testing.
Thank you for the advise.
I have tried the 4.1.Beta but result is negative. The signal coming from the LED pad is still just noise. I enclose a screen copy from the scope.
Update:
Tried to eliminate hardware errors at Servo13 by moving Neopixel output to Servo8. Result is same as above described. Then I changed Servo8 from Neopixel alternative to Landing gear (function # 29) and controlled this from RC10. Now the result was a perfectly normal PWM signal at the Servo8 pad.
Thus this seems to be a specific problem for the Neopixel functions.
In case somebody finds this thread I can mention that another test using the now released 4.1.0 firmware was successful. The Neopixels did work as expected and parameters used were as earlier mentioned.
I have no idea why the 4.1 beta did not work but that is of course irrelevant now.
