Posted by Genesis Factor on September 24, 2008 at 3:00am
Woot offs are great! I am hoping to buy a recorder like the one i posted for sale the other day :)Okay...here we go...We're no longer loading down that poor little predator. Infact, it's role has be relegated to a training machine versus the final project. The main board has changed to something else, lower powered, but, still fun. No programming will be changed, and the basic idea of a network based remote controlled UAV will still be in that plane. The full project isn't dead, it's just been moved to staged development system. Why? Because better things are on the horizon...plus this path makes sure that everything that i have done and have bought thus far wasn't a waste.Changes:New Board.New OSNew Programming OptionsOther changesThe new board is a recently procured Viper-Lite. It is basically a DIY Pocket PC with a PXA255 200Mhz Xscale processor. It is small, 1.8Watts of power, adnd has only serial ports and a CF card slot of expansion. It is NOT IDEAL, as i was hoping it would be the regular VIPER with USB Host, but nothing that I've been playing with has been, so what else is new. This board is forcing me to buy and change a few things, which is okay. My servo controller now has to be serial based, as does my GPS. I will be going with the Lynxmotion SS322. Although it is bigger than the parallax serial servo controller, it is much much better and i can program it much more easily. I will be forced to try and constrict EVERYTHING to a 10-14MB ROM, saving at least 2MB for failsafe operations, such as return to home if power fails, GPS coordinates, and recording where home is. the 64MB flash is all going to go to program memory if i can make it so. The camera is going to still be routed through the board. However, there is only one way to do this: using the CF card. I have a LifeView Fly Grabber. It has two ports, but i can only view one at a time. This means that i will have to switch between fixed FPV and panoramic. Finally, the large camera will be removed for a smaller one that just is permenantly zoomed in with an optional 2x zoom. I am not sure if i can do video recording and streaming on this device, so there will be no real onboard recording. Finally, this board DOES have an ethernet controller, so the wifi based netwokring will have to be handled by an wireless game adatper, with converts 10/100 to 802.11b/g. My choice for that is the Linksys WGA54G. Power will still be the two batteries, but i may have to build a regulator...again...joy.The new OS is Linux, Debian. Also, good news, Urbi has given me access to their engine to make my own. I am very happy with that news, but i wasn't able to touch it due to recent tragic events (RIP Shaf). Running linux will allow me to run the VLC.ipkg. Using that, i can stream to and record at the base station. A joint MSRS and Urbi will be running on the board, with MSRS handling the basic flight and UAV functions and URBI taking over for more complex commands. Sorry MSRS, i know C++, and C# is hard. What this means is that when the plane moves or goes to a waypoint, all instructions are handled by MS. If i move the camera, that is also handled by MS. However, the more fun things i want to play with, such as object collision avoidance, will be handled by Urbi. If MS fails me, Urbi will take over form there and that will be that.The one thing that is upsetting is that ARCOM, the makers of the Viper, refuse to help me at all because i am a second hand buyer. All i needed was a sentence on how to make sure that Linux/CE made it into the ROM that the manual didn't answer. They suggested that i join the forums, so i will. Hopefully a kind soul will take me from there.The final set of changes are in the base station and other gear. I have a new laptop and sold my other ones. It is an IBM T60 (yay dual core!). The transition has been rough, but i finally have the system how i want it, so now i can install/reinstall the necessary software. I'm still installing my basic stuff and it's been back form the depot for a day now. There will be another thing that i will be adding to the base station, but that is just a forethought. Also, this project needs to be done programming by November. Flying before the dead of winter. I technically have until Janurary to do the debugging. Then my feet will hopefully meet the horizon, and more fun things will happen. That and school. Finally.Cost estimates for new suppliesSerial GPS (may have one that works already, but $40+)Lynxmotion SSC- $40Linksys WGA54G- $40-$50 ebay. going with a FON router flashed with DD-WRT. I 'll make it a wireless brigde. It is cheaper than a WGA54G and it is better as i have a whole bunch more controlTotal- $130. $200 is my cushion savings amount.If anyone can help me with Debian booting from the rom, please do. i know it is a tough question, but once i get debian running, the rest is gravy.
hey Paul. sorry about the delay, i have been back in school. I spent alll of winter break making money for school and building a computer. Now that i have that money, now i get to make money back for the project. I have to write a new blog. i have new people going to help me in terms of programming who are VERY interested in this project.
As far as teh GPIO ports, SPI is pretty annoying to get working on a C/C++ basis. i am REALLY tempted to by a PIC JUST to handle the SPI. I have TWO programmers working with me now, so yes...i will have SPI out for you. With their permission, i will try to make it readily available for the community to use ( a basic C template). If you know any, please let me know.
also, if you use the arcom viper, be SURE to get teh 400MHz one with the PC104 bus. If you just want a 200mhz or don't need PC104, contact me, because i seriously don't need the board. THe reason for that isthree fold. I have given up on my programming abilities in VPL, due to lack of time. Also, now that i have my programmers, and now that i am in school, it will really just sit there and i'm going to jump right into the big plane (still in touch with criag horner, he has the 14ft predator) Trust me, it will be cheaper than you can get it anywhere else. Oh, the Arcom people are nice too! If i ever get back to this plane again, and i hope to, maybe, for a small sized UAV, then i will probably go with the NVidia ION. for it due to onboard CUDA. :)
Hi, I am also thinking about using the Arcom Viper for a project. Can you provide me with more info on the GPIO ports being used for SPI? Have you got that working in your project? Thanks!
Just adding a pic for size comparison between the two systems. Hopefully Chris approves and i get a nod from Craig lol. The only parts missing are the serial servo controller (the USB is going to someone who wants a trade) and the GPS and the wireless adapters :)
Are you serious? geez, i always thought no one but Chris and Craig read my ranting...
the ethernet bridge is for uploading the linux image. that's it really. after that, i will be using a regular cable to a router to my laptop to control the servos remotely and test out the software and programming. Finally, get that La Fonera, DDWRT, and put that sucker in the sky, after tweaking.
lol no no talk away. I'll let loose a secret, as we are on ethernet bridges: the goal is for a network driven UAV. Not just wifi. Cellular too. In other words, a UAV that you can fly in austrailia from home using data rates. sure, the video will be crappy small, but kinda liek video calling, you can do whatever, whenever, and keep the data on baord. then when you land, or are on the trip home, you simply upload your vid/pics using the data network. Al you'll need is a sim card. this is why i can't use the great boards chris made. I actually spent some time looking at them and wondering if it wouldn't be better to use the audrino as the auto pilot and use my boards solely for video streaming and as the Rx, but i alreayd kind did the autopilot functions adn it doesn't take too much CPU to say, go a touch left lol. it's an idea if my autopilot fails. Also, teh GPS is on the board, not seperate, meaning i would either need to buy two GPS or just not GPS my board. Dean's attopilot rocks, but i haven't seen it's ports to know if i can interface with them or not.
As for your crawler, pick up some lego tank treads form a small building set or something. I ALWAYS prefer treads when dealing with areas where i might get stuck. hell, pick up 4 and you can put them on the top too for a nice squeeze lol. This way it can go under the house easily while being as offroad as possible. I mean, the last thing you want is for your crawler to get stuck because its rear wheels sagged into the muck. 2 servos for the camera, and the motor contorls form a simple RC car, gear drive the sucker with these cheap plastic gears form surplusshed.com (search gear), and you're in business. I actually have a nice stock of the vision equipment you need.(including IR illuminators and display gear) so let me know.
BTW, pics will be up soon. I am still doing my home network. New computer next month, HURRAH!!!
I noticed that you purchase a cat6 xover cable. What do you plan to do over the ethernet bridge? Like I said in my first reply, I'm really wondering why this isn't done more often. We use ethernet everyday for communications and pragrams/devices as well. I just don't know enough yet in this world (diy robotics) why we don't see it more often. To me even if it were somthing that seem pretty straigh forward like using the java based webcams to send pics/video to an onboard processor for capture.
I do follow your posts because they always seem to be a good read and I always get something from them. Shoot I even picked up a couple of the spy-cars you once talked about hacking. (I'm interested in them for my creepy-space crawler) The units seem to be great starting platforms. They are heavy enough, quiet, onboard cam. I'm planning on using ir cam to study how moisture/fungi/bugs/dryrot look on the underside of a house. This along with hi-res visible light camera an inspector can record a quick video to show the customer any damage that's in their house or a house they plan to purchase. - Sorry I guess that's for another blog!
hehe i didn't want to sound like someone who just flames suggestions, and wanted to listen. I get you, trust me, because, my system is actually quite modular
In terms of modular design, all parts i am buying for this board can be stripped off and put on any other board, other than the processor and flash rom and ram.
The board is handling video streaming, autonomy, and data streaming at once. In autonomy, there is waypoint and light computer vision. I can't do that with adrino, parallax, or anything form sparkfun (believe me, i checked).
Go through my other blogs and you will see what the workings looked like before i did things this way. i used pc104 moldules to do almost everything.
Hehe, call it what you want, i call it a headache. I'm sure a few people were like, why are you pretty much starting over system wise. However, when i showed my dad the difference between system A and system B, where 1 board replaced the need for 4 others, reducing weight and size substantially, it really became quite clear that this was a decent path, at least for this plane
When it comes to programming these little devices I'm totally newb (period!). I'll tell you from my perspective what I'm talking about with modulization (is that a word?).
I'm a systems guy. I'm responsible for the build process used in the field to deploy server operating systems. This includes the operating system, core security patches, security software (AV, Firewall, SPAM), core program updates, and base application tool sets.
I could wrap this all up into a single deployable unit that the filed techs use to deploy servers.
But... New updates, application patches and tools are updated all of the time, some at a very feverish pace. So when a field tech has used an all in wonder build they must immediately go to some location, find the latest updates and apply them all prior to the server passing baseline check-out.
I group the builds into logical modules where common components are installed and updated without affecting modules that have not changed.
So my Modulized approach would be similar to this:
The base operating system with core security and updates are all rolled up into a single install, which calls a script which kicks off the next module, this might be a security module, which has been updated many times since the "core" OS install was established. This module finishes. The install script calls the next module which might be base system applications, which has changed only once since the OS install was established. This module completes and the install script calls the module that installs the technician's toolbox. Which hasn't changed at all because the company is cheap and does not want to fork out any $$$ for updated tools for IT Techs.
This process is kicked off by a field tech which may be via a network load or a DVD install, but the process knows where to go to get the next module which is always up to date and completely tested before making it's way to the production build-point. At any point in the process any module can change and not affect the others so long as the same protocols are used to call each module into action.
I could totally see an approach where multiple boards are used to complete different parts of a diy uav's mission, in fact that's what is already happening w/out stuff now. We have the ardino's talk'n to the radio reciever which is talk'n to the Co-Pilot, a camera/video controller is in place somewhere and don't forget the GPS, all different boards following common protocols to make something happen.
A wireless or wired ethernet connection is just another way to have a switch flipped and something happen, maybe something as simple as using an ethernet based java coded webcam to send video to another onboard device for storage. People do that everyday on the ground...
When I get a little more practiced I'm planning on something close for a ground based rover for doing crawlspace inspections on houses.
i'm curious to what you would suggest. i wrote a long thing, but i realized that i speak from an area of weakness and you from, possibly, an position of knowledge. my EE friend always tells me what he can do with a PIC, execpt it never is what i want to do, so i wanted to hear you out before i told you WHY i am using this "jewel" :)
With onboard ethernet capabilities I've always wondered why folks don't plan on haveing one board do stuff and talk to another board which does other stuff. You could take a board like this jewell and talk to one from sparkfun (for far le$$) and do all kinds of stuff.
I'm sure somewhere in the reason is the complexity of having to design code that does the interactions but you have different functions on a single board that need to talk to other parts of the board/program and do stuff, which is also complicated.
To me making things modules might make system upgrades easier in the future when parts change and get better. You'd only need to upgrade the one module and possibly not everything.
Comments
As far as teh GPIO ports, SPI is pretty annoying to get working on a C/C++ basis. i am REALLY tempted to by a PIC JUST to handle the SPI. I have TWO programmers working with me now, so yes...i will have SPI out for you. With their permission, i will try to make it readily available for the community to use ( a basic C template). If you know any, please let me know.
also, if you use the arcom viper, be SURE to get teh 400MHz one with the PC104 bus. If you just want a 200mhz or don't need PC104, contact me, because i seriously don't need the board. THe reason for that isthree fold. I have given up on my programming abilities in VPL, due to lack of time. Also, now that i have my programmers, and now that i am in school, it will really just sit there and i'm going to jump right into the big plane (still in touch with criag horner, he has the 14ft predator) Trust me, it will be cheaper than you can get it anywhere else. Oh, the Arcom people are nice too! If i ever get back to this plane again, and i hope to, maybe, for a small sized UAV, then i will probably go with the NVidia ION. for it due to onboard CUDA. :)
the ethernet bridge is for uploading the linux image. that's it really. after that, i will be using a regular cable to a router to my laptop to control the servos remotely and test out the software and programming. Finally, get that La Fonera, DDWRT, and put that sucker in the sky, after tweaking.
lol no no talk away. I'll let loose a secret, as we are on ethernet bridges: the goal is for a network driven UAV. Not just wifi. Cellular too. In other words, a UAV that you can fly in austrailia from home using data rates. sure, the video will be crappy small, but kinda liek video calling, you can do whatever, whenever, and keep the data on baord. then when you land, or are on the trip home, you simply upload your vid/pics using the data network. Al you'll need is a sim card. this is why i can't use the great boards chris made. I actually spent some time looking at them and wondering if it wouldn't be better to use the audrino as the auto pilot and use my boards solely for video streaming and as the Rx, but i alreayd kind did the autopilot functions adn it doesn't take too much CPU to say, go a touch left lol. it's an idea if my autopilot fails. Also, teh GPS is on the board, not seperate, meaning i would either need to buy two GPS or just not GPS my board. Dean's attopilot rocks, but i haven't seen it's ports to know if i can interface with them or not.
As for your crawler, pick up some lego tank treads form a small building set or something. I ALWAYS prefer treads when dealing with areas where i might get stuck. hell, pick up 4 and you can put them on the top too for a nice squeeze lol. This way it can go under the house easily while being as offroad as possible. I mean, the last thing you want is for your crawler to get stuck because its rear wheels sagged into the muck. 2 servos for the camera, and the motor contorls form a simple RC car, gear drive the sucker with these cheap plastic gears form surplusshed.com (search gear), and you're in business. I actually have a nice stock of the vision equipment you need.(including IR illuminators and display gear) so let me know.
BTW, pics will be up soon. I am still doing my home network. New computer next month, HURRAH!!!
I do follow your posts because they always seem to be a good read and I always get something from them. Shoot I even picked up a couple of the spy-cars you once talked about hacking. (I'm interested in them for my creepy-space crawler) The units seem to be great starting platforms. They are heavy enough, quiet, onboard cam. I'm planning on using ir cam to study how moisture/fungi/bugs/dryrot look on the underside of a house. This along with hi-res visible light camera an inspector can record a quick video to show the customer any damage that's in their house or a house they plan to purchase. - Sorry I guess that's for another blog!
In terms of modular design, all parts i am buying for this board can be stripped off and put on any other board, other than the processor and flash rom and ram.
The board is handling video streaming, autonomy, and data streaming at once. In autonomy, there is waypoint and light computer vision. I can't do that with adrino, parallax, or anything form sparkfun (believe me, i checked).
Go through my other blogs and you will see what the workings looked like before i did things this way. i used pc104 moldules to do almost everything.
Hehe, call it what you want, i call it a headache. I'm sure a few people were like, why are you pretty much starting over system wise. However, when i showed my dad the difference between system A and system B, where 1 board replaced the need for 4 others, reducing weight and size substantially, it really became quite clear that this was a decent path, at least for this plane
I'm a systems guy. I'm responsible for the build process used in the field to deploy server operating systems. This includes the operating system, core security patches, security software (AV, Firewall, SPAM), core program updates, and base application tool sets.
I could wrap this all up into a single deployable unit that the filed techs use to deploy servers.
But... New updates, application patches and tools are updated all of the time, some at a very feverish pace. So when a field tech has used an all in wonder build they must immediately go to some location, find the latest updates and apply them all prior to the server passing baseline check-out.
I group the builds into logical modules where common components are installed and updated without affecting modules that have not changed.
So my Modulized approach would be similar to this:
The base operating system with core security and updates are all rolled up into a single install, which calls a script which kicks off the next module, this might be a security module, which has been updated many times since the "core" OS install was established. This module finishes. The install script calls the next module which might be base system applications, which has changed only once since the OS install was established. This module completes and the install script calls the module that installs the technician's toolbox. Which hasn't changed at all because the company is cheap and does not want to fork out any $$$ for updated tools for IT Techs.
This process is kicked off by a field tech which may be via a network load or a DVD install, but the process knows where to go to get the next module which is always up to date and completely tested before making it's way to the production build-point. At any point in the process any module can change and not affect the others so long as the same protocols are used to call each module into action.
I could totally see an approach where multiple boards are used to complete different parts of a diy uav's mission, in fact that's what is already happening w/out stuff now. We have the ardino's talk'n to the radio reciever which is talk'n to the Co-Pilot, a camera/video controller is in place somewhere and don't forget the GPS, all different boards following common protocols to make something happen.
A wireless or wired ethernet connection is just another way to have a switch flipped and something happen, maybe something as simple as using an ethernet based java coded webcam to send video to another onboard device for storage. People do that everyday on the ground...
When I get a little more practiced I'm planning on something close for a ground based rover for doing crawlspace inspections on houses.
I'm sure somewhere in the reason is the complexity of having to design code that does the interactions but you have different functions on a single board that need to talk to other parts of the board/program and do stuff, which is also complicated.
To me making things modules might make system upgrades easier in the future when parts change and get better. You'd only need to upgrade the one module and possibly not everything.
-
1
-
2
of 2 Next