BUT One oh- : ROS2 deprecated the blinkin’ message
ros2 interface show ros2_gopigo3_node/msg/led/blinker/left
# This was originally provided as an example message.
# It is deprecated as of Foxy
# It is recommended to create your own semantically meaningful message.
# However if you would like to continue using this please use the equivalent in example_msgs.
uint8 data
Yeah - semantically meaningful messages … this is ROS we’re talking about.
I can’t even imagine that level of stupidity, except at the governmental level. (The lack of oxygen at the altitude most congresses imagine themselves at, likely affects their judgement.)
At this stage of the game, were I to start messing with AI in a serious way like you two are, I’d look for a more stable platform, even if it doesn’t have native support for genomic research, isn’t hardened for outer-space, or speak a dozen different (human) languages.
This bull- with things changing and being depreciated every second update is not something I would tolerate well and I have enough stressors in my life as it is.
How the two of you tolerate this horse-hooey without going nuclear is a mystery to me.
I’ve decided.
I’m going back to “old-school” C, or maybe WATFIV FORTRAN. Dang these new-fangled, modern languages! What was good enough for my great-great-great grandpappy is good enough for me!
P.S.
I wonder if I could fit an IBM-370 mainframe on Charlie. You think it would affect his center-of-gravity too much? The card reader interface is another problem and I might need a bigger battery too.
Actually you already have the equivalent of 6500 complete computer centers filled with IBM-370 Model 158 (1972), and you are in luck - there is an IBM-370/VM emulator that will spin Charlie’s wheels faster than a room full of mag-tape readers.
as the kids say “TIL” about the rosnode info <node> command
I’ve used rostopic list a lot. And I’ve used rostopic info <topic> a fair bit. I’ve used rosnode list to see what nodes are running, and rosservice list for services, but never connected the dots to think of using ‘info’ for a specific node (not surprisingly, rosservice info also works I just found out). Great to know there are different ways to have the info organized.
rostopic list does show the different LED topics - I just hadn’t paid attention since I hadn’t needed them for anything. But definitely good to know if I want to implement color signaling as you had done.
Ok , agree that uint8 data isn’t the most semantically transparent. But once you get used to the different messages, there is a certain consistency that is helpful. Maybe??
Their custom msgs tutorial showed how to define the msg data elements, but nowhere did they show how to make comments show up in the info response. It would be cool to explain the legal values and usage for each. When I should have known the blinkers would take a data r(ed): 255 or 0, but I was thinking “why would they not use 0 or 1 for a LED that cannot be anything but red, and as far as I knew could only be on or off. DI never demonstrated that the blinkers can fade, so I still don’t know if I trust I know what the legal values for the blinker msgs and their exact function. Hopefully I can figure some of these ROS “features” out so my ros2_gopigo3_node can be more self documenting and more configurable. The ROS1 node doesn’t’ allow for setting the servo center, only the lower and upper limits. It just seems so rushed to publish without use cases and example code for each feature.
As you can see, the blinker LEDs are connected to PWM outputs so, theoretically, they should be able to fade.
However, the easygopigo (et al) libraries may not implement fading so, (from within the Dexter/MR operating systems), you might have to address them natively.
(I’m not near my 'bot, so I can’t look at the libraries.)
Also, since it’s a single pin PWM output, it seems to me that the “color” shouldn’t matter and/or it would take a single luminance value.
However, since I can’t see the actual code, you will know better than me.
Silly me, only looking at the easy_blinkers.py and easygopigo.py files. The LED.py example uses the gopigo.py and clearly shows fading “blinkers”. But, the method has blue and green defaulted to 0, so the example hides the fact that the brightness is being passed as the r(ed) level. Again, my brain is learning from the examples, instead of reading the API and imagining the diverse possibilities by generalization and reduction. (The reason I never understand philosophers, and the reason I get bored in courses - I only learn from (pay attention to) the examples. This really has held me back all my life. I have known it, but am ineffective at beating it.)
Since the gopigo methods are not mutex protected, I have rarely looked to see what magic I am missing.
And even less time looking at the schematic, Thank you @jimrh for reminding me to spend more time at that level as well.
I haven’t explored this yet, but I think it must. The “Data” value of the message is only a uint8, so it will have a range of 0-255. Enough to control the fade on a single LED only. No color data.
At least in ROS1 the message type for the /led/wifi is ‘ColorRGBA’. I’ve never played with an alpha channel in the context of an LED, but as I think about it could be interesting. It could be an easier way to fade a complex color w/o having to recalculate each RGB value. I’ll have to see if that works in practice.
I saw that the message was r,g,b,a but the message doesn’t tell you what values. When I tried publishing with an “a” value ‘{ r: 255, g: 0, b:0, a:1.0 }’ ROS2 barf’d on it. Only when I left the “a” value off completely was I successful at blinking the misnamed “blinker”.
To make it blink, you would actually have to create a sub-process with a timer to turn the “blinker” on and off, and what if more than one process want to talk to the “blinker”. I wonder how many GoPiGo3 robots actually found use for the “blinker that doesn’t blink”.
Probably more than three as one of the standard bloxter lessons is blinking a blinker with an add-on, (extra credit!), of making both blinkers blink alternating like a rail-road crossing.
I can totally talk to that. I LOVE examples because they help take the abstract classroom lessons and turn it into something you can see and touch.
In high school, I was invited to teach a two-week section on “electricity” to some 7th graders. (Apparently I was the only person in the school who understood the topic to any reasonable extent.)
One lesson was the “electricity doesn’t grow on trees” lesson. (My name for the session - the official names were about as interesting as watching ice melt.)
The high point of the lesson was when I invited the class “gorilla” to come up and crank a hand generator connected to a 25 watt light bulb.
He spun it like a top - until I screwed the lamp down and it made contact! The sudden resistance to motion caused by the load almost lifted him off the floor
Lesson: It takes power, a LOT of power, to generate even a relatively small amount of electrical energy. It “doesn’t grow on trees”.
I thought the “blinker” name was just to distinguish which LED it was (just like “eye”). I’m surprised that it worked with even an RGB message, since I thought the /led/blinker/left and …/right used Uint8.
And you could always write a blinker service or action : -)
/K
You are correct. I’m so sleep deprived when software isn’t working. My brain was convinced it was an on/off device, that I couldn’t imagine why it was a Uint8.
: ROS2 deprecated the blinkin’ message
