cork()/push() will be called in the vehicle code.
The issue that led to this fix was as follows:
- on a Linux board (Navio 2) usage of this class didn't yield any PWM on
the expected outputs on Rover (Copter and Plane worked as expected)
After dicsussion at #6339 rover code was changed (541538f) to use make
proper use of SRV_Channels API.
This fix is also the consequence of the discussion. TL;DR: the output is
only done when commanded by the vehicle.
Reworked the process flow. Created the aviation vs rover themes.
Created visual operator feedback for prearm checks, GPS, EKF, gyro init,
radio failsafe, and low battery. This also includes work by Hugh Eaves
to open up the full extended properties of the Oreo LEDs. Not only are
far more functions available, but you can override and do custom things
via mavlink.
Jaime did the hard work on this one. He reworked notify device
selection to take place on init rather than on compile like before. The
notify decivces are mostly set on compile using preprocessor directives
based on board type. I created NTF_OREO_THEME. This will allow the
user to enable/disable the OreoLED driver. And it also allows you to
select between aircraft and rover lighting themes. This allows the Solo
to use the OreoLEDs, and doesn't waste the memory on vehicles not
equipped with Oreo LEDs. The OreoLED driver is restricted to Pixhawk 2
FCs by proprocessor directive due to memory constraints. So it will
never work by accident on another board.
There is also a new notify flag for GPS Fusion. This flag is true when
the EKF is happy with the GPS, actively using it for position
information.
Evaluated solo specific tones file vs standard px4 tones files. The
only thing the Solo had that standard ArduPilot does not have is the GPS
unplugged tone and the power off tone.
* Some tones have a different tune, which is fine. We want the Solo to
sound like ArduPilot if it is running ArduPilot.
* GPS unplugged tone abandoned. Determined to be unnecessary.
* Power off tone merged into standard px4 tones file. Smart battery
signalling a power off will make use of this tone. Has application for
any smart battery equipped vehicle, not just Solo.
* Removed all references and dependencies to `ToneAlarm_PX4_Solo.cpp`
and `ToneAlarm_PX4_Solo.h`
* Deleted `ToneAlarm_PX4_Solo.cpp` and `ToneAlarm_PX4_Solo.h` since
they're no longer needed.
This makes the display architecture closer to our other frontend/backend splits
Added check that display is initialised successfully in hw_init
Renamed _update_timer to just _timer to make more consistent with other drivers
pwm backend to drive leds.
In new Disco releases, the led sysfs api will replace the pwm sysfs
api to drive the tricolor led.
Keep pwm sysfs api for compatibility reasons.
We currently check examples are buildable with waf which doesn't need
the libraries to be specified in a make.inc file. Having the makefiles
there is misleading since people try to build and realize the build is
broken.
when this is set the board RGB LED will be controlled by MAVLink
instead of internally. This is useful for cases where the LED patterns
and colours needed are specified by an external authority (such as the
OBC organisers)
- Initialize device on hw_init() method, allowing it not to be
present
- Add missing lock
- Add packed attribute to structs
- Move defines to source file
- Add missing semaphore take on bus
- Initialize device on init function rather than constructor: the
constructor may run before I2CDeviceManager is initialized since our
AP_Notify objects are static so it can't be used.
On early versions of minlure an RGB LED was wrongly placed next to the
barometer, causing trouble on it.
Additionally depending on the LED intensity it may be a pain to leave it
turned on for boards supposed to be used for bench testing. This allows
to disable the LED by software so we don't have to remove it.
- got rid of a lot of not needed defines
- allocated channels on init instead of accessing them every time
through the HAL reference
- simpliefied hw_set_rgb()