NEW 2009 Control System Released

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

[writchie]

Originally Posted by NCollins

OK, after numerous calculations here is the data for 802.11 channel interference. Although it is true that only 1,6,and 11 have no crosstalk AT ALL does not mean that there are only three channels with low enough interference to work.

Sorry - not OK. First, the non-overlapping channels 1, 6, 11 are not totally free from adjacent channel interference. They are called non-overlapping because you have three channels with nominal channel widths of 22mhz spaced 25 mhz apart. When transmitting on 6 for example, most of the signal energy will be in 4 - 8. But there will still be signal energy in channels 3 and 9 that can interfere with channels centered on 1 and 11. While the adjacent out of band signals are typically -20db - 35db below the peak signal, this is still sufficient to cause interference. This is because the signal in the adjacent channel, while 20 - 35 db lower than the the peak signal, can still be nearly as strong in absolute level as a signal you are trying to receive that is ten times father away. Adjacent channel interference is a particular problem when the interfering transmitter is very much closer than the transmitter you are trying to listen to. This is exactly the case if you try to operate several robots in close proximity with the robots relatively far from the stations they are talking to.

Originally Posted by NCollins

Cisco tested a 4 channel system using 1,4,8, and 11. In their test they found an only 1% interference overlap. With such little crossover they only found problems when using a large amount of the bandwidth at one time.

Even when operating on the exact same channel, two networks interfere only when they occupy the channel at the same time. Very lightly loaded networks, even on the same channel, have little noticeable interference consequences due to link layer retransmission. You won't see the effects until you have larger amounts of data on one or the other network or you are running an application that is sensitive to packet delay. Teleop control is such an application where you do not want such delays. You won' care about a 400ms delay surfing the web. You will when controlling your robot.

I suspect the Cisco example showed access points spread apart by some tens of meters. This is enough to reduce the interference seen at the access points. However, two laptops close together operating on different networks will experience lots of mutual interference. In the normal office operating environment wireless nodes are normally several meters apart or operating on the same network.

Originally Posted by NCollins

Using similar calculation I extrapolated the crosstalk with the system I described above (1,3,5,7,9,11). I found a crosstalk interference of only 5.47% outside 802.11 guidelines. Also at a distance of only 12.45 inches there is a drop in power enough to lessen the crosstalk below guidelines as well.

We also need to remember that the robots this year are only running at 19.2 Kbps. 802.11 provides up to 11000Kbps.

The guidelines for 802.11 require a 30dB drop for no interference.

I have no idea what 5.47% crosstalk interference means. I would expect that the total combined throughput of the 6 networks you suggest would be well below that of a single network. Operating 6 robots on 1, 3, 5, 7, 9, 11 would probably not be too pretty, especially with synchronous traffic. When the robots are in close proximity, they will overwhelm the signals from the much more distant stations they are communicating with. The traffic would have to be extremely low for this to be workable. Bluetooth would probably a much better solution for multiple independent networks in close proximity. Or 802.11a where there are many more channels. Or a channelized system like we have now (operating on other than 2.4 GHZ).

Operating a single access point per field with 6 robot stations and using wired LAN from the Operator Stations to the field controller is IMHO the way to achieve the best performance. The single access point can employ 802.11e to provide QoS for teleop control packets (and possibly telemetry) and the beacon rate and other network parameters can be tuned for optimum system performance. The Field controller can also shape the traffic to equalize the access for the six teams or even for the two alliances. Adjacent field would operator on non-overlapping channels. All of this off-the-shelf stuff. There would be very few re-transmissions or holdoffs in such a scenario - mostly from outside interferences. If FIRST is planning on 802.11b/g, I do hope this is what they are planning. Personally, I'd like to see 802.11 a/b/g radios in Linux capable boxes all around for maximum flexibility.

[Nikhil Bajaj]

You know, I was just thinking that it would've been fun and rewarding if FIRST had challenged the community to come up with a control system--we're a big huge bunch of engineers and the like with tons of experience between ourselves with embedded programming, board design, experience hardening electronics to survive harsh environments, etc. I think that given the opportunity we could've come up with something absolutely wicked and cheap, too. While NI is an AMAZING company, and they make absolutely sweet products, part of the charm of the IFI system is that it was designed for FIRST. I feel like the community could have done an amazing job of that--then they could be manufactured and sold to teams at cost. Oh well--just...everybody remember this idea for 10 years down the road when we change systems again!

[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?

[MikeDubreuil]

Originally Posted by Gdeaver

It looks like the power distribution pannel produces 24 volts for the compact rio. So what happens under heavy load and the 12 volt battery is pulled very low?

I agree, the power distribution board provides the power regulation for the RIO and the Wireless Access Point as seen in these two photos. It would be nice to see a big capacitor there designed to survive brown outs.

[writchie]

Originally Posted by MikeDubreuil

I agree, the power distribution board provides the power regulation for the RIO and the Wireless Access Point as seen in these two photos. It would be nice to see a big capacitor there designed to survive brown outs.

These look like high-speed switch mode regulators. Large capacitors are not required, and can even be detrimental. Since the 24V supply is an up-converter, it can probably maintain regulation down to 7V on the main battery, maybe even less.

[FRC4ME]

Does everyone think we can count on Kevin-style ADC processing built-in next year?