5

I am trying to create a hobbyist portable robotics library (Windows and Linux) that has hard real-time capabilities. It should be able to connect over standard Ethernet to a microcontroller, upload firmware to that device, connect to other devices over a fieldbus, and upload firmware to those other microcontrollers that run dedicated controllers. NICs will be those supported by RTnet if hard real-time is desired. I will want typical servo rates of at least 1 kHz but preferrably 2 kHz or higher. It will be running a completely custom protocol (not TCP or UDP over IP) so that the overhead is minimal and the high-speed fieldbus can be saturated while not receiving or transmitting frames. The payload in the Ethernet frame can then be interpreted or sent to connected devices.

1) I prefer to keep the protocol in C++ but know that using the "new" keyword won't work for real-time programming. What other limitations will I run into if I choose to use the C++ language rather than converting the project into C? Do people recommend books or websites that teach how to utilize C++ and meet hard real-time deadlines? I beleive it's possible and I hope to be able to go ahead with using C++ because the Orocos project uses real-time C++. I would prefer not to use C code.

2) In order to keep the portable protocol library general purpose how should the program handle the protocol running simultaneously on both a non-realtime Ethernet adapter and say an RTnet Ethernet adapter?

A specific question that I have would be a question about say a portable Mutex class that can use either a boost or a Xenomai mutex.

Solution 1 to problem 2 could be the following: If the application has also been compiled with the Xenomai libraries then a mutex could be constructed with a boolean flag to say which methods (either boost or Xenomai) would be wrapped at runtime for lock and unlock. It could contain the boost mutex and a Xenomai mutex if the library was compiled for Xenomai. I don't like this solution because if the project is compiled for Xenomai then it will contain private variables of a mutex for boost and Xenomai, which seems like a less elegant way then having just the mutex that one needs.

Solution 2 to problem 2 could be the following: Write 2 different derived classes from an abstract class of pure virtual interface methods to the mutex, one for boost and one for Xenomai. I like this way better but then telling which class to use at run-time is cumbersome. I'd maybe have to have pools of a boost and Xenomai mutexes. Is this how most hard real-time C++ programs address the issue?

I have this issue coming up with more than just a mutex but would like to receive feedback since I don't want to replicate bad design patterns from the start.

3) I believe TwinCAT from Beckoff runs EtherCAT in real-time under Windows 7. Is there anything that will be coming out that would not be out of reach of the hobbyist that supports at least one NIC with hard real-time under Windows 7 or later? Maybe there is an open source Hypervisor project.

4) Also, how do people load the system so that their quad-core computers are using 100 % of each of the cores so that they can tell if their system is not running in hard real-time?

Edward
  • 148
  • 1
  • 6
  • 1
    You should split this up into small, concise questions. This is too much to digest. – Jonathon Reinhart Nov 18 '12 at 02:31
  • 1
    What layer of the network stack specifies collision detection and avoidance? I'm having a hard time seeing how a system employing the usual random-wait CD/CA can make hard realtime guarantees. – dmckee --- ex-moderator kitten Nov 18 '12 at 02:36
  • 2
    To do anything "hard real time" you need "hard real-time" OS. Neither Windows or Linux is in that category. – Nikolai Fetissov Nov 18 '12 at 03:44
  • There will only be collisions if there is a new Ethernet device that comes online and makes the system non-realtime for some time. The protocol chosen avoids any other collisions. There doesn't need to be more than one Ethernet device as I don't expect most hobbyists to need more than one Ethernet microcontroller attached that gives them a high speed fieldbus. Complex robots needing more than one high speed fieldbus off of a single Ethernet port would need to accept a non-realtime glitch with my design but I don't see an easy workaround. – Edward Nov 18 '12 at 03:46
  • @dcmkee: CD/CA are pretty much defunct with the advent of switches and full-duplex links. Collisions only happen when you use non-switching hubs. Instead, you need to worry about queue depth in the switch, but that's a much more tractable problem. – Ben Voigt Nov 18 '12 at 03:47
  • @NikolaiNFetissov: Or dedicated coprocessor hardware fulfilling the hard real-time requirements. – Ben Voigt Nov 18 '12 at 03:50
  • What would be preferable for a hobbyist if not Xenomai if it does not provide hard real-time? Should I be looking into hypervisors? – Edward Nov 18 '12 at 03:59
  • @BenVoigt: Mmmm...yes. I should have thought of that, but I live on the trailing edge of the technology curve and still own a couple of plain hubs. On top of that the OP hasn't specified IP so I was wondering if he intends a token controlled protocol or something like that. In any case it was just idle curiosity. – dmckee --- ex-moderator kitten Nov 18 '12 at 04:46

1 Answers1

3

One detail : if you want a 1khz refresh cycle for servos, why are you using hard real-time ? Soft real-time (ie. run as root, but pure userspace but set scheduler policy to FIFO levels for that process, lock everything into memory, disable swapspace ...) and you'll easily get 1khz out of it without missing a single message in an entire year of running.

At this point, just use a raw socket for your ethernet protocol and call it a day.

As to the unrelated question ethernet CD/CA are implemented in hardware these days. Just ignore them.

christopher
  • 1,061
  • 2
  • 8
  • 10
  • This was helpful to get started with soft real-time. It generally works with < 100 uS latencies while running background processes. Hard real-time is working now and Xenomai with RTnet do seem to have an upper limit of about 50 uS without much tweaking of kernel settings. – Edward Dec 16 '12 at 21:49