I'm writing a small program to save my laptop's battery, and I can now switch between power schemes using PowerSetActiveScheme.
The next step is to control the battery saver in Windows 10. Though I can read the state of it using GetSystemPowerStatus, I can't find a way to enable/disable it programmatically. Are there any functions in Windows API to do this?
Most probably you can do it Linux-way, by calling a system app named PowerCfg through ShellExecuteEx():
powercfg /setdcvalueindex SCHEME_CURRENT SUB_ENERGYSAVER ESBATTTHRESHOLD 100
powercfg /setactive scheme_current
This means that the energy saver is activated even when the battery percentage equals 100%. SUB_ENERGYSAVER and its sub-GUID ESBATTTHRESHOLD are described here.
#hidefromkgb's answer is pretty much correct. The only missing part is that to disable Energy Saver and prevent it from turning it on, you need to do:
powercfg /setdcvalueindex SCHEME_CURRENT SUB_ENERGYSAVER ESBATTTHRESHOLD 0
powercfg /setdcvalueindex SCHEME_CURRENT SUB_ENERGYSAVER ESBRIGHTNESS 100
If you do that, and go back to the control panel Battery Saver section, you will see that the first checkbox is now disabled (although it still shows 20% but it is grayed out so it should be ok). Also the second checkbox (lower screen brightness) will be unchecked.
You seem to be out of luck. MSDN docs show no API through which the battery saver could be controlled. Examining SettingsHandlers_OneCore_BatterySaver shows that only GetSetting is exposed. Even SetPowerState in WMI Win32_Battery is not implemented -- I know this is not exactly what you need, but it shows that Microsoft has not gotten around to exposing the battery-related functionality. At this point, instead of reverse-engineering the button click, your best bet is probably to emulate it with something like AutoHotKey, however beware of the pitfalls with that.
Related
We are trying to move Pepper around on a floor using ALNavigation SLAM APIs. We have created a map using ALNavigation:explore() method. The application works most of the time but sometimes Pepper stops and the application crashes in between due to some safeguard feature.
We are using ALNavigation:navigateToInMap to move Pepper around the map.
Here are some logs:
[W] 15:01:26 ALMotion.OmniWheelFollowPath: Stitch failed. Stopping path:
["Circle", [0.436987877, 11.431554794], [2.869375944, 11.368105888],
-0.046996359]
[W] 15:01:26 ALTouch.TouchManager: My Base is touched. Reasons: Wheel.
[W] 15:01:26 AutonomousLife: Robot was moved!
[W] 15:01:26 AutonomousLife: Robot moved, must enter safeguard state. Will
immediately re-enter solitary state.
Is there any way to fix this issue or is this a hardware issue with Pepper's wheels or something wrong in the code? I am simply calling navigateToInMap after localizing the robot and this works most of the times but this issue is getting more and more frequent.
Thanks
Pepper has a system to detect if she's been pushed, and (with current versions) there are sometimes false positives - especially on a floor with irregularities, or when pepper is moving quickly or accelerating brutaly.
Some solutions:
Make Pepper move / accelerate a bit more slowly
Have a system to launch the application again as soon as it exits safeguard (for example with a ShouldBeExploring or shouldBeNavigating trigger condition) - in my experience when this false positive happens the robot is in safeguard for a very short time, maybe less then a second.
I recommend the second solution because that's usually what you want to do when a safeguard that's not a false positive is triggered - when someone bumps into pepper, or shakes her, etc.
Everything is pretty much in the title, I have tested using Display Changer but without success because my monitor are both named "Generic PnP Monitor" so I can't say which screen must be set as the primary. I've seen that i need to download the drivers to get my monitor a name but both of my monitor don't have driver for Windows 10. I would think there must be a way to simply swap the principal screen to the other one or something like that but I haven't seen anyone do it.
Maybe you can try nircmd.exe which is a small but powerful command-line utility .
http://www.nirsoft.net/utils/nircmd.html
setdisplay {monitor:index/name} [width] [height] [color bits] {refresh rate} {-updatereg} {-allusers}
....... You can specify the monitor by index (0 for the first monitor, 1 for the second one, and so on) or by specifying a string in the system monitor name...........
Another solution is to use the multi monitor tool, as it allows for more functionality towards switching monitors, such as moving windows as well. Also has a simpler command for the basic task at hand.
http://www.nirsoft.net/utils/multi_monitor_tool.html
/SetPrimary <Monitor>
Set the primary monitor.
Example:
MultiMonitorTool.exe /SetPrimary 2
I'm trying to use whole body balancer made by Aldebaran to make my nao dance more steadily and to be less dependent on the surface horizont level, to neglect some small tilt.
I've succeeded in requesting nao to go to balance, but enabling balance constraint gives me nothing. For testing, I designed an ill-balanced timeline which leads robot to fall down when the body balancer is disabled and should keep the robot stable as log as it's enabled, that's what Aldebaran declares as a use-case. However, the robot still falls down (I keep him vertical with my hand) and then goes to balance due to ALMotionProxy::wbGoToBalance. It is strange, however, that he reaches balance in a rapid move, rather than in 3.0 seconds that I requested.
My suggestion now is: whole body balancer needs some resources (joints) that are actually used by my timeline (it uses all the joints). Is it correct? Can anyone confirm or deny this?
The source I use is generally this one:
self.proxy = ALProxy("ALMotion")
self.proxy.wbEnable(True)
self.proxy.wbFootState("Fixed", "LLeg")
self.proxy.wbFootState("Free", "RLeg")
self.proxy.wbEnableBalanceConstraint(True, "LLeg")
I use this source inside a box in Choregraphe 1.14 and it is definitely called (it leaves logs I stripped out). And it definitely gives me no exceptions, I check and log them.
Yes, I think that you must remove some joints from your timeline.
The test is easy: disable for instance ankles from your timeline and see the results.
Disabling some joint is easy:
open the timeline
click the small pen beside the "Motion" caption on
the left
then uncheck some circles (for instance the LAnkleRoll
circle): so those joint animation will be disabled.
retest
I'm working in a embarked application on linux that can be used with different PC hardware (displays specifically)
This application should set the environment for the highest allowed resolution (get by
the function XRRSizes from libXrandr).
The problem is: With some hardware, trying to set for the highest option creates a virtual desktop i.e. a desktop where the real resolution is smaller and you have to scroll w/ the mouse in the edges of the screen to access all of it.
Is there a way to detect within the Xlib (or one of it's siblings) that I am working with a virtual resolution (In other words, the re-size didn't go as expected) ?
Hints for a work around for this situation would also be appreciated...
Thanks
Read this: http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt
You need to learn the difference between "screen", "output" and "crtc". You need to check the modes available for each of the outputs you want to use, and then properly set the modes you want on the CRTCs, associate the CRTCs with the outputs, and then make the screen size fit the values you set on each output.
Take a look at the xrandr source code for examples: http://cgit.freedesktop.org/xorg/app/xrandr/tree/xrandr.c
I recently wrote a program to display data on a set of LCD TV's. The data is for the most part static with the exception of refreshing from the database every 60 seconds. I know screen burn isn't as big an issue with LCD's as Plasma TV's, however, I would like to try and minimize the risk. These screens will be running for 8 hours a day.
I programmed a small square that bounces around the screens on top of all the data. The square constantly changes colors as it goes. I did test that it hits every pixel on the screen. It completes a "cycle" every couple of minutes.
Is that sufficient to mitigate the risk of burn in? Or do I need to make something more complicated?
Discard all the effort altogether, LCDs do not sufer from that problem at all.
And that square is probalby annoying, and even if it were to do any good, it would have to stay on the screen for longer period of time.
And - I wouldn't worry, 8 hours per day is normal. If you are paranod, you can move the window / re-place the text every so.
That is not true exactly. While LCD don't suffer from what burn in actually is. They do have a similar problem, especially when used as a computer screen, or left on a tv guide. An image will stick if left on the screen long enough, usually goes away but it can be permanent.
The program you are describing sounds like it would work just fine.