I am having a problem with my analog joystick. I have set it up to move the mouse position accordingly to the joystick values. On a technicality, it does work, as it does control the mouse. However, the calibration is off and when I test it, the mouse stays off-centered on the screen at rest and can only move around from that "center" position. I have scoured the internet trying to find a solution, but alas I must ask.
Snippet:
int xMapped = map(xread, 0, 1023, 0, 1920);
int yMapped = map(yread, 0, 1023, 0, 1080);
I have done testing to the joystick and can confirm the min and max values are correct.
(I feel like I may have weirdly worded the situation, so here is a ms paint visual :D)
Expectation
Circle-Mouse
Rounded Rectangle-Range
Rectangle-Screen
What Happens
Related
I'm trying to use a joystick to control the brightness of two LED's (which will eventually be replaced by stepper motors). The resting analog value for the joystick on the X axis is 504, with the minimum and maximum of course being 0 and 1023, respectively. My goal is to use a conditional to determine which LED to light, and how bright it should be. As the analog value approaches 1023, it should get brighter. as the analog value approaches 0, the other bulb should increase in brightness.
Here is the relevant code so far:
if (xVal < 500) {
analogWrite(7, map(xVal, 0, 500, 255, 0));
}
else if (xVal > 510) {
analogWrite(6, map(xVal, 510, 1023, 0, 255));
}
if the value is greater than 510, it behaves as wanted. The brightness steps up, until hitting 1023 where it reaches its maximum value.
For less than 500 however, the behavior doesn't work. It just does a maximum brightness when true, without adjusting the PWM. If I understand map functions right, shouldn't it be mapping an analog value of 0 to the maximum PWM value?
The answer was quite simple and actually did not fall within a code issue. I'm an arduino noob and I realized pin 7 (for the less than condition) does not support PWM. I changed it to pin 5 and it began working. I also opted to modify the map function to make it more sensible.
analogWrite(5, map(xVal, 500, 0, 0, 255));
}
This is how I changed it. Using the map to invert the value, I thought it made more sense to have the first range flipped, rather than the PWM range.
QPainter has many composition modes but none called additive. I'm interested because additive blending is used all the time in games for lighting / particles whatever.
The overlay mode is the only one that had something like the effect of lighting.
EDIT: I figured it out, heres how you can efficiently make different coloured lights in Qt.
In constructor or where ever, not in paint event:
light = QPixmap("light.png");
QPainter pix(light);
pix.setCompositionMode(QPainter::CompositionMode_Overlay);
pix.fillRect(light.rect(), QColor(255, 0, 0, 255)); // colorize the light in any color
Paint Event:
// Do drawing, e.g. a background
p.drawPixmap(0, 0, QPixmap("background.png"));
// draw the lighting
p.setCompositionMode(QPainter::CompositionMode_Plus);
p.drawPixmap(100, 100, light);
You can reuse the same pixmap as much as you like and draw it with different opacity or size etc.
The documentation for QPainter::CompositionMode_Plus says:
Both the alpha and color of the source and destination pixels are added together.
I'm trying to draw an icon(.png) inside a QWidget with QPainter::drawPixmap()
:
QPixmap _source = "/.../.png";
painter.setRenderHint(QPainter::HighQualityAntialiasing);
painter.drawPixmap(rect(), _source);
but in comparing to QLabel (for example) and in lower size (19*19 in my case) the result isn't perfect.
What can I do?
****Edit****
QLabel with pixmap # size 19*19:
My painting # size 19*19 via SmoothPixmapTransform render type:
You are setting the wrong render hint, you need QPainter::SmoothPixmapTransform to get smooth resizing. By default the nearest neighbor method is used, which is fast but has very low quality and pixelates the result.
QPainter::HighQualityAntialiasing is for when drawing lines and filling paths and such, i.e. when rasterizing geometry, it has no effect on drawing raster graphics.
EDIT: It seems there is only so much SmoothPixmapTransform can do, and when the end result is so tiny, it isn't much:
QPainter p(this);
QPixmap img("e://img.png");
p.drawPixmap(QRect(50, 0, 50, 50), img);
p.setRenderHint(QPainter::SmoothPixmapTransform);
p.drawPixmap(QRect(0, 0, 50, 50), img);
img = img.scaled(50, 50, Qt::IgnoreAspectRatio, Qt::SmoothTransformation);
p.drawPixmap(100, 0, img);
This code produces the following result:
There is barely any difference between the second and third image, manually scaling the source image to the desired dimensions and drawing it produces the best result. This is certainly not right, it is expected from SmoothTransformation to produce the same result, but for some reason its scaling is inferior to the scale() method of QPixmap.
I'm wondering if someone with more Arduino knowledge than me can point me towards the right direction to solve this. I'm trying to smooth out some accelerometer readings. I was following the suggestion to do so over here: http://arduino.cc/en/Tutorial/Smoothing
The issue is that I'm using a Light Blue Bean which has an on board accelerometer which calls a struct? And has some form of on-board filtering: https://punchthrough.com/bean/the-arduino-reference/accelerationreading/ | https://punchthrough.com/bean/the-arduino-reference/getacceleration/
I'm not sure how to go about this. Try and smooth each axis (https://punchthrough.com/bean/the-arduino-reference/getaccelerationx/)? work of the arduino digital smooth example? Maybe smoothing is the wrong approach?
Mostly its just giving me some big jumps in readings even when its sitting still. ie: the y-axis will be: 0, 1, -8, 0, 3, etc.. in a sample.
I am less than a novice on this, but this page https://punchthrough.com/bean/the-arduino-reference/getacceleration/
says the conversion for the units to "Gs" is 3.91X10-3. So, if you multiply the values you are getting by .00391, then you should get the units in Gs. Your value of -8 above is only -0.03128G. This is a reasonable acceleration for something "sitting still."
I am a little perplexed as to the trouble I am having with glOrtho(). My code works in the following case:
// Scenario 1
...
glOrtho(0, _width, 0, _height, 0, 1);
...
glRasterPos2i(0, 0);
...
However, I am unhappy with this coordinate system, I would like it to use:
// Scenario 2
...
glOrtho(0, _width, -_height, 0, 0, 1);
...
glRasterPos2i(0, -_height);
...
Unfortunately, only changing the two lines above in my code leaves me with a blank screen. I assumed I did not understand how glOrtho() and glRasterPos2i() work, as I am fairly new to OpenGl, so I tried the following:
// Scenario 3
...
glOrtho(0, _width, -_height, 1, 0, 1);
...
glRasterPos2i(0, -_height);
...
And, to my surprise, it worked! Why is this? The above code is not sufficient for my purposes, so I will stick with scenario 1 unless I can solve my problem. Does anyone have any insight as to why Scenario 1 and 3 work, but Scenario 2 does not? According to my web searches, Scenario 2 should work, so I must misunderstand something.
If it helps, I am using glDrawPixels() to draw an image, where _height and _width are the height and width of the image.
I am using Windows 7 and Qt 4.7.4.
If you need any more info, let me know.
edit: Typo in the original, it should read glOrtho(0, _width, -_height, 0, 0, 1) instead of glOrtho(0, _width, _height, 0, 0, 1).
You raster position is on the corner of the window. My guess is that round-off error is causing the position to be clipped in some cases but not others.
I think that the answer is glWindowPos(), which was added in version 1.4. Like the name says, it sets the raster position directly in window coordinates, unaffected by the modelview and projection matrices. Importantly, the raster position will always be valid, even if the position is on or outside of the window bounds. The disadvantage is that you'll have to do the coordinate mapping yourself before calling glWindowPos().