![]() |
Re: Let's have Linux Robots Next Year!
Quote:
Another great advantage of this setup is logging driver activity or CMUCam activity. Useful statistics can be aggregated. |
Re: Let's have Linux Robots Next Year!
Quote:
|
Re: Let's have Linux Robots Next Year!
Quote:
Quote:
|
Re: Let's have Linux Robots Next Year!
Ok, I'm now into the "design phase". I plan to have two separate primary processes:
1. Serial Communications Daemon -- Gets new data from RC, sends output back to RC. 2. Worker -- Receives data from #1 through pipes, and uses the other pipe to send data back. A few notes: Both #1 and #2 will be written in C++ for now. I really wanted to write #2 in Python, to give users a simple language to work in, but it's too slow in preliminary tests... Further investigation is required in that aspect, but it doesn't look too promising. If anyone has info/experience on this, please let me know. These apps will run on any standard *nix distribution with a gcc compiler -- theoretically even Cygwin! Once these are written, I want to do some performance testing, on at least Ubuntu [Debian], Gentoo, Slackware (all with -ck / latency-patched kernels), and on FreeBSD (which claims top-notch performance). |
Re: Let's have Linux Robots Next Year!
Quote:
|
Re: Let's have Linux Robots Next Year!
Quote:
We haven't done a whole lot with it (we completed it sometime in the last two weeks of build time) but we have some plans for it for this year and next year. So maybe we should share ideas and the like sometime after season. |
Re: Let's have Linux Robots Next Year!
Cool. If you guys are willing to share the source, it makes no sense for me to start from scratch....
|
Re: Let's have Linux Robots Next Year!
Ok, clarifying:
If I was to take a laptop, remove the screen and unnecessary accessories (i.e. Speakers, CD-ROM, Floppy), it would be LEGAL to place it on the robot? Would supplying it a battery be legal, or would we have to use power from the robot's breaker panel? |
Re: Let's have Linux Robots Next Year!
Quote:
Quote:
Guys, this is a really good idea and its awesome that you are thinking "out of the box" this way, but you should really consider if putting a full-fledged PC running Linux on the robot isn't overkill. Just about anything you want to do could be accomplished with a reasonably powerful microcontroller and maybe a very simple RTOS on top of it. We've been doing some fairly complicated things with our custom circuits the last 4 years and we don't use any OS at all. If you're interested, check out some of these pre-built microcontroller boards that are (to my knowledge) fully legal under this year's rules: HC912D60 board (uses a Freescale HC12 microcontroller) from Kevin Ross (and I believe he's on a FIRST team!) CardS12 - Another Freescale HCS12 microcontroller board Or, if you're really set on using Linux then you should check out this product. It uses an ARM processor, runs Linux, and has just about all the features I think you could want, and it starts at about $150 (comparable or less than what you'd pay for the laptop, I imagine). It also runs it's code from CompactFlash - which is an important feature! I really doubt most laptop harddrives would survive use on a FIRST robot! |
Re: Let's have Linux Robots Next Year!
The first post did a great job of summarizing why adding (not replacing) standard operating systems would be beneficial for FIRST programmers.
To reiterate, scripts are great because non-programmers can quickly get robots executing. Keep in mind a vast amount of FIRST kids that can not learn to program in C properly in their high school period (embedded programming is tricky...). Especially now that most high schools are teaching JAVA which also demonstrates why higher level languages are better for kids. Scripts (Perl, Python) versus C versus JAVA should become a whole new topic. We should also think of FLL and the upcoming VexRobotics which has kids programming in GUIS which can never fully get kids into C programming, scripts however come closer. I have used gumstix extensively and I feel they are fantastic but too small (currently) for FIRST. Smaller kit robots such as FLL, Vex or botball are great for the gumstix because of their size. Since FIRST robots have room to store a laptop, that should be a top choice of embedded PCs due to their cost (<$200). To get a feel for why PC's are so important in robotics, take a look at Player/Stage. Particularly “Pyro Robotics” (google it) which has a live cd of what FIRST robots could be ported quite easily with a laptop. The great thing about a PC is the vast functionality and scalable potentials. With many pre-written drivers (player/stage) for common sensors such as sonars, laser rangers, IMU, gps, cmuCam, etc... integrating a PC into the existing PIC system is a great idea. IFI would have to change very little since they leave a programming port open on the RC which can communicate to the laptop on transferring commands. The drivers and data transfer should most likely be standardized (base level) by FIRST for teams to quickly began development. The live CD can be downloaded burned onto a blank CD and started up in the PC's cd drive. If you read the directions for Pyro you will be amazed by the different real time functionality. Especially the multi-agent system programming which could really help teams sync between alliances and have fantastic simulations to work out the bugs. Pyro runs a great 2D and if you are lucky 3D simulation of real time robots !! If you have any questions, feel free to contact me, andrewlynch <at > mail.utexas.edu ~Andrew |
Re: Let's have Linux Robots Next Year!
I've been considering getting a gumstix and trying to interface it with the controller. This would leave the processor free to handle nothing except for serial communications, and extreme limits (We have several limit switches on the robot, which should never be activated, if they are, something very bad has happened, and they prevent damage. Not something that requires an external processor)
I've yet to come up with a good reason to do so though. The best one I've come up with so far: Remote programming. Hook a 802.11 adapter up to it, and a serial port to the RC. SSH into it, WGET the .hex file, use ifi-loader to get it, then watch the serial port for printf's... all without getting up :) Not legal during a match though.. hrm. |
Re: Let's have Linux Robots Next Year!
We have been looking at building linux robots, but we would likely just quit FIRST and start our own open (basically no rules) competition here in Alaska. The competition would be almost entirely autonomous. And as far as the computer you use check this out . That site (www.mini-box.com) has everything you need to make a linux robot that should be legal within this years rules. You use one of the bootable flash adapters with one of the motherboards I cited above, and one of their 12v-12v power supplies and you got yourself everything you need to convert your FIRST robot to be under linux control. Best of all that motherboard I cited is about six inches square, and pretty light, as are the rest of the components. But if you want to use it in actual competition you need to either get the fanless model, or use a FIRST fan run from a spike. And be sure not to use any hard drives or other devices with motors.
|
Re: Let's have Linux Robots Next Year!
I agree that using Free Software for FIRST Robotics should be a high-priority goal. As someone already mentioned, Player/Stage would be a very cool way to go.
Right now, I am just trying to get to the point where I can program the FRC from Linux. Building WINE now, but hoping to use SDCC instead if possible. Anyone interested in a FIRST-LINUX mailing list? I am having some trouble finding the current threads here on the forums... |
Re: Let's have Linux Robots Next Year!
Quote:
|
Re: Let's have Linux Robots Next Year!
Just to give everyone a status update:
1. I've started designing the serial communications protocol. Right now, I'm thinking of simple parity/checksum authentication, and data that isn't transferred in a loop (i.e. lost some bytes) will be discarded (the value from the previous sync will be applied). I was thinking of a pick-up-where-left-off, but that would add a very nice amount of start-bit-parity-stop-bit overhead, which I deemed impractical. 2. I've chosen FreeBSD as the development platform, mainly because I've found it to be much more responsive interactively on the particular laptop I'm using, and much more resilient to damage as far as abrupt power kill goes. 3. I'm still testing if FreeBSD will support the Linux picloader & WINE MCC18 system. It'd be so cool to load code practically hands-free. |
| All times are GMT -5. The time now is 20:14. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi