RBOT Robotics Sensor/Acuator Board - Value Proposition

hardware / electronics / product / robotics

I’m building a board for robotics, but it’s also useful for IoT and home automation. What’s it do? What problem does it solve? It’s basically a WiFi interface to a variety of I2C-driven devices (motors or sensors). The I2C side is Engineered to be highly robust and reliable.

RBOT

The RBOT platform is aimed at folks doing robotics - but it’s also easily used for IoT and home automation. One of my core values is the strong desire for this to be a means for learning and education, so it’s an open platform and open source solution. Electronics hobbyists can extend it because it’s open. Software hobbyists can purchase kits to just use it without knowing much about the hardware. Makers can do both! More importantly it’s an easy to use, SOFTWARE FIRST robotics kit suitable for middle-school through Junior College educational use.

Disclaimer

This is a work in progress. Consider it a vision more than a real product spec. I definitely expect that as I progress it will change. Once real users start to use RBOT it will definitely morph again. I am taking a “customer development” approach to this. I am currently in the Customer Discovery phase.

A Platform for Learning

My top three problems being solved are:

  • Provide a SOFTWARE FIRST kit/platform for robotics suitable for education and learning
  • Enable robotics learning and education from ANY coding language
  • Avoid proprietary, closed solutions and embrace the revolution in maker technology

Using sensors is key to doing anything interesting in robotics, IoT and home automation. It’s easy to wire up an typical I2C/SMB two-wire sensor to a few pins on an Arduino and you have a sensor and you can write some code in the Arduino IDE to do something. There’s even a few robotics kits built around that. But try to use five or six sensors at once. Not so easy. Want to do it in python? Hmmm. Want to build your own sensor and then use it? Double hmmm. You run into problems. Using multiple I2C sensors means understanding the I2C addressing, and then even if you avoid address conflicts you can add a device in parallel - I2C is a bus, after all - and suddenly nothing works anymore. Groan. If what you really want to do is play with the software side of robotics anyway suddenly you are trapped in hardware hell and you likely don’t have the tools to solve what’s wrong. You likely need an Oscilloscope and a some electronics knowledge.

Likewise, if you want to focus on the software side and just follow the Arduino postings and cut and paste code in the Arduino IDE that’s cool, but you are then limited to the power of the Arduino controller you are using and doing any kind of concurrent programming on Arduino is essentially impossible for the non-expert (and even then, most coders I know could not pull of multi-threading in Arduino). How do you interface that to something off the Arduino? You start moving up the food chain and thinking ESP32, but now you are stuck back in low level C or very limited python.

RBOT solves these problems by providing a central device hub that you connect to over WiFi. It lets you use up to eight (8) “smart RBOT devices” and another eight (8) simple digitial inputs - all at the same time, all in real-time and in parallel. The best part is that you can access all the devices and their data over WiFi using a simple-to-use API. The RBOT board uses an inexpensive ESP32 daughterboard ($8 currently) programmed with the open source RBOT firmware that abstracts all the hardware complexity from the developer. The source code for the ESP32 is open source, so you can change it if you want to. Or you can just use it, plug and play, and concentrate on writing robotics code. Using a set of initial RBOT devices - a motor, some sensors - you can plug them in and start building code to make it go within minutes. And you can use whatever language you want, from whatever device you want. Use your phone! Use your notebook! Use a Raspberry Pi operating as an embedded controller! In any language that supports networking.

And, because the whole RBOT spec is open it allows development of new sensor and actuator applications. You can use Arduino tooling and boards and make your own new custom sensor, or dive deep into more advanced embedded system design and drive the cost out of your connected RBOT device.

in short: it’s a PLATFORM FOR LEARNING ROBOTICS.

Why am I Building RBOT?

In my career I have used a number of sensor systems as a user and developer. I was a Nuclear-trained Electronics Technician in the Navy (served in submarines), when I fell in love with instrumentation and control systems - especially for complex systems (like a submarine nuclear reactor). After the Navy I worked for an R&D lab for 5 years (at PG&E, before California stupidly de-regulated) where we built remote sensing applications for gas and power systems. I worked as the on-board Engineering support for the folks who found the Titanic: Woods Hole Oceanographic Institute (WHOI) where I was responsible for all the non-shipping sensors and systems and supported the data and video systems on the deep diving submarine Alvin. As a Software Engineer and at various levels of management I’ve worked in internet telephony, internet video, smart TV data systems, and complext network data collection systems.

I’ve also coached middle-school and high-school robotics for the last 7 years where I have seen many educational robotics systems first hand for what they can, and cannot do. Today’s FIRST and VEX systems are amazing, powerful, educational and fun. But they are primarily MECHANICAL FIRST approaches that focus on REMOTE CONTROL. The new VEX compiler suite is so much better, for sure… but it’s still limited to one fairly limited controller programmed either in their C++ or their non-technical block language. FIRST allows use of Java but again, it’s a closed ecosystem. Kids in high school should be learning python, or even golang! The AP Computer Science courses have a huge emphasis on javascript. Shouldn’t a robotics system allow a creative teacher to link those classes to sensing and moving in the real world? Of course. And that’s the drive behind RBOT.

The RBOT vision is to provide a SOFTWARE FIRST kit and platform. Connectors and the core device technology should be easily obtainable, open standard, and open source. If you want to put a sensor five feet from the micro-controller you shouldn’t have to buy some special, over-priced cable when a normal Ethernet cable will do the trick nicely.

What Will I Have to Buy?

Nothing, if you really want to make it all yourself. Some folks will want that. Most will be happy to buy an RBOT Main Board and some core sensors and actuators. If we do this right, there’s be a marketplace where creative roboticists can make and sell their own additional sensors and actuators, especially as newer chips and sensors, and smaller motors become available. If it makes it’s way into flight or undersea bots, then all the better! Yes, I’ll sell RBOT hardware and I’ll need to make a profit of some kind to recoup the investment I’ve made. But unlike some other systems, we don’t aim to lock anyone into a specific proprietary solution. I think we can do just fine with an open approach.

What’s the Connection to VEX?

None, except that I coach VEX team 8255 at Sacred Heart Cathedral Preparatory in San Francisco. As such we have thousands of dollars of VEX parts and my students are my first testers. We just upgraded to the new VEX v5 control system. One downside of this is that it cannot use the old motors and batteries. So I plan to make lemonade from that lemon and early RBOT devices will allow you to use older VEX 293 motors and motor controllers and shaft encoders. Waste not, want not.

Frequently Asked Questions

I believe in question and answers, and sometimes the best way to quickly share a lot of information is through that format.

  • Why do I need RBOT?

    • If you want to learn robotics with a SOFTWARE FIRST mentality!
    • If you want to use multiple I2C sensors and actuators and not be bound by a specific micro-controller or platform choice (e.g. Arduino) this device abstracts away all the I2C problems.

  • How do I interface to RBOT?

    • RBOT is a WiFi device that can easily be configured to join an existing WiFi network or act as an Access Point (AP). It uses standard ZeroConf to easily allow discovery. It exposes a rich API that enabled enumerating what devices are plugged in to the board and to then read and control those devices using simple APIs.

  • What network devices inter-operate with RBOT?

    • Any device that works on a WiFi network, or on an Ethernet network that can connect to a WiFi network that the RBOT is connected to.

  • What programming languages do I need to use to interoperate with RBOT?

    • Any language that supports networking, which is pretty much all of them. You pick. Examples will be available in at least a few common languages.

  • What would a common RBOT application look like?

    • You might have a simple robot that you can control with your phone or notebook directly. You might have a more complex robot that has an onboard processor like a Raspberry Pi or Beagleboard that is programmed to control RBOT using it’s API’s. The choice is yours. RBOT is a building block that abstracts device complexity away from the software developer.

  • Why would I need many sensors and actuators?

    • An example simple robot would need two motors, maybe two shaft encoders, maybe one or more ultrasonic transducers, a 9-axis IMU, and a color sensor for line following, as an example. That’s at least 6 sensors. If the robot was 2 foot square wiring those to the “brain” means a lot of individual wires and some potential problems because of that. One is from I2C/SMB address collision, and the other is from wiring capacitance.

  • What’s address collision?

    • Today an I2C bus is that - a bus. Every device on a single bus needs it’s own unique address. Some I2C devices let you change their address, but keeping track of that is confusing and limited - and you might want to use more devices than the chip allows unique addresses.

  • What’s wiring capacitance?

    • Wiring a bus of I2C devices adds significant capacitance for each device in parallel and leads to “rounding” of the data pulses and failed communication. This is very hard to troubleshoot even with an I2C sniffer. You need an oscilloscope, which is not a tool many of our target users will have available to them.

  • But can I have many of the same device?

    • Yes. Since RBOT is a switch each port is on it’s own electrically separate “bus” so no messing with I2C addresses is needed.

  • Real-world sensors need to be remote to where processing is - perhaps many tens of feet away. Does this solve that?

    • Yes, you connect your sensor to the RBOT using normal Cat5 (or better) Ethernet cable - tens of meters if need be.

  • Sensors need power. Does this solve that?

    • Yes. The RBOT takes 6-15VDC in through a standard center-pin jack. An onboard regulator provides 3.3VDC for the controller daughter board and sensor power. Each sensor port pinout supplies two voltages - board 3V3 for sensor power and board VCC for actuator power so your remote sensor or actuator is easily powered.

  • Actuators need more than 3 volts, Does this solve that?

    • Yes. The RBOT sensor port pinout supplies board VCC at up to 600mA on each port, wired on the same pins used for Power over Ethernet. Board VCC can be any voltage between 6-15VDC supplied by a standard power plug just like on an Arduino.

  • Do sensors need to use board VCC?

    • No. If a sensor does not need board VCC then those pins are not even connected.

  • What exactly is an actuator? * Actuators are usually small motors or servoes. RBOT allows a single Ethernet cable to control a “smart” motor over I2C/SMB.

  • Does RBOT know what’s plugged in? * Yes. RBOT uses a “hot plug detect” scheme to know if a device is plugged into a port, which triggers the software to probe it automatically. It then builds a “port map” of what is plugged in and exposes that information over an API.

  • What sensors and actuators can I use?

    • RBOT will support a few options at launch with more over time - but the system is open source and openly expandable with sensor code, schematics and boards published. We aim to support at least a basic smart motor, ultrasonic transducer, color sensor, and 9-DOF IMU.

  • Can I design my own sensors or actuators?

    • Yes, off course, that’s the point. You can add sensors and then plug in code to expose that sensor into the open source RBOT switch code. We will have simple breakout boards for that use case, but you can just use perf board if you want since a sensor has very few wires and components.

  • What are the Digital Input Ports for?

    • Simply reading a contact closure does not need to use an entire I2C/SMB ports. These ports use less expensive RJ-11 (phone cable) connectors and supply 3.3V and feed into the digital inputs. They also support hot plug detect so the RBOT knows which ones are plugged in.

  • Why not just use Grove Connectors?

    • Grove connectors are cool, but they are proprietary. We aimed to make everything easily available and industry standard. We think that the easy ability to make custom-length RJ-45 Ethernet cables (or RJ-11 cables for digital inputs) is an overwhelmingly better option.

  • What can I build with this?

    • RBOT was designed for robotics, but is flexible enough to support IoT, home automation, and a wide range of interesting applications.

Example Sensors and Actuators

  • Color Sensor

    • TCS34735 color sensor. Wire it up with one resistor on a small board with an Ethernet jack and put the color reading chip right where you need it. One an example line follower robot you probably need two of these positioned to read the floor, spaced about half as wide as the line you intend to follow.

  • _ 9-DOF IMU_

    • MPU-9250 is an example of this. Wire it up with one resistor on a small board with an Ethernet jack and put the sensor right where it makes sense for your robot - probably direct centerline with the x, y and z axes positioned properly.

  • _ Smart Motor_

    • Use an off-the-shelf motor and I2C/SMB driver chip on a board and power the motor right from board VCC.

  • _ VEX EDR 293 and Shaft-Encoder “Smart Motor”_

    • With the release of the VEX v5 many teams took advantage of the swap program, returning their old EDR brains. The new v5 uses it’s own smart motor. Many teams will have piles of older 293 motors and shaft encoders laying about. A simple low cost controller to interface I2C and to drive a speed controller and read two lines from the encoder and you have a “smart” interface that lets educational programs keep using their older investment.

  • Smart Ultrasonic Transducer

    • A simple low cost controller to interface I2C and to drive the transducers and you have a range sensor.

  • Use your Imagination

    • We will be providing example code and breakout boards for both digital inputs and sensor/actuator devices. We will open source all our sensor boards so makers will have plenty of examples and tools to work from.

  • Visuals!

Clicky

Clicky

 Share!