Re: Let's have Linux Robots Next Year!
 

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.

Re: Let's have Linux Robots Next Year!
 

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...ain/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,

Re: Let's have Linux Robots Next Year!
 

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!

Re: Let's have Linux Robots Next Year!
 

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?

Re: Let's have Linux Robots Next Year!
 

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

Re: Let's have Linux Robots Next Year!
 

This sounds like a lot of fun. Let me know if you guys need help making it happen.

-Kevin

Re: Let's have Linux Robots Next Year!
 

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.

Re: Let's have Linux Robots Next Year!
 

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.

Re: Let's have Linux Robots Next Year!
 

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.

Re: Let's have Linux Robots Next Year!
 

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.

Re: Let's have Linux Robots Next Year!
 

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

Re: Let's have Linux Robots Next Year!
 

Its not worth converting, just posted it as an example PC-RC interface to give you all some ideas.

Re: Let's have Linux Robots Next Year!
 

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



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?

Re: Let's have Linux Robots Next Year!
 

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

Re: Let's have Linux Robots Next Year!
 

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/v...rceCoProcessor) this seems like the home of our coprocessor project. The page is horribly unfinished right now, so ignore it for a couple days :).