Hi there,
Does anybody facing with this problem, it’s a brand new one from the package.
Connection was done according to the guide (heavy configuration), but in the case of selection frame, there was no option for “Bluerov2 Heavy Config” that I thing should pull up all correct parameters.
@EliotBR could you please assist in this regards, if you need additional info about my config or I need to send log file please let me know
Hi!
Try this to see if QGC recognize the ROV/Pixhawk for corrrect frame:
Shut down QGC, restart ROV by power off/on and wait to pixhawk/Pi has woken up (~20 sec)
Then start QGC and check in settings if you find the frame of “Heavy”
Hi @Boko
Is it depends on which version QGC to use, because I don’t see this options as it was before like a drop down menu option where you can select “heavy” config?
Nurjan.
Hi @nurjan14, apologies for the delay on responding to this.
We’ve had some issues with flickering lumen lights in the past, which if I remember correctly were caused by a faulty Pixhawk servo output chip giving incorrect timings. I would recommend you contact support@bluerobotics.com to confirm the issue and sort out a relevant replacement or refund 
The Vectored_6DOF frame is the “Heavy” frame, although it should be showing up with an image when connected to ArduSub (similar to this). I would recommend confirming that your software versions match our latest recommendations, then try setting the heavy frame, resetting parameters, and seeing if thing are improved. If the issue is still present then contacting the support email is your best bet
Hey everyone,
Just to recap on this regads,
I checked almost 10 piece of pixhawk 1 from different branches (factory) ordered from different vendors at completely different time (like one year difference). They all have the same behaviour about this flickereing while powered up and in IDLE disarmed mode and in IDLE manual arm mode. However it works fine as it supposed (you can make it from off, dimmer or brighter) while you sending certain PWM command (again, my speculation its about should constant pwm signal over 1100±1200 ms) to any actuators such a servo, gripper to motor(s) to move. I tried to set boundaries in the QGC, for minimum PWM for servo9, but no luck. Perhap, might be a software issue.
Also noticed that if you touch the lumen’s frame itself in IDLE disarm mode with bare hand it fix a problem for 1-2 second then flickering come again, so might a problem with grounding or capacitors issue perhaps?
I have checked 2 new lumens and 2 old version lumen (with red penetrator) and it has the same situation.
So might be helpful for someone. I am ok with that but flickering for sure it’s annoying when you doing some testing on surface indoor.
Following up here, it sounds like you may be running into this issue, where one or more of your thrusters has a shorted stator. Worth a check
Hi @EliotBR thanks for reply,
I checked my thrusters, and there are no any issue with a shorting in wires with the ground.
And it’s seems to me that on the post the author describes alternative situation with mine, i.e. in my case flickering occurs when I connect batteries and when rpi with os and everything boot up. And only when I apply some power to the throttle it is just works fine and no any flickering as long as I give some non IDLE (800-920ms) pwm signal it works fine.
Best
Nurjan.
Hi @nurjan14,
I’m not super clear about what exactly your problem is. Does the flickering occur
Also, have you tried testing with just the Lumens connected (e.g. no thrusters/servos/etc), and/or can you try testing with a servo tester or something? It would be good to establish whether the problem is with your Lumens, with the signals you’re sending to them, or with some other device/component on your vehicle.
From there you’ll likely need to contact support@bluerobotics.com and
Hi @EliotBR
when you’re changing the PWM signal to the Lumen within its expected 1100-1900us pulse-width range
When the throttle or any thruster are IDLE it doesn’t changes and keeps flickering. When throttle, is about to move more than 4-5% throttle gain from IDLE and I can see gradual brightness changing while changing PWM to the Lumen.
when you’re changing the PWM signals to other devices something else?
I tried motor control mixer unit and simple PWM module for ESC testing and it doesn’t change the brightness while changing PWM knob.
something else
I tried this with the different lumen set and with the previous version of 4x set lumen (those with the red penetrators) and it has the same behavior. I tried with different pixhawk and it has the same issue.
Looks like there is smth else wrong, because for me it’s looks like in stuck position.
I don’t know how to explain that beyond definitely being some kind of hardware issue. Perhaps there is significant cross-talk between the ESC signals and the signal for the Lumens, but I’m not sure what’s most likely to cause that unless the signal wires are shorted. There could also potentially be noise from the thruster signal wires, but I’m not sure why it would be so strong, or whether it would display as you’re describing.
Was this with the Lumens powered and controlled separately to the rest of the ROV, and with the ROV off? If a servo PWM signal isn’t changing the brightness then either the provided signal is not in the correct range (1100-1900 microsecond pulse-duration), or perhaps the Lumen signal wire is floating, or shorted to power or something.
It seems unlikely that multiple sets of Lumens and multiple Pixhawks would be performing incorrectly in the same way, although there is a possibility that a batch of one or the other could have a consistent issue. That said, I would expect such an issue to have been raised previously, which doesn’t seem to have been the case. If the issue is not with the Lumens or Pixhawks then it must be with the rest of your system, but in that case the brightness control should work fine when you test with a setup that has just computer → Pixhawk → Lumen with no other components attached.
If you have access to an oscilloscope you can try measuring the PWM signal being output from the Pixhawk and also your “PWM module”, both when the Lumen is and isn’t connected to see if they match the expected pulse durations.
I would probably suggest contacting the support email I linked you to earlier, as they may have some additional ideas or solutions. You may need to include some pictures and/or diagrams of your setup to fully communicate what you have tried, and how it’s behaving in each situation.
Just for update, I have managed this worked,
I can’t tell exact problem, I’ve been just replaced lumen set to the previous model and made a rewiring from scratch. One difference is the latest blues and navigator board instead of pixhawk. But I am now experiencing problem with compass calibration so most probably I am gonna roll back to pixhawk, and check wether or not it will fix the problem with compass calibration and lumen flickering.
Eliot; I was running some tests using a PWM LED controller and 3W LEDs - none Blue Robotics.
I see a flicker due to the 50 Hz of the normal PWM signal. I looked at the schematic of the Lumen and the A6200 chip data sheet which shows it can run at much higher frequencies than the normal servo 50Hz.
What frequency does the Pixhawk put out on the PWM? Is it different for the lamps?
If it is 50Hz the LEDs will flicker, incandescent lamps will not because there is not enough time to cool between pulses.
Does the flicker bother the video image?
Edit: I don’t think the inductor is big enough to do much to the current pulses.
I started a new thread called “Lumen Control Signal” and figured it out before I got a reply.
The Lumen uses an A6211 LED driver which says it needs a 0.1 to 100% duty cycle.
Looking at the schematic of the Lumen I see the PWM signal goes to a microprocessor as SIGNAL_HU and is converted to signal LED-PWM that has the required dynamic range, and log function, to control the LEDs.
