• On board power

    Derrick Bommarito4 days ago 0 comments

    I've done some digging into DC/DC converters and have narrowed in on some TI step-down regulators that I'm going to play around with for integrating 2 regulator circuits on the board to be able to power everything from a single 11V-15V battery. Trying to cram two of these circuits onto the board while it's already full is going to be a fun puzzle! I've been trying to keep the I/O pins inside the edge of the HAT but I'll likely have to abandon that goal and I'll also be eliminating the ftdi header to create much more room; the FTDI header takes up about the same footprint as one of these circuits.

    The reason I'm trying to embed 2 circuits is to have a completely isolated supply to provide 5V for the servo header. Each circuit will be able to provide 5V at 3A.

  • Necro-project!

    Derrick Bommarito6 days ago 0 comments

    After 4 years I've finally resurrected my RoverPi project. The last project was abandoned for a couple of reasons namely that Raspberry Pi was still developing its HAT standard and I had initially tried designing a board to fit the needs of many people instead of just myself. This meant that it was hard to actually get designed with all of the features needed to make it easy to use with the Pi and that it wasn't exactly what I needed so I lost interest in it!

    This time around the HAT spec is fleshed out, though I still need to look into the tools for proper configuration and communication with the PI, and I'm limiting the board to the features I'm looking for. In fact I'm even limiting the board design a bit because Pi HATs are smaller than what I was designing last time.

    With that said the planned feature list is: (Subject to change as I add/remove features and need more space on the board)

    2x Bi-directional motor channels, 2A each

    8x Servo control, can be re-purposed as DIO.

    8x Digital I/O, header provides 5V and ground

    4X Analog Input, header provides 5V and ground

    FTDI Serial Port

    ISP SPI Port

    Once the first revision of the hardware is completed I'll be developing libraries to more easily develop firmware for the controller. All firmware libraries will be written in bare AVR C with the intent of developing for the controller outside of the Arduino IDE. Eventually the goal is to create an Arduino compatible bootloader for the microcontroller (It's a variant of the chip used on Arduino MEGA boards) and to port the libraries over to the Arduino IDE to expand the reach of the board. The controller will initially support being programmed via its ISP port (via ArduinoISP, AVR dragon, or other ISP programmers).

    After all of the stand-alone firmware libraries are working the next step will be to begin Raspberry Pi integration. A full out-of-the-box firmware stack will be developed for the RoverPi controller meant to be a one-stop shop for configuring the controller and interacting with the I/O directly from code running on the raspberry pi. The main communication bus will be I2C from the Pi to the RoverPi board. C++ libraries will be developed that mirror the RoverPi firmware libraries to expose features to applications running on the Pi. Features such as velocity based motor control, servo control, digital I/O, and analog input will all be exposed to the Pi.

    The final step will be to develop ROS nodes that expose all of the features to people looking to develop within a ROS architecture. This is my personal intended use and the ultimate goal I'll be working towards. With the release of the Pi 3 it is now possible to run less specialized distributions of ubuntu which means it's becoming easier and easier to get ROS running on a Pi.

    Additional features I'd like to work in are:

    Integrated Power supply to generate 5V directly from battery input to eliminate the need for a separate 5V supply. The goal would be to create a supply strong enough to back power the Pi as well through the expansion header, completely eliminating the need for additional batteries and external components. This will be the largest driving force in what the final I/O will be as I need to move stuff around to make room for the PS components on the board. One of the first components to axe might be the FTDI header. (And therefore stand-alone arduino support)