Where is the documentation on low-level C++ routines?

[DAQjr]

dangyogi wrote:

A couple more suggestions...

If you feel that you must use vxworks, could you provide an option to use linux?  In other words, in addition to supporting multiple programming languages also support multiple operating systems?  Not all languages would have to run on all operating systems.

Getting the network set up is also a trouble spot.  Is it really required that the robot be on a separate network, rather than connecting to the local wifi?  Maybe the robot could run a simple server that responds to UDP broadcasts with its DHCP assigned IP address?  The UDP broadcast could include the team number to support multiple robots on the same network.  Then the Driver Station issues this UDP broadcast to get the IP address of the robot, rather than using static IP addresses.

It is not feasible to implement completely new OS support for the existing targets.  That is far beyond the scope of the FRC control system team.  The OS was not chosen by the team, it is simply the only OS supported on the selected controller.

The new controller is Linux-based.  Perhaps you will be happier with that.

We are also looking into redesigning how the robot and driver station find each other on the new controller.  We recognize the pain there but have to balance improvements with added risk, complication, and incompatibility with existing team systems.

[dangyogi]

sciencewhiz wrote:

The 2015 controller, as announced today, runs linux rather then vxworks.

Yes, I saw that!  Excellent!  I'm very excited about that!!! 

sciencewhiz wrote:

It was stated today that they were trying to make the new WPILib library compatible with the old one. However, I suspect that is only at the highest levels, as given its a different OS, processor architecture, and FPGA, the lower level interfaces will change.

Understood.  This is what I expected.  That's why I'm keeping my investment in the current RobotLib to a minimum for now.

DAQjr wrote:

I'm not aware of any plans to document the low-level interfaces.  They are low-level and insulated from the user by WPILib.  They are not guarenteed not to change.  The FPGA documentation that is available is meant to provide information about the specs and behaviors of the FPGA that leak though the WPILib abstraction.  They are not meant to be a roadmap for implementing WPILib.

This seems strange to me.  We are invited to make changes to the WPILib, but then denied the information needed to do so (at least at the low levels)?  What's the logic in that?

On a related note, in grepping the copyright notices in the WPILib (the C++ version), most are copyrighted by FIRST stating that he code is open source and covered by the BSD license.  For example:

/*----------------------------------------------------------------------------*/

/* Copyright (c) FIRST 2008. All Rights Reserved.                                                         */

/* Open Source Software - may be modified and shared by FRC teams. The code   */

/* must be accompanied by the FIRST BSD license file in $(WIND_BASE)/WPILib.  */

/*----------------------------------------------------------------------------*/

One of the files, LiveWindow/LiveWindowSendable.h, is copyright by Patrick Plenefisch, but still stated to open source subject to the same license:

/*----------------------------------------------------------------------------*/

/* Copyright (c) Patrick Plenefisch 2012. All Rights Reserved.                        */

/* Open Source Software - may be modified and shared by FRC teams. The code   */

/* must be accompanied by the FIRST BSD license file in $(WIND_BASE)/WPILib.  */

/*----------------------------------------------------------------------------*/

One, pcre.h, is copyright by the University of Cambridge, giving permission to use it and redistribute it.

One, CAN/can_proto.h, is copyright by Texas Instruments, not giving permission to use or redistribute:

//*****************************************************************************

//     

// can_proto.h - Definitions for the CAN protocol used to communicate with the

//               BDC motor controller.

//

// Copyright (c) 2008 Texas Instruments Incorporated.  All rights reserved.

// TI Information - Selective Disclosure

//        

//*****************************************************************************

And 21 files, 19 header files in ChipObject, but also including NetworkCommunication/FRCComm.h and nivision.h are copyright by National Instruments, again not giving permission to use or redistribute:

// Copyright (c) National Instruments 2008.  All Rights Reserved.

Do you think that it would possible to place these under the FIRST BSD license as well?  And perhaps ask Texas Instruments if it would be willing to do the same with the CAN/can_proto.h header?

This would allow one of the teams to set up a public open source code repository for all to benefit from.  Otherwise, I believe they would have to exclude these header files.