Error Message when trying to run AlexRobot code

pi-top [4] Robotics Kit
,
#1

Hi,

I just received my Robotics Kit and started to play with it.
Unfortunately I’m struggling already with the first steps of the “Alex Robot - Line Follower - Part 1” challenge when trying to do the servo calibration with the following error message (no matter whether I use CodeRunner in Further or Mu):

Traceback (most recent call last):
File “/home/pi/pitop/src/tmp.py”, line 5, in
alex.calibrate()
File “/usr/lib/python3/dist-packages/pitop/robotics/alex_robot.py”, line 169, in calibrate
self.pan_servo.zero_point = 0
AttributeError: ‘NoneType’ object has no attribute ‘zero_point’

I already went through the following steps:

  • updated everything with Sysem -> Check for updates
  • tried these commands: “sudo apt install -y python3-pitop” and “pip3 install pitop”
  • flashed all latest firmwares
  • reflashed Sirius (with pi-topOS-sirius_C781_2020-12-22_04-11-42) and repeated the steps above
  • searched for any help in the forum and the knowledge base

Some more version details:
python3-pitop version (0.16.0)
pi-top devices -> pi-top [4] Expansion Plate (v21.10)
pi-top devices hub -> pi-top [4] (v5.4)

Nothing helped so far - so I would really appreciate any help!

Regards,
Michael

1 Like
#2

Same here and I also went through exactly the same steps. A firmware update was recommended but is not available. Regards, Andreas

#3

Hi @mk578 and @QuietProphet, I’m also seeing this behaviour after running one of the latest updates - I’m running some tests now to try and confirm where the problem is. I’ll get back to you ASAP

#4

@mk578, @QuietProphet I’ve found the bug, someone was doing doc edits recently and must have broken this - since this is a brand new part of the SDK we don’t have automated tests running on it yet and other robot functionality was working so we must have missed it (anything that doesn’t access a PMA component directly works fine).

If you want to fix this right now it’s really simple, run:

sudo nano /usr/lib/python3/dist-packages/pitop/system/pitop.py

Go all the way to the bottom of the file and change this line:

self._port_manager.get_component_on_pma_port(port)

to this:

return self._port_manager.get_component_on_pma_port(port)

i.e. add “return” at the start. This is why you got a NoneType error as it wasn’t returning anything under the hood. We’ll roll out this patch very soon anyway but I thought you’d appreciate a quick fix if you wanted to continue the Further challenges :+1:

#5

@duwudi Thanks a lot for the quick reply - keeping in mind that it is sunday that is really awesome!

I fixed it as described, and realized that I was probably like only one small step away from finding the problem myself. Actually I was somehow expecting it would implicitly return the last line’s value …

The error message is gone now, what is great, however I’m now struggling with the following observations:

  1. Yesterday I was already wondering about how slow everyting gets when I execute that python code, but now it takes extremly long until I get e. g. to the dialog to enter a calibration value. In general the overall look and feel gets extremely laggy, like mouse movements take about 3s to be displayed(!). Surprisingly an htop running in parallel is not showing high cpu or memory utilization at that time - don’t know what is slowing down the pi-top that much …

  2. This may be related to the first one, but when patiently trying to enter a calibration value like -5 (with about 1 character per 3-5s) it quite often happens that pressing a key once ends in lots of repeated characters at once (-> -555555555555555555 … - like key bouncing). For a while I tried to debug it with Mu, but finally I gave up since it is almost implossible with the extremly laggy responce time to every tiny interaction.

  3. When trying to connect that Code Runner within Further it always tells my that I should update my pi-top, allthough I already spent quite some effort to update everything I could find in the docs/knowledge base. Is that Dialog something based on failing code version checking or just meant informational to remind the user to update frequently? Maybe some more information about what exactly is outdated would help me with finding my problem, or at least avoid beeing confused or worried - especially if something does not work as expected afterwards.

Setup and test conditions:

  • pi-top connected with the full AlexRobot Hardware (like motors/servos, camera, etc)
  • using the pi-top FHD display & keyboard connected with the special green USB cable (alternatively tried VNC with a notebook)
  • pi-top is powered by the original USB power source.

I hope that is not the expected behavior - so is there anything I can do to improve my user experience?

Regards,
Michael

#6

Just realized, that when I remove the green USB cable to the FHD display & keyboard and use VNC over WiFi only it works much more fluently.
Seems to be some problem with the direct display/keyboard connection.

Also just got another automatic update after restarting the pi-top, but Further still tells me “Please update first”

Regards,
Michael

#7

@mk578 Thanks for the detailed information

I had a similar issue recently when using the FHD display and keyboard attached, I was using ROS at the time and thought it was a problem there - we need some time to look into this behaviour, we’ll get back to you soon :+1:

For point 3 regarding Further, it will ask you to update if you don’t have the pitop SDK installed with apt - did you install it manually or just using standard pi-topOS with regular updates? I’ll forward this onto the web team to look into, would be good if you could try reflashing a fresh OS and see if you still get the issue.

#8

@duwudi
I tried both again yesterday and fortunately the Further update messages disappeared with another SD Card with a completely fresh OS on it. That is the third fresh installation now, where I saw these massages with the two first of them (before(!) and after checking/updating the pitop SDK manually). I was suspecting you fixed something under the cover, but reading that now it might also just be due to the fresh installation.
However, I don’t know what went wrong before - but I’m happy it is gone now!

The extremly slow responce time when using FHD & keyboard by green cable is most likely somehow related to the AlexRobot python code from my perspective. Trying different Further challenges - like the camera face recognition or the ServoMotor receipes form your SDK docs - everything works fine, only when importing the AlexRobot code it starts to bahave like described. Maybe some intereference with any of the additional parts the AlexRobot code activates?

Regards,
Michael

#9

@mk578 good to know it’s resolved - we have also started a discussion internally on how this check is made so we can improve it. Also, we’re going to add a “Don’t show me this message again” checkbox that is retained for your entire login session just in case it happens again - so thanks for reporting the issue, we can now have a plan to improve it on multiple levels for future users :+1:

I think you’re right regarding the AlexRobot class, we’ve also discussed internally and we’re probably going to be changing the structure of that anyway so the user has to build it up themselves instead of us spinning everything up under the hood with one command - should be easier to find and fix problems that way. We’re still looking into the root cause of the USB device lag, we’ll let you know what we find!