Yep that's what gave me the idea for the maze solver
Most of this code is the A* Algorithm. It works, as with the vision. The only thing I can't get to work right now is changing a light on the Prop with the Pi by sending an integer. Frustrating getting stuck on stuff like this with a deadline looming.
When using fdserial_rxChar(comms); it is definately recieving something it just isn't the integer I'm trying to send. Hopefully it's just changing it to char or something like that in the Pi program.
I've got it driving and turning now. Time to build the decision making loop and figure out how to actually navigate the solved maze. For now I'm basically just using drive_goto. The tough part might be calculating what angles to turn since the picture will be at an angle and in perspective etc.
and I can get a brief video stream on the Pi. However I can't get the camera to take a picture in OpenCV.
I only have like 4MB free space so I am weary of installing anything such as raspicam.h etc if I don't have to. Your code doesn't seem to include that but I keep getting what is apparently an empty image from the camera.
Thanks for the info dgately I wasn't aware of that.
I finally just purged wolfram for an extra half gig of space. I installed raspicam. I can now get a still image, I just have to figure out how to mess with the settings for brightness, image size, etc.
Things are moving alone! Hope to get you guys an update on all the code etc soon.
I'm just having trouble getting a good image INSIDE OpenCV. Right now the images are coming in very nearly pitch black. I'm trying .set( CV_CAP_PROP_etc ) and can't get anything even near an acceptable image.
Meanwhile I can use raspistill in the terminal and I get a fine image. Not finding good documentation to help with the darkness.
cap.set(...BRIGHTNESS, int ) doesn't seem to be working for me, nor exposure, reducing FPS, gain. Always something!
A couple years ago I was working on a university research project where we created a segway out of a Propeller in C (it was actually the first project to ever use PropWare). I learned a lot doing that project, and here's the two things I think will be most important for you:
I don't think there is a single other processor in the world that can time something as precisely as the Propeller's native waitcnt instruction - and that's exactly what you get with waitcnt2(a, b). Learn it. If you have questions, feel free to ask - but start by reading the API documentation linked above.
KISS should be obvious in general, but very specifically, I mean to point you at the MIT-sponsored high school segway: http://web.mit.edu/first/segway/That Segway was built with a 20 MHz PIC16 and NO interrupts!!! Oh my goodness. If a Segway can run on that, you can sure as heck program something on the Propeller. I thought, with all the extra speed I'm getting from the Propeller, surely I can program some awesome powerful precise fantastic loop that will create a ride that is 10000x smoother than those silly high schoolers. But I made it too complex and it never worked. After a month of tuning variables and buffer sizes and other crud, I gave up - I commented it all out until I was left with the bare basics - the same algorithm used by the kids in Massechusets. And you know what? It worked beautifully. So: KISS. Keep it stupidly simple.
Good luck, and I'll be keeping an eye on this thread to provide any help that I can!
Cheers,David
--Edit--
I previously said it was an Arduino Uno. I was wrong.
My current issue is that I don't know what color format is coming in from the Raspberry Pi Camera. I've tried CONVERT_RGB yet in OpenCV when I do cvtColor( img, img, RGB2HSV ) my pure red isn't in the 0-10 range but rather around 120-135. Also, the highest HSV Hue value is 180, while in my previous experience with OpenCV H goes from 0-360
I can still likely get the robot to work. The problem is my goal is to use the robot to introduce kids to computer vision and one of the fundamentals is the HSV wheel. I'd really like for red to be properly shown as 0-10.
Does anyone know how to get the right color out of the thing so I can relate this to the hsv color wheel?
Yeah I've tried that. I'll give it another spin but I don't think the Raspberry Camera Module/Board is sending the color as BGR. I might have to do some silly garbage like save the image, close it, and re open it to get known color values.
I'll give that one more try hopefully I just tested it wrong earlier. Thanks ratronic.
It's installed. Still getting the HSV issue. Red is still in the middle of the Hue spectrum. After a quick errand I'm going to see if I can subtract away the difference from the Mat and see if I can get the Hue to line up as it normally should.
Hopefully I can resolve this soon. I need to be struggling with my logic loop and detecting distances and angles for navigation. I don't have time for my camera to change colors me.
I've now got red at 0 and 360 (or 180 really) which is very good news. uv4l did the trick. I think it was raspicam.h that was getting me wierd colors, maybe YUV.
Thanks a ton ratronic. My HSV wheel is looking correct now that I can use VideoCapture cap; cap >> img;
Well everything was on track and now I'm getting Segmentation Fault and it keeps happening at different parts of the code. Pretty much SOL. Trying to intsall OpenCV on another Pi and just hoping for the best.
Have you given valgrind a shot? It if it's throwing errors in OpenCV, that's very much SOL. However, any errors in your own program should certainly be cleaned up and might well fix your seg faults.
Thanks SwimDude. Turns out it was a silly mistake on my part. I forgot I'd changed how I defined the size of a Mat. Took a very long time to narrow down since it was failing away from the mistake, and never giving a line number or reason for the problem.
Anyway it's working now, and at this point I am defining the points of travel mathematically. I might have to take a transform of everthing to look at it square, because I think the path of finding angles while looking in perspective is going to be more than I want to tackle in the day I have left before the event starts.
Do any of you know how to get findDominantPoints working on c++?
It keeps saying it's not defined in the scope.
I'm about to try to hack in the C version of it with CvSeq* instead of vector<vector<Point> >
Also, I'm only finding cvFindDominantPoints in legacy.hpp, which isn't comforting.
Is there another way to find the points in my path without writing my own algorithm? It would take me probably a day to do it. I've got the contour of the path.
For clarification cvFindDominantPoints requires cvarr etc, not the normal Mat c++ type format. I'm trying to find an actual supported method for finding the defining points of a series of connected lines.
Imagine making straight scribbles on paper. I want to find all the corners. Granted, it's pixels so a straight 45 degree line could be made of 100 corners. dominantpoints addresses this issue but I can't find how to do it without dominantpoints.
Comments
I'm now trying acc = fdserial_rxtime(comms,100);
still no luck for now
got me interested in this. He does a great job following a ball and reading signs.
Most of this code is the A* Algorithm. It works, as with the vision. The only thing I can't get to work right now is changing a light on the Prop with the Pi by sending an integer. Frustrating getting stuck on stuff like this with a deadline looming.
your loop until a character is received.
Edit: The forum wouldn't let me post an example but I use "if fdserial_rxCount > 0" then do a rxTime.
FYI I just got it to change the lights properly. Here is how I got it to work...
sudo shutdown -h now
unplug Pi
plug in Pi
re run program...
Well there went 4 hours!
Now I need to get the Pi to tell the Prop to either turn a certain angle or go a certain distance.
I'm currently thinking of sending a -1 for straight and a -2 for turn followed by a number representing either angle or distance.
Thanks a ton for the help so far ratronic!
I've done:
raspivid -t 10000
and I can get a brief video stream on the Pi. However I can't get the camera to take a picture in OpenCV.
I only have like 4MB free space so I am weary of installing anything such as raspicam.h etc if I don't have to. Your code doesn't seem to include that but I keep getting what is apparently an empty image from the camera.
raspistill -t 500 -o myImage.jpg
dgately
I finally just purged wolfram for an extra half gig of space. I installed raspicam. I can now get a still image, I just have to figure out how to mess with the settings for brightness, image size, etc.
Things are moving alone! Hope to get you guys an update on all the code etc soon.
[code]
Meanwhile I can use raspistill in the terminal and I get a fine image. Not finding good documentation to help with the darkness.
cap.set(...BRIGHTNESS, int ) doesn't seem to be working for me, nor exposure, reducing FPS, gain. Always something!
I'm trying cvtColor( img, img, CV_RGB2HSV ); and it's giving unexpected results
I've even tried cap.set( CV_CAP_PROP_CONVERT_RGB , true ); and it still seems to fail to convert to HSV properly.
this project looks absolutely fantastic
A couple years ago I was working on a university research project where we created a segway out of a Propeller in C (it was actually the first project to ever use PropWare). I learned a lot doing that project, and here's the two things I think will be most important for you:
- use waitcnt2
- KISS
I don't think there is a single other processor in the world that can time something as precisely as the Propeller's native waitcnt instruction - and that's exactly what you get with waitcnt2(a, b). Learn it. If you have questions, feel free to ask - but start by reading the API documentation linked above.KISS should be obvious in general, but very specifically, I mean to point you at the MIT-sponsored high school segway: http://web.mit.edu/first/segway/That Segway was built with a 20 MHz PIC16 and NO interrupts!!! Oh my goodness. If a Segway can run on that, you can sure as heck program something on the Propeller. I thought, with all the extra speed I'm getting from the Propeller, surely I can program some awesome powerful precise fantastic loop that will create a ride that is 10000x smoother than those silly high schoolers. But I made it too complex and it never worked. After a month of tuning variables and buffer sizes and other crud, I gave up - I commented it all out until I was left with the bare basics - the same algorithm used by the kids in Massechusets. And you know what? It worked beautifully. So: KISS. Keep it stupidly simple.
Good luck, and I'll be keeping an eye on this thread to provide any help that I can!
Cheers,David
--Edit--
I previously said it was an Arduino Uno. I was wrong.
My current issue is that I don't know what color format is coming in from the Raspberry Pi Camera. I've tried CONVERT_RGB yet in OpenCV when I do cvtColor( img, img, RGB2HSV ) my pure red isn't in the 0-10 range but rather around 120-135. Also, the highest HSV Hue value is 180, while in my previous experience with OpenCV H goes from 0-360
I can still likely get the robot to work. The problem is my goal is to use the robot to introduce kids to computer vision and one of the fundamentals is the HSV wheel. I'd really like for red to be properly shown as 0-10.
Does anyone know how to get the right color out of the thing so I can relate this to the hsv color wheel?
I'll give that one more try hopefully I just tested it wrong earlier. Thanks ratronic.
http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=14
That is the place to install the raspicam driver including raspicam extras. After that OpenCV will
see the Raspberry camera module and you will have a configuration file you can edit to change
things on the camera module at boot up. I.E. brightness, exposure etc. See my first post in the other Opencv
thread.
It recognizes the camera, I just seem to be getting a strange colorspace.
I'll try installing UV4L
as on that page you probably won't see one. To prove it plug in a USB webcam then look in the /dev folder
and you will see video0 shows up. If you install that driver it creates a video0 for the camera module which
OpenCV can now see.
Hopefully I can resolve this soon. I need to be struggling with my logic loop and detecting distances and angles for navigation. I don't have time for my camera to change colors me.
settings and also remove it in front of nopreview=yes. After saving that file then type this into the terminal -
sudo service uv4l_raspicam restart then give it another shot.
Have fun!
Thanks a ton ratronic. My HSV wheel is looking correct now that I can use VideoCapture cap; cap >> img;
Anyway it's working now, and at this point I am defining the points of travel mathematically. I might have to take a transform of everthing to look at it square, because I think the path of finding angles while looking in perspective is going to be more than I want to tackle in the day I have left before the event starts.
Down to the wire...
It keeps saying it's not defined in the scope.
I'm about to try to hack in the C version of it with CvSeq* instead of vector<vector<Point> >
Also, I'm only finding cvFindDominantPoints in legacy.hpp, which isn't comforting.
Is there another way to find the points in my path without writing my own algorithm? It would take me probably a day to do it. I've got the contour of the path.
Imagine making straight scribbles on paper. I want to find all the corners. Granted, it's pixels so a straight 45 degree line could be made of 100 corners. dominantpoints addresses this issue but I can't find how to do it without dominantpoints.