The node accepts a ROS message as below but at this time I only do simple strings limited to one line which is I think 15 characters and we have 7 lines on this 128x64 pixel display. No graphics support in my node at this time. The node is in one of my own robots so has to be made ‘presentable’ and integrated prior to use in our Magni so that task is not immediate.
int32 actionType
int32 row
int32 column
int32 numChars
int32 attributes
string text
string comment
One thing to bear in mind is that you can cause a somewhat graceful shutdown with the button on the sonar board. Its the one that’s behind the front facing sonar. Press and hold for 3 seconds then release and the system will go in to shutdown without having to kill it.
Consider the OLED display - it will be supported on future board revs. You can access the appropriate pins from the bottom of the sonar board right now and Mark has a node functioning that publishes whatever you want to this screen. If you wind up writing code that publishes diagnostics that you particularly want consider sharing it back and we will most likely include it on a future release.
Mark, could you please indicate where this 4-pin jack is located on the motherboard, for possible connection to a display module?
And, what is the nature of these signals? Are these signaling lines being shared with any other peripherals, or, are there any possible conflicts if I chose to use these?
OK the 4 pin Jack is not on the currently released motherboard. It will be on the next iteration.
This will tie in to the I2C on the RPi along with 5V and Gnd. So you can do a similar think with your board by connecting in the display.
David
Small correction: The OLED display connector will be 3.3V.
The SCK and SDA lines for the raspberry Pi on any current board in the field (rev 4.9 and before) can only be picked off by soldering wires to the bottom of the 40 pin Raspberry Pi connector.
Be really careful because you must use your ‘3D’ side of your brain to realize where the pins on the Raspberry Pi come out on as the Pi plugs in ‘upside down’ more or less so be careful.
The raspberry Pi SDA (DATA) line is pin 3 and the SCK (CLOCK) line is pin 5. This is documented on perhaps thousands of DIY sites on raspberry Pi by the way.
A key concern that we are taking precautions with is you must try to have your cable to your display short (I’ll suggest 4" max) lenght AND you should run ground between each lead so the SCK does not couple to the SDA line. Basically KEEP THE WIRES SHORT as possible! I2C does not in general work well over long lines unless you slow down the clock speed and use electrical engineering good practice for these lines. Enough said, keep it short or you will corrupt the very key use we have for our realtime clock and all heck will happen. Did I mention ‘keep the lines short’ yet? LOL
Oh, … and keep it short. yes. … Plus, another advice to remember is that =if= numerous peripherals are sharing these lines, their combined pull-up resistors (effectively in parallel) could pull these lines High, with too much current.
To tell you the truth, we are looking at another approach to this health indicator. I would prefer some kind of simple I2C approach, like you have described above, exploiting that extremely inexpensive lcd.
However, we already have other lcd’s, and other micro-controller options to drive them. Our architecture is to drive this (first) with a simple arduino running a Ros-Serial node, to pump ros-serial data to the display. The heavy lift is an additional ros node in the Pi which monitors the system’s health and then publishes simple strings to the ros-serial node. For now, we will connect this simple arduino approach to the R-pi through one of the USB ports.
I have to admit that I feel a little dirty using the arduino. We have a lot of success with MBed-compatible boards, especially some from ST-micro, which are extremely powerful, with floating point processing on-chip. … Once this arduino architecture works, we will port it to one of our ST boards.
One more thing ~ ~ I would prefer to use the R-Pi’s I2C bus, which if believe are pin3=sda(1) / pin5=scl(1) … AND … pin27=sda(0) / pin28=scl(0) . HOWEVER I am a little scared of the methodology of programming for these pins, within your Ubiquity software architecture. I believe you use Ubiquity-flavored Kernel-level drivers and Kernel-level applications to communicate with these pins, and associated Ubiquity drivers and Ubiquity services. If true, this presents a steep learning curve.
Please feel free to re-direct my suspicions, if necessary. And, possibly direct me to any documentation to guide me: sample code, how-to’s, etc.
To address the software questions:
-
You cannot use the I2C lines on Pins 27 and 28. This is reserved by the Raspberry Pi HAT Specification.
-
The system I2C (Pins 3 and 5) is also used to communicate with the RTC chip. This happens via a kernel driver. However the kernel subsystem for I2C has well designed addressing support, so a I2C bus can be shared between userspace and kernel space as long as userspace doesn’t try to talk to an address being used by a kernel driver. This boils down to you can use i2c as long as you don’t try and talk to the RTC. You can read more here https://www.kernel.org/doc/Documentation/i2c/
I agree that the heavy lift is going to be collecting the system health data. We have been looking to supporting http://wiki.ros.org/diagnostics in all of our nodes. So far this is only implemented in the source version of the sonar_node.
Rohan
Also important to realize that the node is already there that supports the screen. All you need to do is publish to the node that is putting stuff on the screen.
You should not count on use of the I2C lines on pins 3 and 5. These ‘belong’ to the base product. Also if you want to place things on the display we are thinking about using then access through our node when available abstracts you away from our hardware. We would have some sort of mechanism to allow some sharing but full display ‘ownership’ is a tricky thing. This is far too early to lock into some promise but some schemes may be that you request ‘ownership’ of some or all of the 7 lines after we are up and running and have had time to display key debug info from self test and so on. Then it is up to you to realize you are in effect overwritting and our data no longer shows (be it good or bad). So there are tradeoffs and again this is far too soon to make solid decisions but we appreciate your thoughts just the same. ALL of this means you ONLY put data on the display through negotiations to the display node under ROS and please do not try to use I2C. On many of my bots I use a semaphore to ‘own’ I2C from root user permissions so multiple processes can access I2C. This would be one way to allow user apps to use I2C. You are additionally absolutely right that I2C pullups must be engineered properly as too many or not enough pullup are both bad. I2C is really a not very clean thing but it’s convienence if you respect it’s electrical limitations tempts us to use it. Like anything, use in excess is ‘unhealthy’. We may do some sort of semaphore thing too ‘someday’ as well but our kernel 'ownership of the RTC chip remains a hard and fast set of addresses unavailable except through kernel driver. All this is just blue sky discussion at this time.
Okay…
So, Rohan recommends avoid pin-27/28 and utilize pin-3/5 (avoiding conflict with RTC).
And, Mark recommends using pin-3/5 with a mutex / semaphore. But, wouldn’t this also require the system kernel-level RTC access module to also use the same semaphore mechanism? It seems unlikely that such an exclusive-use mechanism is already in place for this protected system software.
With these considerations, it seems impossible to use either of the two I2C ports on the RPi.
Finally, Mark, you refer to “the 7-lines” above. Can you please describe these?
This is going to be one really long post. Sorry but to explain this all it must be that way. I suggest users NOT interested in I2C usage themselves skipt this entry entirely.
As for what I meant by ‘7 lines’ I was ‘blue sky’ thinking out loud that the display we hope to put on as an option for the product has 7 lines of text with each being 15 characters. Was not discussing hardware ‘lines’. I was suggesting that I allow the ROS node to be written to by other ROS processes and the content be like I do today for specification of the 'line on the display and then the content. More complex but not too bad interface would be that a partial line such as 4 characters starting at character 7 of line 3 would get some short string. In all of that discussion I am talking about a ROS node that sits on top of the OLED display which is on the pin 3,5 I2C lines. Please keep in mind nothing is cast in stone and all of this is as much looking for user input as it is discussing some actions we are addressing right now.
As far as general I2C discussions … The only critical component on the I2C in our software at this time is the real time clock chip. As we send out rev 5.0 boards (in production now) we have another I2C device loaded that is an IO expander for reading PC board revision and a jumper block of 3 signals meant to allow. So in total we will have RTC, IO Expander and OLED display all ‘owned’ by Ubiquity Software. What I fear is that there is some risk opening this wide open to every user as if the bus gets locked up we loose key functionality and it is out of our control for the bus to be wide open.
Of course there is no way we can enforce I2C usage. Users are building bots and are basically going to ‘go for it’. We (UR dev team, most likely me) have to publish how we use I2C which includes kernel and non-kernel access as well as all I2C addresses with hardware onboard and thus not usable addresses by users. We (me) must also state guidelines because a great many users will read something somewhere and then pound the I2C to read the temperature or something with zero delay between reads. That sort of thing will kill us and is a real risk for this open platform. Don’t think they will not. There will always be 20 % or so of the users that get in too deep not realizing the system impact as they are too focused on their own needs unless it is A) Published and B) read by those users.
Advanced users who respect not loading down the I2C with far too many devices and who respect using only lets say 50% of the I2C bandwidth I think will be ok. When I mentioned the system semaphore I was assuming the mechanism to talk to I2C was not exclusive between processes. ROS only runs one thread at a time so it would be safe. Some user Python script outside of ROS may be the greater risk. I fear mostly new to I2C folks that mess up the bus or pound on it full blast then blame us for something not working like the RTC updates or some display issue. That is not an unrealistic view, a great many new coders just pound on a bus in some tight pooling loop with zero wait periods but experienced coders recognize the need to space out IOs on a shared resource.
Another thought came to me in that we have 2 Raspberry Pi GPIO lines that come out one each on a couple jacks called P704 and P705. These pins are available now although we will move the jacks to the back of the board on our current board in production in order to avoid interference with people plugging into the Pi 4 USB and Lan jacks but they will be loaded. So I have not done bit-banging I2C on the Pi yet but have done it on at least 3 other processors and so it is possible to have your very own and exclusively owned by you ‘bit banged’ I2C on those jacks. Not sure how well it would work but it is an interesting thought.
The I2C devices Ubiquity Robotics reserves:
Addresses given in 7-bit form so on the I2C bus they appear shifted up by 1 bit.
- MCP7940 RTC 0x6F Realtime clock for Linux when no NTP can be contacted
- PCF8574 IO Expander 0x20 IO Expander for Ubiquity Robotics usage on 5.x boards
- SSD1306 OLED Disp 0x3C Near future 8 line by 15 character small display on rev 5.x boards
Tips and Guidelines For any I2C usage On the Magni Platform:
The I2C is the main 3.3V Raspberry Pi I2C on pins 3 and 5 with Raspberry Pi as the master.
The Rev 5.0 board has a 4-pin jack that brings out I2C and 3.3V with a ground.
- Use the I2C ONLY from within a ROS node to avoid conflict on the I2C bus.
- Keep the I2C lines to your device under 60mm from board to your device
- Only use devices for short data accesses and space out your accesses by at least 50msec
We will be placing this I2C information in our documentation so this is a 1st cut at it for the forum
Hi Mark, is rev 5.0 out already? We are interested in buying today.
Yes, all boards in production for the units we have in stock and for the units being built at this time are either rev 5.0 or rev 5.1. We changed the connector type to be female for rev 5.1 for the 4-pin I2C jack in case you needed that from the discussions. That is because we want to have a small OLED display plug into the jack. It would be quite easy to take out either style of jack and run your own wires of course.
Please note that although we have mounting and connector worked out for a 1.3" OLED display we have not set a date for support of the display. We have only proven we can run the display. We hope to add this display but have to work out how to structure it to the product delivery options and it is a lower priority item at this time due to other development.
Finally got around to placing a simple display node I have discussed onto the Ubiquity Robotics github. We are trying to have this available but not anchored to use specifically with Magni like we have done with some other popular packages. I myself wrote this node for my own ROS based robots for example. By default it shows linux host name and IP address which are both handy in a general way.
See the readme and code at: https://github.com/UbiquityRobotics/display_node
Enjoy,
The Ubiquity Robotics Team
Getting back to this one.
We are shipping rev 5.2 boards with the OLED display on the boards starting with our next production run in progress at this time. Rev 5.1 boards had the correct socket so can be used as discussed in earlier post or on our github (link in next paragraph)
The display node had to be renamed and is not part of the image yet but we hope to do that very soon. It is on our github now located here with a readme to help use it now.
A couple months back I added the I2C info and more from prior post on this thread. It is on learn pages so that may be handy for those wishing to use I2C.
Some people on this thread also asked about GPIO. A page that tries to explain all the GPIO we use and how to use some of the lines if your application needs them now exists. That is here https://learn.ubiquityrobotics.com/doing_more/GPIO_lines.html
Ok, hope that brings this up to date. Let us know other things that you want to see in terms of the learn pages that would help so our docs can improve.
Cheers,
Mark
1 Like
Thanks I’ve got my magni and its sweet OLED display shows its current ip. Neat!
We are actively working on two OLED related things. One is we will show battery voltage on the OLED soon!
Next there seems to be an all too common issue with some displays don’t properly initialize. This one is stumping me so if anybody figures this out we would greatly love to benefit from suggested code changes. I have it a bit better but it can still fail. Devil is in the details as always in tech.
1 Like
We have pushed a more completed set of initialization parameters to the OLED display and also have a battery voltage now showing up if the ROS system has a /battery_state topic like our robot has.
While looking at this I also ran across one display that came up in an odd state even on my tried and true test rig for these displays. So I now will have to watch for quality control on these displays and get a test going in production so at least at the factory we have validated the display is good. We do not have an image that supports the display yet so we must have that then implement the production test.
1 Like