NEW 2009 Control System Released

[Richard Wallace]

Originally Posted by AustinSchuh

... It still would be nice if they let us program the FPGA ourselves.

Originally Posted by NetElemental

... If the FPGA is designed to automatically do many of the low level functions that we as programmers normally have to wrangle with (like what Kevin Watson's libraries are used for), it would be an incredible help. Imagine never having to write code to interface with the camera, or have the gyro angle automatically calculated for us instead of having to do it ourselves - there are much greater problems that could then be tackled.

Some teams might like to program the FPGA. Other teams might like to design their own custom motors. FIRST wisely limits the degree to which teams can engineer at the component level, for several good reasons. Safety is a big one. Reasonable limits on work during build season are another. Keeping teams focussed on the game challenge, rather than component details, is still another.

I'd favor no team programming of the FPGA. [But of course I'm not a VHDL programmer.]

I also favor keeping the rule against custom motors. [And I am a motor designer.]

[MikeDubreuil]

Originally Posted by Richard

I'd favor no team programming of the FPGA. [But of course I'm not a VHDL programmer.]

As an embedded software engineer I wouldn't want to comment on that until we know more about the architecture of the new system. Specifically where the "safety features" reside. There's some good ideas floating around about FPGA based counters for sensors such as encoders.

[Eldarion]

Originally Posted by MikeDubreuil

As an embedded software engineer I wouldn't want to comment on that until we know more about the architecture of the new system. Specifically where the "safety features" reside. There's some good ideas floating around about FPGA based counters for sensors such as encoders.

From what I understand, having attended the "training" session at Nationals and talked with the NI guys separately, the FPGA will most likely be acting like the old IFI Master processor, and therefore will not be user configurable. I cannot be absolutely sure, however, as getting detailed information out of them was like pulling teeth!

Something interesting with regards to the PowerPC processor they keep mentioning--NI appears to be using a Virtex II Pro FPGA in the CompactRIO. That FPGA actually has two hard-core 450MHz PowerPC processors connected to the FPGA fabric. I wonder if we will be allowed to use both cores, or if they are using the other core for something else (more Master functionality, perhaps).

The biggest thing that is bugging me at this point is the sheer size of the applications that are downloaded to the controller. 75Mb+ for a simple two-wheel drive control program??? That screams bloatware to me! I wonder how easy it is going to be to chew through the 128Mb of FLASH storage?

I also talked at length with the NI guys about the "Real time vision system". All of the vision algorithms actually run on the PowerPC processor, and if you do unbounded OCR or any vision processing at a higher level than basic color thresholding or simple shape detection, the system will not be real time. They were able to get the "reading" demo to work in real time because the words were surrounded by either an oval or a rectangle. I am not sure if they were using the OCR after that first processing stage or not, but they were definitely keying in on the shape. I just wanted to clear up some misunderstandings and confusing / conflicting information on that particular subsystem.

All that said, if they can work out some of the bugs, this looks like a very powerful system and it will be interesting to see what teams can do with it!

[dcbrown]

After reading a lot of the stuff available from FIRST, WPI, NI, and Wind River... and doing some integration/interpretation... and guessing, the following are some random opinions

• . VxWorks is essentially (very!) unix-like operating system.

• it uses a BSP (board specific package) as h/w abstraction layer so it can be targetted to multiple platforms. The BSP exists for the cRIO. The normal VxWorks comes with a bunch of different BSPs, we may end up with a stripped down version of the environment with only the cRIO - that would make sense.
• there is a configuration process whereby you add in or remove components that you want in the RTOS build - standard stuff. Which means you can add rom-based file system, FTP, and other capability that is already available in the VxWorks kit as needed. There will be a standard config for competition, but for prototyping this opens up lots of stuff like application data logging during testing via WiFi. There are separate Broadcom device drivers available, for example, and other 3rd party driver packages.
• The IDE (Workbench) is Eclipse-based. You have the ability to add REAL breakpoints and other stuff for debugging. You'll need to compile with debug flags, otherwise you only get assembler view. Compiling w/debug goes for any libraries you'd use which is why any FIRST provided added-value such as pre-canned drivers for gyro, et.al. would need to be in a controlled source form.
• Both the Wind River C and GNU C compilers will work.
• VxWorks is RTOS, applications are either integrated into the kernel or as application. Multitasking native with 256 priorities and round-robin scheduling within priorities (so essentially unlimited tasking until you run out of main memory).
• a ton of documentation is available (I'm looking at 100mb of stuff), everything from getting started, to writing your own BSP (as if we'd ever need or want to do that!). For software mentors, start reading!
• (ok weird factoid), interrupt latency is slightly better than RTLinux, at around ~70usec (published number was 100us but that was on a MPC8260 @200Mhz processor vs 400Mhz MCP52xx of cRIO... but should give a ball park figure).
• fun stuff like a shell window on the target (cRIO) that you connect to and use from the development host [I guess like a console].
• lots and lots of other good stuff if you're an applications programmer.

Someone (WPI?) will provide the pre-canned "driver" software for the common interface devices; gyro, camera, sonar, and the like similar to the WPILIB today. It will be provided in source form. This combined with a default VxWorks project will provide the default/base code for the robot next year. I haven't read far enough into "Wind River General Purpose Platform, VxWorks Edition - Getting Started" to see how much work it will be to change drivers, but if the pre-canned driver software is open-sourced then you could use that to slightly modify things as needed for your robot - but suspect that shouldn't be needed often.

Custom h/w and/or driver software will likely be discouraged the first year. Both would make it difficult to provide the type of deep generic support needed across all the teams. The programming of the FPGA will be canned and shouldn't be touched by individual teams again for the same reasons. Maybe in later years we'll be able to change this.

LabVIEW is built on top of what VxWorks provides, so C/C++ is actually the native method of building apps.

[SL8]

After reading the first post to the last, I went back to the first again.

Can someone help explain this stuff to me in peasants terms?

[dcbrown]

Originally Posted by SL8

After reading the first post to the last, I went back to the first again.

Can someone help explain this stuff to me in peasants terms?

Its a "PC" running a flavor of unix operating system that you'll need to write an application program for. Hardware drivers for all the common stuff will be written for you so you just have to call them to get the data you're interested in.

Take EasyC or WPILIB x 1000 in terms of the number of library calls that are available.

NAME taskInfo – task information library
ROUTINES
taskName( ) – get the name of a task residing in the current RTP
taskNameGet( ) – get the name of any task
taskInfoGet( ) – get information about a task
taskOptionsGet( ) – examine task options
taskNameToId( ) – look up the task ID associated with a task name
taskIdDefault( ) – set the default task ID
taskIsReady( ) – check if a task is ready to run
taskIsSuspended( ) – check if a task is suspended
taskIsPended( ) – check if a task is pended

and

NAME eventLib – VxWorks user events library
ROUTINES
eventClear( ) – Clear all events for calling task
eventReceive( ) – Receive event(s) for the calling task
eventSend( ) – Send event(s) to a task

and

NAME clockLib – user-side clock library (POSIX)
ROUTINES
clock_getres( ) – get the clock resolution (POSIX)
clock_setres( ) – set the clock resolution
clock_gettime( ) – get the current time of the clock (POSIX)
clock_settime( ) – set the clock to a specified time (POSIX)
clock_nanosleep( ) – high resolution sleep with specifiable clock

and

NAME timerLib – user-level timer library (POSIX)
ROUTINES
timer_cancel( ) – cancel a timer
timer_connect( ) – connect a user routine to the timer signal
timer_create( ) – allocate a timer using the specified clock for a timing base (POSIX)
timer_open( ) – open a timer
timer_close( ) – close a named timer
timer_unlink( ) – unlink a named timer
timer_delete( ) – remove a previously created timer (POSIX)
timer_gettime( ) – get the remaining time before expiration and the reload value (POSIX)
timer_getoverrun( ) – return the timer expiration overrun (POSIX)
timer_settime( ) – set the time until the next expiration and arm timer (POSIX)
nanosleep( ) – suspend the current task until the time interval elapses (POSIX)
sleep( ) – delay for a specified amount of time
alarm( ) – set an alarm clock for delivery of a signal
_timer_open( ) – open a kernel POSIX timer (system call)
timer_ctl( ) – performs a control operation on a kernel timer (system call)

and on and on and on...

[SL8]

So it's actually the same programming accomplished in a different style?

Edit: Had to fix my grammer.

[SL8]

And since its in C++, you would still be able to write in C, as long as it tagged as C, and in C++ at the same time ,right? Does this mean we will be writing classes, object, and using the C++ templates, et cetera?

[ericand]

Originally Posted by dcbrown

After reading a lot of the stuff available from FIRST, WPI, NI, and Wind River... and doing some integration/interpretation... and guessing, the following are some random opinions

• . VxWorks is essentially (very!) unix-like operating system.

• ......

you need to be careful. While VxWorks has a posix interface, but it is not Unix or Linux. You can go along way treating it as if it was a unix system and then you get bit by something that does not work as you expect.

You can do things with the vxWorks shell that are just not unix like at all. For example, you can call routines from the shell much like you can call programs from a linux command prompt.

I hope that Wind River will give us access to some of the extra tools that can come with Workbench. For example, Wind River has tools which can monitor memory use as the your program is running, so you can detect memroy leaks. There are also tools for profiling so you can know how much time is spent in various routiens and how often those routines are called.

Hopefully we can get Wind River to spring for some training assistance to allow us to make the best use of their tools.

[dcbrown]

You can do things with the vxWorks shell that are just not unix like at all. For example, you can call routines from the shell much like you can call programs from a linux command prompt.

I do this on the unix I support from a utility called crash all the time. Crash provides an interface into either a live system (/dev/kmem) or a memory dump (crash) and lets you do LOTS of stuff that ain't application programming safe! . You can call routines, change data, whatever you want.

But from an application programming standpoint, the API provided in VxWorks is very unix-like.

I guess what I'm trying to say is don't confuse utilities unique to VxWorks with the environment that the typical team will be using (if using C).

Ditto on training. It would be especially nice if the full analysis tool set was available, possibly at extra, but discounted, cost.

[dubious elise]

Wow - this looks pretty rugged. I can't help but wonder how long it would take Ricky to rip a port out of it...

[BigJ]

but we don't have any serial cables to accidentally screw in anymore!

[Boydean]

The system looks, awesome. To me(I missed all the sessions and everything gotta catch up)its a lot more down to making a WHOLE lot better auto. code than the IFI controller was. Also from the pics I saw, it looks way more cooler and professional then IFI.

Originally Posted by BigJ

but we don't have any serial cables to accidentally screw in anymore!

YES! The way our board now is, its a pain in the butt to get to the program/tether port plugged in. So when someone just touches it and it goes in, it can set us back 10 to 15min getting it back out.

[neutrino15]

Originally Posted by dcbrown

After reading a lot of the stuff available from FIRST, WPI, NI, and Wind River... and doing some integration/interpretation... and guessing, the following are some random opinions

...

• The IDE (Workbench) is Eclipse-based. You have the ability to add REAL breakpoints and other stuff for debugging. You'll need to compile with debug flags, otherwise you only get assembler view. Compiling w/debug goes for any libraries you'd use which is why any FIRST provided added-value such as pre-canned drivers for gyro, et.al. would need to be in a controlled source form.
• Both the Wind River C and GNU C compilers will work.

Does this mean I can just use my existing Eclipse install on my Mac? Maybe add some plugins? Or do I have to use Windriver? What features will Windriver give me over Eclipse?

Originally Posted by dcbrown

* a ton of documentation is available (I'm looking at 100mb of stuff), everything from getting started, to writing your own BSP (as if we'd ever need or want to do that!). For software mentors, start reading!

I can has link? All I could find was the WPI page and some stuff on NI's site.. Not 100MB, no enough to get started.. If all else fails, be cool and upload a package to FileDropper or something?

[dcbrown]

Originally Posted by neutrino15

I can has link? All I could find was the WPI page and some stuff on NI's site.. Not 100MB, no enough to get started.. If all else fails, be cool and upload a package to FileDropper or something?

I can't upload the the documentation because it is copyrighted and is not publically available - at least in any way I could find. You can download your own documentation from Wind River by agreeing to the licensing terms via the 3.6 30-Day Evaluation kit. This is the top link in the list.

The above evaulation kit has the full doc set for VxWorks. Just remember, VxWorks is multiplatform targetted so this is the generic doc set. Some components such as full MMU support may not exist in the cRIO environment. But all in all, the documentation is a place for the software mentors to start.

I'd start with the following

Wind River General Purpose Platform, VxWorks Edition - Getting Started - general overview

And then move on to:

VxWorks Kernel Programmers Guide
VxWorks Application Programmers Guide
VxWorks Device Driver Developer's Guide
VxWorks Kernel API Reference

Wind River Workbench User's Guide
VxWorks Command-Line Tool User's Guide
Wind River Workbench Host Shell User's Guide
Wind River Host Shell API Reference

Wind River Host Utilities API Reference
Wind River System Viewer User's Guide

And a whole lot more...