Will Ubiquity Robotics consider making a system health status indicator?
I am proposing a small LCD display option for sale, which tells system health status. This module could show items such as:
Our rev 5.0 board adds the hardware support for small OLED display readable from the front of the Magni BUT it is not considered ready for release just yet so the display itself will not ship (yet). Most of what you have discussed is in our plan for what we would show. More on this later but letting you know we are working to this goal actively. The plan is the display is ‘owned’ by a ROS node and we have a flexible way to allow other nodes to write to the display using ROS messages so we are doing it in a way that if users want to display OTHER things they will have that freedom once we have booted up and shown initial status type messages, including the IP in use.
Sounds great, Mark.
Until this is available I am hacking together one of these, right now!
It would have been particularly useful yesterday. We strayed far out of range of our Wifi-bubble, but the Magni remained in disconnected-mode, and never started PiFi-Access-Point mode.
We had to reboot it (un-gracefully) and connect with our laptop’s local A.P.
Also, as our payload was executing, it would have been nice to not have to fumble with the laptop (outside, away from the comfort of our lab), just to ascertain that one of our processes had failed, and needing to be restarted.
There is not much space on the board but we have squeezed in a 4-pin jack and some mounting ability to hold the OLED display. If you wish to work on this then form a ROS node that can be told what line and column to display a text segment. If you do it this way then you are likely to be compatible with what I am doing. To do work that would directly run given our current thoughts you should be compatible with is a very very common OLED display all over the place but if you want one fast that is compatible then check this out: https://www.amazon.com/dp/B01MRR4LVE/ref=sspa_dk_detail_2?psc=1
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.
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.
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