How important is Linux?

[EricVanWyk]

More importantly, how much lag is between the joystick and the Victor?

I'd assume that it is at most 2 "cycles" of 20ish (26.4??) milliseconds.

In other words, probably unnoticeable.

Great work guys, I hope to see more of this sort of awesome in the future.

[keen101]

Sorry to revive an old thread, but I'd like to input my say.

Kevin,

For the most part it is probably a small crowd. But, as the years go by more and more people are turning to Linux.

It's about freedom of choice and flexibility. FIRST has a philosophy that everyone should have an equal footing. But, in a sense FIRST is inadvertently restricting the use of resources to teams by forcing teams to use proprietary software.

For some that's fine, but for others it's a painstaking experience to find solutions to using it they way they want/need.

It'd be nice to have an Open Source solution for ANYONE who does not want to use the current MPLAB from FIRST. It could be multi-platform, so it courd be used by Linux, Macs, or Windows users.

With more freedom... Better talents and ideas can come though.

[emusteve]

Keen101, go ahead and revive it! Don't know who may be listening, but the topic is still relevent.

For my part, I'd like to see a system based on a popular core, and NO required software for the user processor. Required tasks, yes! But I see no need for FIRST to require the use of proprietary libraries, or a dictated framework. A Master processor in the system, can always take hold of the user processor via hardware (NMI or hold the Reset) if they need to override. Just require us to answer the Master when it calls, within a specified time window, and pass appropriate data. If you use a popular core (ie: ARM), an advanced programmer could use Linux, or any other ported OS, instead of whatever framework FIRST wanted to supply. Likewise, they could have their choice of available IDE or compiler.

The greatest issue for our team, is cost of the software. Programming isn't a curriculum item in our school district, so any instruction for new programmers has to come from the team. We can't afford licenses for the kids to take home and install, nor can we buy extra controllers. This year I started teaching C using a Zilog processor. The kit is only $50, and Zilog gives away (free on their site) the IDE >WITH< a FULLY FUNCTIONAL (read NO limitations, including Floaing Point and Trig functions) ANSI C Compiler. The IDE is very similar to MPLAB in look and feel. We've got more kids working on programming for this year than we heve ever had in the past.

Yes, I like Zilog, but I'm not saying its the best choice. What I'm getting at, is we need to have a controller and programming tools that are redily available and inexpensive for students to have access, and work with outside of the Robo Room. No proprietary boot loader or programming hardware involved, so they can practice on something that doesn't cost $1500, but still work with an environment that can be used to program the real thing.

We also need some self-contained subsystems. For a newbie programmer, trying to tune a PID loop operating across 3 processors (User, Master, and the Bit-Twiddler in a Victor), is a frustrating if near impossible task!

Steve

[keen101]

OK, thanks Steve.

If anyone out there is listening... Hopefully FIRST, then please hear what I have to say.

How important is Linux?

I don't know. For the most part it probably does not affect many of the FIRST community, but it does effect some.

It affects me. It is important to me.

It's important to a group of people, who want everything in FIRST to be accessible. Without that freedom, it's inadvertently suppressing peoples creativity and ability to learn.

Maybe I'm being over dramatic, but it almost seems like no one from FIRST or the community cares.

[neutrino15]

I like the closeness to the hardware of the current non-OS setup.

I completely agree. Before I started programming for first, I never interfaced with the hardware directly. Sure high level code has its advantages, but I feel like our current RC forced me to learn the low level concepts I would never have approached should I have stayed inside an OS. I feel that working on such a low level presents its own sets of challenges and teaches great skills. For example, interrupts and timers are great tools to work with directly.
That said, it would be nice to have a more powerful RC. Weather this means running a full blown operating system (go! linux! go!) or just having default code to match would be a non-issue to me as long as we still have open-ish access to low level operations.
The last thing I want to request is true object orientation. I don't think I have to explain myself here, but weather its a move from C to Obj-C or from C to Java, Object orientation really does have its benefits.

I feel, however, that a more pressing issue (for me) would be that of an IDE on linux/mac. FIRST Robotics is an organization of geeks (in an endearing way)! This means that of all the possible target audiences your software should apply to, this one has an abnormally high concentration of linux/mac users (half of our programming team does not use windows).
There are so many ways to implement an IDE across all the platforms.. Why should I need to have 20GB of VmWare (or parallels) on my computer to run the supported IDE? This is probably for another thread though...

p.s. I have been eyeing the Arduino project for a while. Its based on C and costs $34. Comes with USB onboard, open source, win/mac/linux, good documentation.. Not powerful enough for the next RC, but certainly to play with at home if you can't afford to risk breaking the team's RC!

[Capt. Quirk]

From my point of view Parallel processing is the future, not sequential processing with an RTOS. To be able to acomplish 8 - 16 or 32 tasks, all at the same time and more if you add what you can do sequentially in the processors spare time. And programming would stay the same or possibly be simpler.

[stevethetinker]

I would say that Linux on the controller is not important unless the robot controller system can also have disk files, a much wider telemetry link to/from the OI, etc. I suspect using Linux would make the "level playing field" problem worse rather than better. I agree with one of the other posters to this thread - writing Linux drivers is no picnic. The system we come up with needs to be much easier to use than that. Maybe one of the real-time variants of Linux would work. (I'm not familiar with any.)

No doubt there are a number of good RTOS designs that we could borrow from to implement these or similar ideas once we have a processor that can support them.

What we need is a basic RTOS that can provide one background "process" and provide an API that allows the programmer to hook up interrupt handlers. The one background process lets the programmer do compute-intensive tasks like navigation in a process that is not tied to the OI cycle. With the current framework such a process needs to be split into stages with such awkward constructs as switch statements. The worst part is writing the functions so that they can be called from the top each cycle. A background process in a RTOS does not need to be staged, or if coroutines are desired, a simple call to a RTOS function can be made to suspend the current coroutine so that another coroutine can be activated. The first coroutine then picks up at the spot where it left off next time it is activated through the coroutine interface. Coroutines don't require much API support (setjmp and longjmp are almost enough).

One key is that the 26.2 ms OI cycle needs to be driven from an interrupt, and there needs to be more than one priority of interrupts, so that things like gear tooth sensors can interrupt the 26.2 ms OI cycle interrupt (to be counted) and return to it. I think a system like this would help with the level playing field problem by providing support for interrupts (takes most of the arcane mumbo-jumbo out of it, though your new framework does a pretty good job).

Such an RTOS would not be complex (it could probably be written in less than 1000 lines of C code), but supporting it on our current processor would stretch it to the outer limits. I investigated the idea a couple of years ago and while I think it could be done, it is not practical.

[Bigcheese]

This year we are using Linux via a desktop PC modified to fit within the rules. There is almost no latency if you use the programming port to communicate with the RC, and the only code we have on the RC is code to send input updates and receive output updates (only 5 lines of code (and a lookup table (It's dang fast))).

I feel that Linux is very important due to ease of use, support, and no vendor lock in. You can figure out how to do just about anything on Linux with only a good understanding of google, and most of the code you need for anything is already written in just about any language under the sun.

[dcbrown]

and the only code we have on the RC is code to send input updates and receive output updates (only 5 lines of code (and a lookup table (It's dang fast))).

Since there is no code within the user PIC processor - which PCI boards are you using to do data aquisition (analog and digital) on the PC? How expensive were they? Did you find it difficult to write the linux drivers for these boards and for the sonar, gyro, accelerometer, etc. drivers? What was the interrupt latency you measured? Really interested in this last one since latency needs to be down under 20us for things like the GTS sensor. The only unix kernel I know of that has decent real time latency are unix kernels built on top of the MACH OSF/1 microkernel.

[Bigcheese]

Originally Posted by dcbrown

Since there is no code within the user PIC processor - which PCI boards are you using to do data aquisition (analog and digital) on the PC? How expensive were they? Did you find it difficult to write the linux drivers for these boards and for the sonar, gyro, accelerometer, etc. drivers? What was the interrupt latency you measured? Really interested in this last one since latency needs to be down under 20us for things like the GTS sensor. The only unix kernel I know of that has decent real time latency are unix kernels built on top of the MACH OSF/1 microkernel.

None. $0. No. 0μs.

Hope that answers your questions.

And then to explain. We do, as I said before, have a minimal amount of code on the PIC processor to forward input/output data between the robot controller and the Linux machine.

[dcbrown]

Hope that answers your questions

Not really. You stated

only 5 lines of code

and I'm wondering if that is true or if you are using the PIC to do all the robot h/w interfacing and only using linux for processing of that data.

It *is* possible to have five lines of code if the robot isn't using ANY controller digital inputs or outputs and has no pnuematics or sensors of any kind attached to the robot controller. In this case you can just pass the data packet from the OI to the linux box and vice versa. If that is the case then such a setup isn't useful for most teams.

[Cuog]

I think he has 5 lines of code that loop through the lookup table and send the data stored there back and forth. That would be pretty low line count and also give useful access to controls.