Anyone seen erratic behavior using the EasyGoPiGo3.steer(left_percent, right_percent) method?
I’m building an isolated test case to investigate what might be causing my bot to sometimes respond to steer() commands and sometimes seems not to be affecting the direction of motion.
I think I’ve figured out (part of) my steer() issue. “Only initialize the GoPiGo3 hardware once”
I have configured RPI-Monitor to check Carl’s battery every 10 seconds. It instantiates an EasyGoPiGo3(use_mutex=True) object, and then calls the volt() method.
The problem is that instantiating the EasyGoPiGo3 class performs two hardware affecting operations:
I don’t know if reseting the pin modes in pigpio interrupts anything, but the set_speed() surely messes up any steer(left,right) commands in other running GoPiGo3 programs.
I actually have three other processes running that instantiate EasyGoPiGo3 objects:
These three only instantiate an EasyGoPiGo3 object once each at boot time, so they should not be affecting the steer commands.
I created:
for the RPI-Monitor to use to access the battery voltage without affecting the motor speed settings.
I’m waiting for Carl to finish recharging so I can try my Braitenberg Vehicle test program again, (with the test program, and the wheel logger, IMU logger, juicer, and RPI-Monitor all talking to Carl at the same time), now that RPI-Monitor is using the “noinit” classes.
ooh, we never considered this use case! I might make the change to the library. An extra parameter to pass, if you want to avoid the initialisation.
Thanks!
I’m still investigating - don’t change anything till this is solved. I just hit the other issue I2C Errno 121 again - forgot to stop the IMU while testing. I’ve got too many variables going on in Carl at once.
Why would you assume that the programmer always wants to do a full-up hardware re-init whenever the base class is instantiated?
Full hardware resets are strong medicine and should be used sparingly.
+1 for the change, as a minimum.
Surely you jest, Jim. There is only one robot with a non-real-time OS. Who in their right mind is going to suggest having multiple independent programs, (up to seven in my case so far), running on an a general purpose processor, with no guaranteed execution time frame, and no easy shared memory, who is going to think this is needed to teach young minds about robot control?
There are so many basics to learn about in robotics before even multi-tasking is needed, let alone the infinitely more complex architecture of multi-processing, so I do not fault DI for not designing for multi-processing.
Multi-processing for a $100 robot? Really not important, but by providing the interface class and API open source, “the exercise is left for the reader” to coin the frequently used educational idiom.
Since the GoPiGo3 board does not have GET_GROVE_xxx commands, a no init feature cannot actually create a fully configured, fully usable GoPiGo3 class object that knows what type of sensors and what state those sensor/effectors are currently in.
Now when we talk about one robot as the interface to multiple asynchronous sensors over multiple channels (direct to/from GoPiGo board - Digital, Analog, and processor through GoPiGo board - pigpio, I2C) - here I don’t expect anyone to be able to understand it enough to dink with it so having the GoPiGo3’s ATMEL firmware locked up tight gives me comfort that I can treat that whole thing as a black box - as long as the company is responsive to questions about it like DI/ModRobotics has been.
The fact that I am the only person, ever, getting fatal I2 [Errno 121] is evidence they made pretty good assumptions designing this bot.
So, all in all, the answer to your question - because 99.999% of the programmers will always want to, (and need to), do a full-up hardware re-init. There was no need to “design for every possible use case”
I would be less expansive and give yourself credit for what you actually accomplished.
Only person EVER?
Maybe not.
Only person who had the chops (and patience!) to instrument the problem and accurately characterize the failure modality?
100% correct.
A phenomenal job no matter what you call it!
Hands hurt. More later.