Support from Beam Robotics for this module? #1
Comments
|
You have to figure everything out yourself. We haven't tried to contact the
company. The current rosbeam package won't work with new beams. Suitable
tech has improved firewall and changed the byte sequence of driving
commands.
We and cornell university have already fixed those things and made rosbeam work with the new
software. You can get the working version from our repository or cornell university's repository. Once you have a working version you can backup beam's harddrive so if they change
something in future you can always revert back to working version.
I am using Beam with Ros navigation stack and it is working great. I don't
see any reason you shouldn't buy a new Beam. It is a very good platform for
HRI and autonomous navigation research. I would highly recommend it.
Thank You,
Utkarsh Patel
…On Apr 24, 2017 8:55 PM, "jywilson" ***@***.***> wrote:
Hello,
I was thinking of a buying a new Beam robot, and I was wondering if you
can think of any reason why "rosbeam" would not work. It looks like it has
been awhile since the repo was updated.
Did the Beam company support you in your efforts, or did you need to
figure this out on your own?
Thanks,
Jim W.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AOXlheb5q7NPcc-hMGZv_uMmrkP1BDAwks5rzUSAgaJpZM4NG4Or>
.
|
|
Good work @utkarshjp7. Well in terms of support there was no support. This was purely reverse engineered. Indeed it was not updated because I no longer had one or worked on one. But the groundwork is all laid. All you need is updating the outdated bits following the existing documentation, which amounts to some tinkering. Pro: human friendly hardware design and driving control. |
That would be most appreciated! Please send me your updated rosbeam. I am just about to click the order button and we would not be buying this robot if it wasn't for this project so the Beam folks should be more supportive. Thanks again! Jim W. |
|
Excellent! Many thanks. I am looking at it now. |
|
I checked @utkarshjp7's changes. It's minimal and quite reasonable. I think this commit people-robots@8ab0b42 did it in the right direction because onboard code should do the absolute minimum and actual computation should be moved off-board, but you would want to pack all the information into one message instead of splitting them across multiple topics with potential synchronization issues. There is also another fork by @wbthomason. If you check the diff here master...Cornell-RPAL:master, they have more detail on the protocol change, and a lot more other stuff going on. Hopefully you guys can figure out a place to centralize the new code. |
|
@utkarshjp7 Looks like we took a bit of a different approach to you, though we've also tried to keep changes fairly minimal. Our approach is working on the Beam currently as well. The most significant of our changes pertain to documenting and adapting to the new driving protocol, as well as crippling the Beam's update mechanism to prevent future software updates from breaking functionality. One of the other members of my lab has also worked on improvements to the odometry. I agree with @xlz that it would be a good idea for us to figure out a good way/place to centralize the code and merge the best of our two changesets. Any thoughts on this? Also, @jywilson, as @utkarshjp7 and @xlz said, Suitable Tech doesn't offer any support with this work. We've contacted them asking for assistance, and only been told that while they will not assist with the work, they won't actively try to stop it at this time. The Beam is still a good platform, and hasn't been too difficult to work with (largely thanks to @xlz's intial work) despite the lack of out of the box ROS support. |
|
Also, mentioning @zzv2 as he's been the primary contributor to our lab's fork for the past months. |
|
I should mention that we are working with Beam+ robot , and not the pro version. We haven't tested our modifications with Beam Pro. |
|
Ah, that is good to know. We've only worked with the Beam Pro, and haven't tested on a Beam+. |
|
This is great information. Many thanks! I just received my Beam+ and I am attempting to following the instructions in the "Deployment" section of the README.md file. It indicates that I should remove the SD card from the back of the Beam. Where exactly is the SD Card? Do I need to disassemble the screen to gain access? |
|
In answer to my own question above, the Beam+ does not have an SDCard. I should have read the documentation in README.md more closely. I built the overlay.tgz file in utkarshjp7's repo. Here's how it went... I was able to mount the partitions described in the Deployment section of README.md. I created the wifi_dev_mode file and modified the file "target" to reference the overlay.tgz layer. This did not seem to have an affect. When I rebooted to the USB flash drive, I noticed that the changes to the target file had been removed. I looked at the watchdog.log log file in the RPD-LOG partition and it indicated that grub was "running a fallback kernel" and was "ROLLING BACK SYSTEM". Is it possible that changes to the file "target" are now detected at bootup? Any suggestions for now to disable this fallback kernel? Also, I noticed that no matter what I am doing when Ubuntu is running on the flash drive, the system will reboot after a period of about 10 minutes. I wonder if the BIOS has been modified to run a watchdog timer that must be pet at some interval. I am not a Linux platform expert, so any suggestions you have to debug this issue would be greatly appreciated. Jim W. |
|
I think @utkarshjp7 may be able to provide the up to date instructions on the exact method of gaining access. Guessing from my previous experience, the system has a backup mechanism where if some boot success flag is not marked post-boot the boot system will revert to a previous known working configuration. Combined with the boot watchdog mechanism you get what you observed. It's nothing malicious. This is the standard backup procedure for embedded systems where it can fail to boot for any reason after a change to the system (upgrade or otherwise). The real problem is that the reference If I were you what I would do right now is:
And actually step 3-5 are just a way to debug step 6 so if step 6 doesn't work on the first try. |
|
@xlz Thanks again and I will keep you posted on my progress. |
|
@wbthomason, @utkarshjp7, and @xlz I would like to modify the content of one of the OS image files in RPD-STORE/images. It looks like I would need to modify the MD5 sums in the releases.yaml file, or at least create new entries for my modified image files. Is there a way that I can disable the checking of the releases.yaml file? @wbthomason Could you provide more information on the approach you took in modifying the Beam robot? Did you make your changes available on github? |
|
Hi, @jywilson. @xlz should correct me if I'm wrong, but I think it will be much easier to add a modified copy of whatever files you're trying to change to the overlay layer. This will overwrite the files in the I am not aware of a way to disable checking of Yes, all of our modifications to the original rosbeam repo are here: https://github.com/Cornell-RPAL/rosbeam, along with some extra documentation. If you have specific questions about the changes we made or the process we took, I can answer them. We also have a few other useful repos in the Cornell-RPAL org, including navigation (https://github.com/Cornell-RPAL/beam_nav) and gamepad control (https://github.com/Cornell-RPAL/beam_joy). Note that these repos may be a bit tailored to our particular setup. @zzv2 is the primary contributor to these extra repos, and knows more about them than me. Note also that we've only worked with the BeamPro, not the Beam+, so ymmv. |
Hello,
I was thinking of a buying a new Beam robot, and I was wondering if you can think of any reason why "rosbeam" would not work. It looks like it has been awhile since the repo was updated.
Did the Beam company support you in your efforts, or did you need to figure this out on your own?
Thanks,
Jim W.
The text was updated successfully, but these errors were encountered: