Let's have Linux Robots Next Year! [Archive]

jdong

08-03-2005, 16:57

I'd like to give a possibility for the nerdy/daring teams: A Linux-powered robot!

This year, FIRST introduced the whole idea of "Easy Programming". Though great strides, like integrated PID and navigation scripting, were made, I still think overall we as a FIRST community failed to provide easy programming capabilities.

I've began to look into the feasibility of having a Linux system control the robot through the IFI standard Robot controller, via RS-232. Currently, it looks quite promising. Kernel-land control would work effortlessly, and I'm still seeing if user-land control can respond in time. This approach has a number of advantages over just the IFI Controller:

1. "REAL" programming language: You get full access to a standards-compliant, well-equipt programming language, not the watered-down buggy C implementation that we currently have. (No offense to Microchip, of course, we respect your efforts to produce a quality controller, acknowledge the great improvement that's always being made to MCC18, and certainly are gracious for your generous donations to FIRST). At the very least, you'll be able to use C/C++ (yeah, gcc/g++), and hopefully, you can use ultra-high-level languages, such as Python, Java, or Mono (.NET/C#).

2. Multiprocessing flexibility: Hopefully it'll accomodate multiple processes generating the data to output to the controller... That way, programmers can choose any algorithm they wish -- including lengthy loops (as long as the result comes out in time). The modular design allows teams to distribute binary components to others, allowing you to mix-and-match programs. Imagine how easy that'll be!

3. Open-source, Free-to-all programming: You can program on a Free, Open Source OS (Linux, etc), with a wide array of IDE's and tools.

4. It's cool -- Come on, who doesn't like Linux on robots?

A rough design:
In the 26.2 ms loop, the IFI RC's Default_Routine() will send a packet of all the Digitial ins, Analog in's, Joystick vals, etc to the serial port (Program or other one, who cares?)

The Linux control system will respond with packet(s) containing desired outputs.

The IFI

I've been looking through the 2005 rule book for any possible "loopholes" allowing this setup:

R54: Doesn't say you can't use other devices to "assist" the robot in calculation. Numerous allowed parts -- shaft encoders, gyros, etc do certain amounts of on-board communication.

There are clear rules against other devices outputting PWMs or other signals, etc. The Linux controller certainly won't do any of this ; all communication is done through serial, making it safe. Also, there's no methods of circumventing competition control, since the Default_Routine() and Autonomous_Routine() aren't called if you're robot is disabled.

There are virtually no rules on what's allowed at the driver's station -- Laptops are permitted. Communicating through dashboard on the OI would work, too!

This setup is inexpensive -- we're talking about a 200MHz laptop off e-bay, which usually is < $100. The software (Linux) is free.

As far as an "unfair advantage", I'll be perfectly willing to work with the community (and FIRST, IFI, etc), to document and provide example code and modules (Free and open-source, of course!).

Please, consider allowing this setup for next year! In the real world, straight microprocessor programming is being quickly phased out by autocoders (i.e. Simulink's RealTime Workshop). Embedded Linux is the future in control systems, and FIRST teams should have hands-on experience with this technology.

---
John Dong,
Team 245 Programmer and Misc. Electronics God

Ubuntu Linux, Forum Supermoderator
Ubuntu Backports Project, Leader & Coordinator
NYLF/TECH: Linux Security Lab, 2004 Staff

Adam Y.

08-03-2005, 17:26

This setup is inexpensive -- we're talking about a 200MHz laptop off e-bay, which usually is < $100. The software (Linux) is free.
It would probably be cheaper/lighter/more durable if you look at this www.gumstix.com

jdong

08-03-2005, 17:30

Hmm, Xscale chips... Same basic idea. It's just that I venture to say 90% of teams have some old laptop lying around without a purpose....

I personally prefer to work off an x86 based chip, because of my familiarity with them!

jdong

08-03-2005, 17:37

Correcting an inaccuracy in the original description: The Dashboard port is a 1-way interface. It can NOT be used (as it's currently set up) to send new data to the robot.

jdong

08-03-2005, 17:52

I've investigated a bit of kernel latency testing on my desktop, and have came to a conclusion:

26.2ms is an extremely slow loop. There's no problem with running any kind of code in this timeframe!

jgannon

08-03-2005, 19:31

Correcting an inaccuracy in the original description: The Dashboard port is a 1-way interface. It can NOT be used (as it's currently set up) to send new data to the robot.
I am intrigued by this project. However, keep in mind one thing:
<R69> All equipment connected to the Joystick Ports of the Operator Interface must be powered solely through the power available through the port. External power sources of any type are not permitted on any equipment connected to the Joystick Ports. Portable computing devices may not be connected to Joystick input ports on the Operator Interface.
As you've pointed out, the Dashboard port is one-directional, so the only way to send data to the RC is through the joystick ports. I don't know how this impacts your plan. Nonetheless, good luck, and keep us updated.

(On a side note, those gumstix computing devices look awesome... definitely something I'll keep in mind for future projects.)

jdong

08-03-2005, 19:48

Well, laptops are self-powered. :) They may only last a short time, but much longer than 2 minutes!

jdiwnab

08-03-2005, 19:53

Well, laptops are self-powered. :) They may only last a short time, but much longer than 2 minutes!

But they have their own batter (aka an outside power source). Now if you could have the computer powered by the controller...

Tom Bottiglieri

08-03-2005, 19:54

Can you find a laptop from a COTS supplier for less than $200? :p

One that is powered by the on site power source??

I thought about the same thing earlier this year. We were going to communicate to the RC via the ttl serial port and run linux on an old laptop to run some of the more complex parts of our code, but soon found it was illegal.

Venkatesh

08-03-2005, 19:55

Lets ignore the rules/rulings concerning intelligent dashboard-connected devices for a second.

We can use the dashboard port as the output from the IFI stack to the laptop. And we can use the digital inputs of the Operator Interface as the inputs from the laptop to the IFI stack. The parallel port on a laptop would be well-suited to that.

Now what do you gain? A high-latency link to all robot operations and the flexibility to do whatever you want with them with the full power of a PC.

For many common tasks on the robots, this approach is unnecessary and doesn't add any advantages. As an example, suppose certain sensor inputs directly influence some motors. To have the sensor data flow all the way up to a PC and back down would be pointless when local operations could have taken care of the task.

Before this year, I would have said there was very little incentive to stack a PC on to this system. The only tasks that the PIC can't do natively are floating-point math, and you can purchase a PAK-II or III coprocessor to do that far more easily than you can have a PC do it (in the off chance that you absolutely need very accurate floating-point math).

The CMUcam changes this. If we could read the raw data coming from the camera (as opposed to processed data), we could feed it to a computer for analysis and processing and whatnot. It is very difficult to outfit a PIC (even an 18f) for analyzing a video stream in near-realtime. If a PC could be used, sudden magic possibilites open up. We could have robots analyze the entire field in autonomous mode and react to different field conditions. The variable-position tetras this year would just be a small step. Imagine autonomous mode with variable starting locations and robot interaction. Other than the CMUcam, new and powerful sensors could appear. Robots might sport miniature radar/sonar/ranging tools, to create a view of the field.

If you are very interested and have experience with esoteric electronics, there is an option. Get a book called "Troubleshooting IBM PCs". It is an old blue book, from the early 1980s. Included are the complete circuit schematics of the IBM PC, XT, and PCjr, CGA and MDA video boards, and printer control systems. You can try playing with an 8086 or 8088 CPU and linking it to the IFI controller. Then, you can add the 8087 coprocessor. Such a setup would allow you to use 16-bit PC C compilers and linkers to generate code. But a warning - it will be exceptionally difficult and yield little more than some cool demos.

Things like this will be seen in the future. Right now, however, they would be too hard to implement, for many reasons, some technical, some logisitic.

The idea of using linux to assist robot control is definately not a bad one. Gaining access to the full firepower of an x86-platform would give electronics and programming teams a field day and an acute migrate at the same time.

And good luck!

AIBob

08-03-2005, 20:05

The current processor now has a lot of the system calls for linux (well some), there is no real advantage to having another operating system on the chip, it would consume too much space even with specially stripped down OS code.
Loading linux onto the robots would make the code even more of a mess.
*Just add functions of the things that are on linux and share them with the rest of FIRST, some other functions would not be too bad.

jdong

08-03-2005, 21:08

I think you're not understanding: We're hooking up another COMPUTER to the controller via the serial port, NOT loading Linux onto a PIC18F -- I agree that's a hopeless attempt!

As far as advantages, I'm most interested in using real C/C++. I still cannot live with Microchip C, losing pieces of results while multiplying longs, and FP math is well desired for PID constants. I was considering a touchpad-driven robot navigation system also, which is impractical on the given micro.

I realize it's against the rules right now; I was asking that if anyone on the magical committee is listening, please consider allowing this setup next year!

It's not difficult either to transform a breaker panel output to a laptop-compatible voltage, if no "external power sources" are allowed.

P.S.:
Venkatesh: I've had a number of issues with the micro already this year, implementing closed-loop PID control on a few separate motors -- everything from garbled RAM to unfinished calculations.

whakojacko

08-03-2005, 21:23

nice idea, but im not sure how practical it would be with the current system. First/ifi would have to change a good amount of stuff to get it to work. Would be cool if it could happen though

Venkatesh

08-03-2005, 21:32

I am willing to bet that at some point, FIRST will move the PC-based controllers. It will not be soon. But the trend towards electronics/programming challenges is unmistakeable. The appearance of autonomous, extremely powerful custom circuits, current sensors, encoders, the PIC, C, interrupts, and the CMUcam, all in 3 years. Control has had a busy few years and will continue to do so.

When FIRST introduced autonomous in 2003, but stuck with the Basic controller, they created the "Year of the Kludge." All sorts of interesting systems came together - processor interfacing, tons of sensors, etc. When FIRST comes up with a new superdemanding challenge and the kludges come out of the closet, they will have an incentive to move to PCs.

I'd bet on a PC/104 system, with an InnovationFirst Powersupply, auxiliary chips, and default code. Maybe 2010? Maybe 2015? Who knows.

Whatever it is, its coming.

devicenull

08-03-2005, 21:49

I'd love to see it opened up to in the rules. I think that would be all thats needed before you started seeing them more and more.. I mean, I can think of a couple of cool things to do right away:
Display what breakers popped over the match.
Record data from the sensors for an entire match.
Different cameras would probably allow better vision stuff :)

It would be very nice to have more power then the current system, and access to more tools :)

jdong

09-03-2005, 08:09

First/ifi would have to change a good amount of stuff to get it to work.

Actually, all they have to do is add a rule allowing processing devices on-board the robot.

Another great advantage of this setup is logging driver activity or CMUCam activity. Useful statistics can be aggregated.

seanwitte

09-03-2005, 09:48

Display what breakers popped over the match.
Record data from the sensors for an entire match.

You can do this already by collecting and logging data from the dashboard port...

Joe Ross

09-03-2005, 09:56

Actually, all they have to do is add a rule allowing processing devices on-board the robot.

Processing devices are allowed on the robot, your rule interpretations in the first post are correct. Teams have done it before, much in the way you described.

You can do this already by collecting and logging data from the dashboard port... Anything on the robot has to be expressed in 6 bytes, or more if you interleave them, loosing resolution.

jdong

09-03-2005, 17:46

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).

Alan Anderson

09-03-2005, 21:23

Anything on the robot has to be expressed in 6 bytes, or more if you interleave them, loosing resolution.
Unused PWMs can also be subverted to act as Dashboard telemetry bytes, as long as you never need a value of 255 coming back.

Kamikaze

10-03-2005, 01:34

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.

Actually team 955 has a working, simple communications infrastructure written in C that runs on a coprocessor (a 200mhz ARM9 SBC) to communicate with the FRC. It uses a very simple protocol. It's probably sufficient for most things and, more importantly, it functions.

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.

jdong

10-03-2005, 11:05

Cool. If you guys are willing to share the source, it makes no sense for me to start from scratch....

jdong

13-03-2005, 20:53

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?

Dave Flowerday

13-03-2005, 21:35

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?
The "fair market value" of the item would have to be $200 or less (based on this year's rules) and it would have to be available to all teams. Not sure how (for example) a used laptop off eBay would be treated with regards to this.
Would supplying it a battery be legal, or would we have to use power from the robot's breaker panel?
You would not be allowed to power it from its own battery under this year's rules.

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 (http://www.kevinro.com/documents/912d60/912d60.htm) (uses a Freescale HC12 microcontroller) from Kevin Ross (and I believe he's on a FIRST team!)

CardS12 (http://elmicro.com/en/cards12.php) - Another Freescale HCS12 microcontroller board

Or, if you're really set on using Linux then you should check out this product (http://www.embeddedx86.com/epc/ts7200-spec-h.html). 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!

lynca

14-03-2005, 19:57

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

devicenull

14-03-2005, 21:05

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.

russell

14-03-2005, 21:31

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 (http://www.mini-box.com/s.nl/sc.8/category.15/it.A/id.230/.f) . 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.

tux

03-04-2005, 18:47

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...

jdong

04-04-2005, 11:36

Anyone interested in a FIRST-LINUX mailing list? I am having some trouble finding the current threads here on the forums...

I'll go into our sourceforge project and make some mailing lists later.....

jdong

04-04-2005, 19:10

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.

jdong

04-04-2005, 19:12

Building WINE now, but hoping to use SDCC instead if possible.

For OCCRA (local Michigan event), we solely used a Pentium-1 90MHz system running Ubuntu Linux + Ubuntu Backports for programming, and the "adambots-live" SF project has most of our work GPL'd in the CVS repo. It works very nicely :)

I don't think SDCC would be ready for our purposes any time soon.... The default code is VERY VERY finicky about the compiler.

lynca

05-04-2005, 23:23

I have looked into Ubuntu briefly, what type of real time support does Ubuntu offer?

I think we should devote a project page where we can list requirments on work to be done and existing work. Jdong, maybe this page exists on adam-bots live?
Actually I found it,
http://adambots-live.sourceforge.net/cgi-bin/view/Main/HelpWanted

I think, I am not sure yet what makefile is, I am going to test out ifi picloader but makefile is still foreign to me, possibly could use a bit more description on the wiki,

jdong

06-04-2005, 09:01

26.2ms is not that hard of a constraint. A C program running under any Linux/FreeBSD could probably handle it. I personally don't care what distro/OS to base work off, since it'll all be standards-compliant in the end.

I personally use Ubuntu on my desktop, and am the Super Moderator of the forums. I also lead a packaging project, Ubuntu Backports. I'm fairly involved with this distro!

tux

08-04-2005, 20:28

I am definitely interested in your idea of using _another_ computer in addition to the FRC controller. That way, we could just compile one set of code for the controller and use a standard (free) compiler for the real code and just bounce through the FRC and out to the robot. Much better than this nightmare with mcc18 and wine.

In any case, I am trying your ebuilds now, but having some trouble. I've sent a few messages to the adambots mailing lists.

Do I need to use a case-insensitive filesystem?

lynca

10-04-2005, 16:24

An important step in the separate computer process would be getting python to talk through the serial module using the serial.py module,

From there, using Kevin Watson's serial code through the Programming Port, the FRC will have a basic library (API) of commands like turn motor 1 on (#), turn relay 2 off, etc...
The API could be very similar to IFI's serial packet structure,

With a decent serial API for the RC, most everyone can use python in an interactive manner, robot go forward, robot go backward, etc...

python is a really easy to use language (which can be your first language)
check out this introduction video,
http://www.ibiblio.org/obp/pyBiblio/pythonvideo.php

Then after a basic serial interface between a laptop and FRC, we can consider integrating the FRC into a player/stage client which can use a 2D/3D simulator for people who do not have access to the robot. If we can achieve simulation level, suddenly code development becomes fantastic!, just look at a few of the neural net/ AI programs written for player/stage.

jdong, if you would like to discuss this else where, send me an email,
lyncas@gmail.com

~Andrew

Kevin Watson

10-04-2005, 22:24

suneel112

11-04-2005, 00:43

I bet this will sound stupid, but I really want to allow the option of programming the robot in Java.
Yes, I know it is not very useful, but that is the language of choice for the infinitely stupid CollegeBoard, and, since I was in AP Computer Science, the only language I learned.
I got to be quite good at it, and wrote a few programs to calculate motor torque and gear ratios for a telescoping arm with a gas spring.
Unfortunately, that skill was of no use to the robot, which only had one programmer this year.
I don't really see what's so bad with Java. Sun brags and says that the latest NASA robots on Mars are programmed with Java. FIRST should also use small, retro computers (instead of the RC) or an updated RC, with the equivalent of 500 - 600 MHz (32 bit, of course), 64 MB Ram, and 256 - 512 MB of storage. That will allow much more complicated autonomous programs (after two regionals, I still haven't seen a robot grab a vision tetra and place it on a goal) and much more accurate autonomous navigation.

My 2c.

thoughtful

11-04-2005, 01:09

This will be a great idea, all one needs is a motherboard with a serial port; let alone a laptop. The possibilities are endless, we can have webcams, sound synthhesizers, and so many other cheap gadgets that are used with computers. I dont want to get ahead of ourselves here, but if you guys pull this off this will be "The Move" for FIRST robots programming.

I am not as good as you guys but i will be honoured to help if needed.

lynca

12-04-2005, 00:08

I've already started playing with a serial interface by exchanging code between the standard IFI debug window and the PIC. However my progress has been slow due to hardware time and my real job.

The next step is sending commands through the Programming port using the IFI packet structure. Unlike the dashboard utilities provided, this will actually send commands for motors/relays like a normal human operator. Therefore little development is needed on the embedded RC.
If I have not properly looked through FIRST history on similar projects which might have accomplished this task, please let me know,

If you need a place to get started and you have programmed before, take a look at Kevin Watson's code, then at the IFI packet structure,

If you have no prior programming experience, I suggest you check out Python , especially a few of the python video tutorials, first "Python Tutorial "(google it) then check out this,
http://www.archive.org/search.php?query=Python you can start with Lecture 3, Python runs on Windows and Linux,

Java or Python are both great languages, the importance is easy learning curve and fast code development, therefore use whatever works and handles the serial driver request.

seanwitte

12-04-2005, 09:28

Last year I wrote a VB application to interface with the IFI mini-RC. The GUI has four "virtual" joysticks and 8 bits of input and received 8 bytes, 6 signed ints, and 16 bits of feedback from the robot. Once you get the program installed on the RC you can drive the robot around using your mouse. It also captures and plots up to ten of the IO channels. You can download it, and the program from the RC, from http://members.cox.net/seanwitte. I've posted this before but its been awhile. If you look in the pc_interface.c source file you can see the information being exchanged. The protocol is weak and blocks while its waiting for data.

I wrote that before I had a buffered serial port library so its a synchronous protocol with the PC. There isn't any error checking and it will crash the RC if you unplug the serial cable while its running.

If you design a standard serial protocol then people would be able to use it with any programming language. If you wanted to be really flexible you can design a framework that wraps all of the IO and loads "virtual robots" as modules at runtime. Sort of the way RoboCode works. Once you standardize the code running on the RC anyone can build a client framework to take advantage of it.

I know this is a thread about using Linux, but there might be a few people who would like to use Windows (well, maybe just me). For that I would implement the framework as a standalone exe and load the robot classes at runtime.

lynca

13-04-2005, 17:08

This is definitely a start, python works well on any platforms, VB is great but not a low cost solution or open source, but there exist VB to Python code converter.
http://vb2py.sourceforge.net/

It might be something worth looking into to avoid reinventing the wheel,
Any questions on python or serial communication , send me an email or please post,

~Andrew

seanwitte

14-04-2005, 08:04

suneel112

14-04-2005, 18:58

In terms of weight and size, probably the best computer to put on a robot (as a replacement to the rc ) is....

http://images.apple.com/macmini/images/indextop20050111.jpg

I guess that's off topic, since an apple machine can't run linux out of the box (it would have to be installed), but with a simple USB device (to handle the PWMs, Spikes, and inputs), it could be a reality. It would allow for a much greater degree of accuracy with autonomous, etc, would be about $800 (500 plus the cost of a USB device to link / contain PWMs and spikes), and would be very powerful (I think 1.3 Ghz is the slowest one they sell) to allow use of high-level programming languages.

If someone wanted to, they could make a PC like that, but why would they?

catlin101

19-05-2005, 02:33

Hm, i'm a bit skeptical about the idea of putting linux, java, or anything more complicated than whats currently on the controller.

The main problem is that many people have trouble tryin to get the most simple systems to work, systems that wouldnt benifit at all by multithreading or object orientation.

Like a few people said, FIRST provides all the calls that are "operating systemish" like memory allocation. I don't think that adding linux would really give you capabilities that are that much greater than the current system.

Its true that the vision systems didnt really work this year... but thats more a consequence of algorithms and not computing power.

Don't get me wrong, I like linux, but I just don't think that it would really provide anything beyond what the controllers already have.

If you do want linux, I think it would be a better idea just to integrate it onto the controller with an embedded 32 bit processor rather than a mac mini or something-- freescale and some other companies make a wider variety of 32 bit microcontrollers that are about 500 mhz, have a few megs of ram, and have linux ported to them already

jdong

03-08-2005, 15:24

UPDATE: In short, I have this system working, with a Python-in-Linux parser, which could soon be cross-platform.

About 150 loops towards the beginning get dropped, due to the Python script's startup and initialization time. I'm using Pysco to JIT-compile the Python code, and the script uses less than 8% CPU on my 1GHz programming laptop running Ubuntu Linux.

Currently, it performs readouts of two joysticks and outputs four PWM values. I'm gonna add more on. You can see live Subversion snapshots of the work at http://ubuntubackports.org/adambots-2006/ . gumstix/orion.py contains the Python PC parser, and ifi_code/trunk contains Linux-compilable source code.

It's not very user-friendly right now; I'll work on getting it polished a bit, and by the end of the month, I'll make a GPL'd beta release for you guys to play with.

BTW, we're starting to set up a wiki for our team, and (http://adambots.gotdns.com/cgi-bin/view/Main/DeltaForceCoProcessor) this seems like the home of our coprocessor project. The page is horribly unfinished right now, so ignore it for a couple days :).

Ryan M.

03-08-2005, 15:50

Cool... although I'm a little confused. :) So... the PC does all the processing, then sends the commands to the RC, which sets the output according to what the PC says? That's pretty nifty, and I'll probably try it out, but is that legal for a match?

jdong

03-08-2005, 16:44

Yeah, pretty much :)

Now that at least a proof-of-concept is working better than originally expected, I'm gonna augment the protocol to send more inputs and allow for more outputs.

mechanicalbrain

03-08-2005, 17:15

I am intrigued by this project. However, keep in mind one thing:
"<R69> All equipment connected to the Joystick Ports of the Operator Interface must be powered solely through the power available through the port. External power sources of any type are not permitted on any equipment connected to the Joystick Ports. Portable computing devices may not be connected to Joystick input ports on the Operator Interface."

As you've pointed out, the Dashboard port is one-directional, so the only way to send data to the RC is through the joystick ports. I don't know how this impacts your plan. Nonetheless, good luck, and keep us updated.

(On a side note, those gumstix computing devices look awesome... definitely something I'll keep in mind for future projects.)
I dint know if this was pointed out or not and i may be wrong but this refers only to the joystick ports. This is to prevent the unfair use of extremely expensive or nice control systems by limiting the power available. In fact I'm sure Ive seen control systems that integrated laptops for dashboard viewing. however i agree that the dashboard is not a two way connection. Ive seen allot of threads about using outside computing systems to augment or change the normal game play and i think that it should be explored for the learning potential but should not be attempted in game play as not only would this give teams a hugely unfair advantage it would also change the way the game is played. I didn't read every post on this thread so this might have already been pointed out and if so I'm sorry for acting like a parrot.

jdong

04-08-2005, 17:25

Ive seen allot of threads about using outside computing systems to augment or change the normal game play and i think that it should be explored for the learning potential but should not be attempted in game play as not only would this give teams a hugely unfair advantage it would also change the way the game is played.

I disagree. True, this may evolve the arena, but most of that would be restricted to Autonomous mode features.

Also, I am developing everything under the GPL, from the code required to support the protocol to the ways Team 245 is applying the coprocessor setup to our gameplay. I'd like to see innovation in programming at FIRST, for all teams to take it to the next level. This is just another way to help see that happen.

mechanicalbrain

04-08-2005, 17:39

I agree that its very cool and I too would like to see it. My only problem is that after talking to newer and smaller teams who have it hard enough building a robot and then come to compititions and see these arcwelded laser cut robots, will this be something all teams can easily utilize even ones with limited resources? If so power to you and please send me updates of your progress but if not maybe leave it out of the arena and more of a personal project as well as sending me updates. No matter how you look at it its a cool idea i just don't want to see small and unexperienced teams be limited in their ability to compete. :D

lynca

05-08-2005, 20:50

Jdong, I think you are leading the wave of a flexible software platform,

Suggestions for making your software more widespread: most people don't have a linux machine at therey fingertips (not yet anyway) therefore you should make a detailed tutorial on the wiki on how to get started, and make it very big and easy to spot,

this includes downloading subversion for windows or linux ,
running the first example of the code
and pointing out where development needs work,

I will be happy to help write the manual or develop code, just tell me where to start (which wiki page and where)

~Andrew Lynch

jdong

07-08-2005, 20:31

lynca -- you gotta understand, I JUST managed to get the communications protocol set. That's just the first step towards this programming platform.

My final vision -- The thing will use USB networking to talk to both Windows and Linux computers via HTTP, with the ability to upload or edit code. The "code" is written in Python, so just a text editor is required for changes (and a text editor runs on any OS).

In other words, the requirements for the FINAL coprocessor would be a web browser and a text editor!

I'm not ready to release this solution to the general public yet; more development on stabilizing the technology has to take place.

Our Wiki for the coprocessor is at http://adambots.gotdns.com/cgi-bin/view/Main/DeltaForceCoProcessor and http://adambots.gotdns.com/cgi-bin/view/Main/GumstixTutorial. The documentation is going to evolve as we're in a very early phase of development. I'd suggest that you hold on documentation until we reach the 0.5.0 milestone.