d's profile - activity

we really like the kobuki base, not only because it's a great mobile base but it also supports ROS.

unfortunately the spec on kobuki base states that the maximum payload it can handles is only 4kg (8.8lbs).

our robot weights around 15kg (33 lbs).

does anyone know a similar base that can handle a bigger payload?

what is an affordable (good enough quality) laser scanner or depth camera (to support navigation, path planning, and obstacle avoidance)? we plan to buy a few hundred units.

currently, we're using kinect for our prototype. did anyone use kinect for final product? would microsoft sell a few hundred kinects at a time at bulk pricing?

or is there an alternative product ou there that is more suitable for mass production vs prototyping?

any recommendation is much appreciated

great to know that! just out of curiosity, since both the tablet touch screen and the robot are on the same unit, why don't you use bluetooth for local communication rather than remote web calls?

great, thanks morgan! much appreciated your input!

thanks morgan. web ui normally doesn't give a good user experience. we probably need to go with android native ui. how reliable is rosjava and ros android? maybe we have to go with android for touch ui and figure out a way to connect it to the robot.

i understand that it may be under NDA. i was just wondering what everyone thinks about a possible good solution for doing a touch screen interface with ROS. savioke seems to do a great job at that.

i just read an article about savioke ( http://www.savioke.com/ ). it looks like one great robot built on ros!

does anyone know how savioke touch screen is implemented?

i asked a similar question yesterday on this forum about how to build a touch interface for the robot (on the robot like savioke), and the only answer so far was to use a tablet (thanks!).

i can see that it could work, but the tablet solution seems to have 2 issues.

1. you have to build the touch interface in a different language / framework (i.e. android sdk or ios sdk), and then build the actual logic for the robot in ros. it's possible but it doesn't seem like an optimal solution to spread development efforts in two different places.

2. the tablet likely has its own hardware (i.e. its own board, ram, etc), while the robot also has its own hardware (i.e. board, ram, etc). it doesn't seem like an optimal way to build out the robot this way, as we'll waste the hardware parts on the tablet, in which we only need the touch screen. in other words, we'll pay for the hardware of the tablet but we don't really use them except for the screen.

what would be the best way to build a touch screen robot?

any feedback, comment, advice is much appreciated.

thanks!

hi there. i'm working on a robot prototype that has a touch screen as a user interface. i have a few questions. i've done some research in the last few days but i couldn't find any reliable source of information. i would love to get feedback from everyone who's done this before.

1. hardware: what type of touch screen manufacturer & product would you recommend that works well with ros & ubuntu? we're using an intel nuc i5 for our robot.

2. software: how do you go about building beautiful touch UI with ros & ubuntu? different from tablets (which already have well defined sdk and api like in android and ios), i'm not sure what are the equivelance in ros & ubuntu.

3. ros support: are there any ros packages that support touch UI yet?

any feedback, comment, advice is much appreciated.

thanks christian again. i understood much better these concepts from the design doc you mentioned earlier. much appreciated for all your help!

hey @jorge, actually i have another question for you :) what is the "controllers:{ }" above in your answer for? how does it work? i got the "joins: { }" working individually now, and hope to understand more about the controllers part. thanks!

thanks. that design pattern doc is really helpful!

that makes sense. thanks paul.

thanks paul. really appreciated it. following your explaination, it seems like actionlib and topics can handle pretty much everything. why do we even need to use services? can you give me a couple of real-world use cases that we must use services vs. topics / actionlib?

topics seem like the best way for storing "states" of the robot (stateful). so that we can monitor all states/components of the robots like position, temperature, voltage, etc. that makes sense to me.

however, i also see a lot of people using topics as a way to send instructions/commands to the robots (like the topic /head_pan_joint/command for sending commands to servos, like /cmd_vel for sending movement instructions to mobile base, etc). in this case, it doesn't make sense to me.

it seems to me that this should be designed as a service (stateless). if you want to send a command to servo, create a service at the servo level that can be called upon. if you want to send a command to mobile base, create a service at the mobile base that can be called upon.

what are the advantages of designing things like /cmd_vel and /head_pan_joint/command as topics? what are the disadvantages of desigining them as services?

thanks.

and, i guess actionlib was created as something in between to feed "states" on "service" calls? i'm new to ros... so i would love to understand how/why these fundametal ros concepts were designed and intended to be used. would love to hear your thoughts.

ps: i don't see a strong reason to use services just because of an explicit response. we can easily create an additional topic to do just that. for example, publish to request_topic and subscribe to response_topic. there must be a stronger reason why ros is designed with both topics and services.