.
March 8, 2024
- It would be interesting to see how kmeans_color() perform on our blobs.
February 22, 2024
- Should read this article on grandmother cells. Grandmother cells are single neurons that only *respond* to inputs from one category. Another definition that is more plausible is single neurons that only *represent* one category. In psychology there are “localist” models that have single units that represent one category.
February 7, 2024
- The history of robots from the robotics academy (RoboCup Junior Australia) starts with Aristotle.
February 1, 2024
- Even after a night cooling down, Moos keeps on complaining. A wakeup from Choregraphe directly gives:
Feb 01 09:22:04 moos lola[4333][ALMotion.WakeUpTask]: 2267 WakeUp task killed and not finished.
- This all due to communication errors with its LeftFootBoard, which is different from yesterday.
- Tried Assignment2 code with DiagnosisEffect off, but Moos will not move:
Feb 01 09:29:19 moos lola[4333][ALMotion.ALTaskManager]: moveTo is not possible due to low level on Legs Stiffnesses.
- So, still the same error as before. Time to ask for a pickup.
January 31, 2024
- Moos doesn't want to stand up. The lola-service indicates that there is not enough stifness in the leg.
Jan 31 14:57:07 moos lola[3300][ALMotion.ALTaskManager]: setWalkTargetVelocity is not possible due to low level on Legs Stiffnesses.
- The hal-service indicates:
Stiffness set to 0 due to DCM missing -- Leg
Jan 31 14:55:20 moos hal[3289][DcmLostPlugin]: Stiffness set to 0 due to DCM missing -- Wheels
Jan 31 14:55:20 moos hal[3289][ClientSyncPlugin]: DCM lost
Jan 31 14:55:20 moos hal[3289][DcmLostPlugin]: Stiffness set to 0 due to DCM missing -- Slow
Jan 31 14:55:23 moos hal[3289][ClientSyncPlugin]: DCM detected
Jan 31 14:55:26 moos hal[3289][DcmLostPlugin]: End decrease stiffness
Jan 31 14:55:26 moos hal[3289][DcmLostPlugin]: HAL stiffness decrease ended : HAL error back to 0
- Flashing Moos. After flashing the device errors directly came back.
- So busy with its errors, I didn't see the ethernet connection going up. Reboot.
- Still no signal. Should try to connect Moos head on another robot. Could also connect my USB-adapter :-)
January 30, 2024
- Last year Feb 1 I tested switchCamera on Moos, but I couldn't find this code back.
- Also looked in the Ubuntu 18.04 and 20.04 partitions, but could find that tools version.
- Modified the record_image script to select another camera, which seems to work (bottom-left from Phineas, top-right from Ferdinand):
- I see quite a color difference. Should also record a bottom one from Ferdinand:
- Yet, this works if the camera is set before the subscription. Not clear if you could switch once connected and if two Video subscriptions are possible.
- Made a function switchCamera(), which seems to work, but actually is not:
Switching from bottom camera to top
saving image
Switching from top camera to bottom
saving image
Switching from bottom camera to top
saving image
Switching from top camera to bottom
- Version 2.8 of NaoQi has MultiStreamManagement, time to test this feature. Only C-code examples are given in documentation. An example of the python call can be found github page, which allows autocomplete of all Naoqi classes.
- Updated the script that it uses Multistream function, which actually works:
January 25, 2024
- Moos had some problems with turning around with MoveTo, which could be used by using the correct type of float.
- I checked , which shows some warnings that setWalkTargetVelocity was used (use moveToward instead). According to the NaoQi 2.8 documentation this indicates deprecated code.
- No call to setWalkTargetVelocity in motion_v6.py
-
- I could learn a lot from Iris Groen at Neuro AI summerschool from 17 - 27 June 2024.
January 23, 2024
- Found Neuroscience paper which explains the canonical grasping in the pre-cortex region F5.
-
- Made a script that sets the volume to 70%. Can be called for any robot, with argument --qi-url, like python set_volume_70perc.py --qi-url=tcp://146.50.60.??
-
- Tested Phineas with Tai-Chi, which works fine. Tested with MoveTo (1 meter), but that directly fails. The log-viewer in Choregraphe didn't gave an error, but on the robot systemctl status --user lola gave:
Jan 24 09:58:51 phineas lola[3279][LoLA.behaviors.DiagnosisLegacy]: Communication error: LeftFootBoard
Jan 24 09:58:51 phineas lola[3279][LoLA.behaviors.DiagnosisLegacy]: End of communication error: LeftFootBoard
Jan 24 09:58:51 phineas lola[3279][LoLA.behaviors.DiagnosisLegacy]: Communication error: LeftFootBoard
Jan 24 09:58:52 phineas lola[3279][ALMotion.ALMotionSupervisor]: Walk Process killed due to loss of foot contact
- More detailed systemctl status --user hal gave:
Jan 24 09:58:51 phineas hal[3268][diagnosisPlugin]: Comm lost (nacks) on LeftFootBoard -- , ack 99, nack 39727
Jan 24 09:58:51 phineas hal[3268][diagnosisPlugin]: Comm. is back on LeftFootBoard , ack 100, nack 39751
Jan 24 09:58:51 phineas hal[3268][diagnosisPlugin]: Comm lost (nacks) on LeftFootBoard -- , ack 103, nack 39778
Jan 24 10:00:21 phineas hal[3268][ClientSyncPlugin]: DCM just timed out (after communication)
- Found some example code to fix and free the legs. Code works:
Feet fixed.
Left leg fixed, right leg in a plane.
Left leg fixed, right leg free
- Also tried the GoToBalance script. The robot stands without problems on its left leg, also see no warning in lola service.
- On control-walk page I found a way to overrule the protection with proxy.setMotionConfig([["ENABLE_FOOT_CONTACT_PROTECTION", False]]). Tested it on robot with this script. Phineas was able to walk several steps.
-
- Tried to move the code to motion.init(). First didn't work, yet in the last test it worked for Phineas.
- Yet, testing the same code failed again with Ferdinand. Putting the same code inside the main (remove_notifications()) worked fine. Beats me.
- Tested code on Ferdinand. Could walk. Still, the lola-service gave errors on the higher devices:
Chain(s): "Head", "LArm", "RArm" are going to rest due to detection of SERIOUS error(s). New error(s):
PASSIVE diagnosis of HeadPitch, PASSIVE diagnosis of HeadYaw, PASSIVE diagnosis of LShoulderPitch, PASSIVE diagnosis of LShoulderRoll, PASSIVE diagnosis of RShoulderPitch, PASSIVE diagnosis of RShoulderRoll
January 22, 2024
- Should make a globals_v8 with a call to ALSonar based on the session service.
- When updating, I should also update to sonar_v4, with some corrections in the comments.
January 18, 2024
- Ferb is back. Yet, this morning it didn't respond to ip or made any sound, so did a refresh.
- With minimal aid (and a battery at 30%) Tai Chi is performed well.
- Yet, in Choregraphe no connection could be made to the camera.
- Updated the record image script to the latest NaoQi version.
- Tested the scripts, could record an image both for Ferb and Ferdinand:
- Restarted Choregraphe, I could now also connect the Video Monitor.
January 17, 2024
- Made a version of the Assignment2 code for Ferdinand. With this code the notification are surpressed and the DiagnosisEffect is False. Tested it on Ferdinand, and the robot could stand and move. The code can be downloaded here.
-
- Wrote a script to mute (and unmute) the robot.
January 16, 2024
- Saw the following bio-inspired robotics papers:
- Ferdinand is complaining on errors in several devices (error 713).
- According to February 1, 2023, I could check the diagnosis-status with self.globals.diagnosisProxy.getActiveDiagnosis() and switched off with setDiagnosisEffectEnabled, if not too severe.
- At Ferdinand several recent posture_dump+*.logs can be found.
- Started with check_version.py script, which nicely reports version 2.8.7.4
- Added a piece of code:
self.diagnosis_proxy = self.session.service("ALDiagnosis")
naoqi_diagnosis = self.diagnosis_proxy.getActiveDiagnosis()
print(naoqi_diagnosis)
- That script gave as output [2L, ['LAnklePitch', 'LAnkleRoll', 'RAnklePitch', 'RAnkleRoll']]
- Checked it on the service level with systemctl status --user lola, which gave the legacy diagnosis:
Jan 16 17:11:34 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: Communication error: LeftShinBoard
Jan 16 17:11:34 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: Communication error: LeftFootBoard
Jan 16 17:11:40 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: End of communication error: LeftHipBoard
Jan 16 17:11:40 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: End of communication error: LeftFootBoard
Jan 16 17:11:40 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: End of communication error: LeftShinBoard
Jan 16 17:11:40 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: End of communication error: LeftThighBoard
Jan 16 17:11:40 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: End of communication error: RightFootBoard
Jan 16 17:11:40 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: Communication error: RightFootBoard
Jan 16 17:13:08 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: Communication error: LeftArmBoard
Jan 16 17:13:08 ferdinand lola[3276][LoLA.behaviors.DiagnosisLegacy]: Communication error: LeftHandBoard
- Even more informative was the command systemctl status --user hal:
Jan 16 17:12:47 ferdinand hal[3265][diagnosisPlugin]: 495 nacks on LeftArmBoard since 2 min, lvl up (2), next timeOut in 5 min, ack 178041, nack 985
Jan 16 17:12:55 ferdinand hal[3265][ClientSyncPlugin]: DCM just timed out (after communication)
Jan 16 17:13:00 ferdinand hal[3265][diagnosisPlugin]: 10 errors 162 on RightShinBoard since 5 min, lvl up (3), next timeOut in 30 min
Jan 16 17:13:08 ferdinand hal[3265][diagnosisPlugin]: Comm lost (nacks) on LeftArmBoard -- , ack 179748, nack 997
Jan 16 17:13:08 ferdinand hal[3265][diagnosisPlugin]: Comm lost (nacks) on LeftHandBoard -- , ack 179746, nack 999
Jan 16 17:13:08 ferdinand hal[3265][diagnosisPlugin]: 120 errors 184 on RightThighBoard since 5000 min, No more log!
Jan 16 17:13:10 ferdinand hal[3265][diagnosisPlugin]: Comm. is back on LeftArmBoard , ack 179749, nack 1147
Jan 16 17:13:10 ferdinand hal[3265][diagnosisPlugin]: Comm. is back on LeftHandBoard , ack 179747, nack 1150
Jan 16 17:13:14 ferdinand hal[3265][diagnosisPlugin]: 91 errors 184 on RightHandBoard since 5000 min, No more log!
Jan 16 17:13:16 ferdinand hal[3265][diagnosisPlugin]: 118 errors 184 on RightShinBoard since 5000 min, No more log!
- The robot Sam seems to had the same types of error during the RoboCup Bordeaux. Reflashing helped in that case. Trying this for Ferdinand.
- Flashed, only updated the name, didn't update the Apps.
- Directly after the update, the Diagnosis warnings are back.
- Rerun the piece of code above again. Now the naoqi_diagnosis is an empty list.
- The hal-service now give other errors:
Jan 16 17:40:34 ferdinand hal[3265][diagnosisPlugin]: Comm. is back on HeadBoard , ack 40714, nack 498
Jan 16 17:40:34 ferdinand hal[3265][diagnosisPlugin]: Comm. is back on LeftShoulderBoard , ack 40708, nack 504
Jan 16 17:40:34 ferdinand hal[3265][diagnosisPlugin]: Comm. is back on RightShoulderBoard , ack 40713, nack 499
Jan 16 17:40:55 ferdinand hal[3265][diagnosisPlugin]: 1 errors 184 on RightHipBoard since 1 min, same lvl (1), next timeOut in 1 min
Jan 16 17:41:02 ferdinand hal[3265][diagnosisPlugin]: 1 errors 162 on LeftShinBoard since 1 min, same lvl (1), next timeOut in 1 min
Jan 16 17:41:25 ferdinand hal[3265][diagnosisPlugin]: 166 nacks on RightArmBoard since 2 min, lvl up (2), next timeOut in 5 min, ack 45295, nack 167
Jan 16 17:41:25 ferdinand hal[3265][diagnosisPlugin]: 168 nacks on RightHandBoard since 2 min, lvl up (2), next timeOut in 5 min, ack 45293, nack 169
Jan 16 17:41:36 ferdinand hal[3265][diagnosisPlugin]: 1 errors 162 on RightShoulderBoard since 1 min, same lvl (1), next timeOut in 1 min
Jan 16 17:41:44 ferdinand hal[3265][diagnosisPlugin]: 1 errors 184 on LeftHipBoard since 1 min, same lvl (1), next timeOut in 1 min
Jan 16 17:41:55 ferdinand hal[3265][diagnosisPlugin]: 2 errors 184 on RightHipBoard since 1 min, same lvl (1), next timeOut in 1 min
- Extended the test with the following code:
self.motion_proxy = self.session.service("ALMotion")
diagnosis_effect = self.motion_proxy.getDiagnosisEffectEnabled()
print(diagnosis_effect)
self.motion_proxy.setDiagnosisEffectEnabled(False)
diagnosis_effect = self.motion_proxy.getDiagnosisEffectEnabled()
print(diagnosis_effect)
self.posture_proxy = self.session.service("ALRobotPosture")
self.posture_proxy.goToPosture("Stand", 0.5);
self.motion_proxy.moveInit();
self.motion_proxy.rest();
- The result is that the robot stands up. Don't get any error messages for a short while, but it is back.
- The API of the ALDiagnosis can be found here.
- Also added a check to passive diagnosis, but both lists stay empty:
naoqi_passive_diagnosis = self.diagnosis_proxy.getPassiveDiagnosis()
print(naoqi_active_diagnosis)
- Because the robot moves, I could try to switch the notification off. The NotificationManager documentation can be found here
- Did a check on the notifications, but the notification list was empty. Yet, when the error message was played, I could see the notification:
Notification ID: 54
Message: Error 713: I can't move anymore. I detected an error on 6 of my vital devices: left foot bumper \pau=500\ left foot force-sensing resistor \pau=500\ left leg \pau=500\ right foot bumper \pau=500\ right foot force-sensing resistor \pau=500\ right leg. Please try to reboot me to fix the problem.
Severity: error
Remove On Read: False
- Added the code to remove the notification, which works, but only temporarly.
- At the end I even get a new warning-message added:
Notification ID: 68
Message: Warning 711: I detected an error on 1 of my devices: neck. Please try to reboot me to fix the problem.
Severity: warning
Remove On Read: False
January 15, 2024
- The students have the problem that once a picture is taken, the terminal no longer seem to listen to a CONTROL-C, which means that the terminal has to be killed.
- A bit strange, I don't see this behavior on January 16, 2023. Maybe they still use the day1-code to take an image (impossible, no vision-module in that zip). Seems to be more related with the shell. In this case the Anaconda Powershell.
January 12, 2024
- Tried to reproduce some of the problems with Anaconda Navigator. Yet, my nb-dual has actually two Anaconda2 Navigators and one Anaconda3 Navigator. The first Anaconda2 hangs at loading applications.
- Don't see the progress running in TaskController, so I cannot kill it.
- In the documentation getting-started is indicated that you can create different environments with different python versions, not clear how to get a prompt for those environments.
- The version that I use is the one in C:\Programs\Anaconda3 (64-bit)., from June 2020. That is actually a link, the runs C:\Programs\Anaconda2\pythonw.exe C:\Programs\Anaconda2\cwp.py C:\Programs\Anaconda2 C:\Programs\Anaconda2\pythonw.exe C:\Programs\Anaconda2\Scripts\anaconda-navigator-script.py
- Opened the Anaconda2 prompt, and run conda update conda. That installs a quite a number of packages, such as jupyter-core.
- Next I tried conda update anaconda-navigator. On this request, it indicates that all requested packages are already installed, but that a newer version of conda exists. That new version can be installed with conda update -n base -c defaults conda. It is quite an update, from v4.8.3 to 23.11.0.
- The navigator is still hanging on 'Loading applications'. This is actually one step further than the problems with hanging on 'Adding channels'. Clicking on the message makes it disappear. Starting Anaconda again gives 'other instance of Anaconda already running'.
- The Trick from this forum to updated the conda_api.py at line 1364 works. Anaconda Navigator now starts, and suggests to update from v1.9.7 to v1.9.12. Will try to do the suggested update. Update succeeded, but now the 'featured channels' is hanging. The conda_api.py also changed, no load anymore on line 1364. There is a function load_rc at that location, I could try to replace yaml.full_load() with yaml.safeload(f).
- Looked at how to kill the running instance. What worked for me (running Windows) is to search for a process called python. After that anaconda-navigator --reset worked, although running anaconda-navigator gave the error:
File "C:\Programs\Anaconda2\lib\site-packages\anaconda_navigator\api\anaconda_api.py", line 432, in _load_repo_data
packages, applications = output
TypeError: 'NoneType' object is not iterable
- Starting from Windows-Start was still hanging.
-
- The problem with the Mac not responding to the questions in scripts is solved by adding an extra -i to the request.
- After repairing the ~/.bash_profile file, the actual working PYTHONPATH is ~/Downloads/pynaoqi/lib/python2.7/site-packages.
- Now access is asked for all dylibs (once Open, twice Cancel, Allow in Security and Privacy window).
- Now the load fails on _locale, which we have seen before.
-
- Ferdinand is complaining on Error 713 and 714.
- Ferdinand started with TaiChi, but failed at the first leaning to the right, with error 713 again.
- The code to stop setBackgroundMovement in motion_v6.py. It is possible to add this code in for instance backToStand and bellyToStand. Another option is for each Walk.
January 10, 2024
- Kim was not impressed by the Walking Straight from Appa, but was very happy with Ferdinand.
-
- Moos wasn't named yet. Set its name in RobotSettings. It had 22 updates ready, including the German Language and AirNao app. It is clear that it came from the repair center.
January 9, 2024
- Still a lot of problems with setting the Anaconda environment in PyCharm.
- Also IPython configuration gives some problems. At least, it is no longer a default tool in the Anaconda environment.
-
- Looked at the webpage of the Leeds Leeds wormlab, with simulation and robots imitating the C. Elegans.
January 8, 2024
- Ferdinand still uses Nao as name, so updated
- Strange, couldn't find the option to set the name, not even in the advanced settings.
- Looked at the Apps. Only one was up-to-date, updating 45 applications:
- According to the NaoQi 2.8 documentation, the name is to be changed in the Settings tool:
-
- Used the Nao-shaped USB-stick with tag 'flash NaoQi 2.8.7.4' to flash Momo.
- Nicely came back to Factory settings, but the webinterface was stuck in the network wizard
- Used the RobotSettings tool to set its name and password, and restarted.
- After the reboot I could continue a bit further with timezone wizard.
- The Softbank was still assigned to Hidde. No apps where coupled to Momo on Hidde's name. Changed it to my account, still no applications coupled:
- Checked the applications in the Aldebaran cloud, but didn't see the option to add the Basic Channel:
- Found that option in Aldebaren cloud channels:
- There was also a channel which allowed to set another language, which is an option which I should check with my following robot update:
-
- Used the Nao-shaped USB-stick to flash Appa.
- Setting up the Basic Channel doesn't work directly (no internet, while the Wifi connection was set).
- The options for a 2nd language can be found under 'My Apps'. Because it cannot be uninstalled (and some Apps require France), I decided not to select install Dutch (for the moment):
- What can be said to the robot is described in the NaoQi documentation. Note that the Dutch is not part of the Dialog.
- After rebooting, and without wired connection, I could couple my Software account to Appa (ID of the head is visible in the cloud). Added the Basic Channel to Appa:
- Allowed to Permit deactivation of safety reflexes in advanced settings.
-
- Used the Nao-shaped USB-stick to flash Sam.
- Also updated the Basic Channel to Sam and changed the permission.
-
- Used the Nao-shaped USB-stick to flash Phineas.
- Also updated the Basic Channel to Phineas and changed the permission.
Six robots running NaoQi 2.8.7.4. Everything ready to go for tomorrow.
Previous Labbooks