Related
BACKSTORY
The other day I found a motorized wheel chair that someone was throwing away. Being a maker who spends a lot of time looking at what other people have made online I decided to snatch it and try to make a robot out of it. I also bought an Arduino mega, a Kinect sensor, and a motor controller to try to control the motors and give it some form of vision.
MY VISION
Honestly I don’t intend for this robot to be much more than a fun, and challenging, project. My current goals are to have it run SLAM algorithms to figure out where it is on a map and for it to navigate to predetermined points on the map. However at this point I would be happy with just being able to do a simple teleop control with the keyboard.
MY PROBLEM
I have spent the past week researching ros and how to get it talking to my Arduino. I have installed diff_drive_controller, Turtlebot, ros_control, ros_serial, ros_arduino_bridge, and several others trying to find something that will tell the motors what to do. By now I feel like I have a good barely below the surface understanding about how ros works. Basically there are a series of nodes each publishing info for the other nodes to see and subscribing to info that they want to read. All I want right now is a node that publishes data about the velocity of the motors based on it trying to navigate or teleop or something like that. I think turtlebot is my best bet considering it is an all in one stack that does everything I want it to do. The only problem is I don’t have an iRobot create. But it seems like it should be simple enough to intercept those commands and have them drive my own robot base. However I’m not sure which topic to listen on and how to run turtle bot in a way that doesn’t try to connect to an iRobot create. I could just listen to the /cmd_vel_mux/input/teleop topic but I think that would limit me to just teleop and it might make it hard to move on to autonomy in the future.
What topic should I listen on? Am I going about this the right way? Are there any packages that would be better suited for my needs? Keep in mind that I am new to ros so tutorials would be appreciated.
I look forward to your responses
Thanks, Logan
Nice sounding project! I second the recommendation to take a look at the tutorials, but I think you spend some more time with the basic ROS tutorials before diving into the world of Arduino + ROS.
For instance, I noticed one misconception I believe you may have. It doesn't really matter which topic your nodes listens to, as its just a name that can be easily remapped through a parameter given when launching the node. The important thing is to ensure you are listening to the right type of messages - they specify the interface by which all the different nodes communicate. There's a bunch of options, and if none of them fit your use case, you can define your own.
I suspect that for low-level things, such as drivers for your motors, you will need to write your own ROS nodes. For advanced functionality, such as SLAM; there's a variety of options. You can find one that's suited to the input data you have available from your sensors.
One last recommendation is to take advantage of the features of ROS that allow you to break a big problem into manageable subtasks. Do one thing at a time - implement a motor contoroller, write a teleoperation method; taking care to specify suitable interfaces at each point. The advantage of this approach is that if you made smart choices in defining individual components with good interfaces, it is very easy to replace them with another one should you so wish.
You can find a list of tutorials how to interface Arduino and ROS here.
Are there any tips for reading source code samples from manufacturer of MCUs'.
I am a newbie for mcu programming, currently I have a MCU, datasheet and sample codes for them. But problem is sample codes are seems written for experienced users. Too many questions about why they initialized RS232, why they set 4th bit of port 1 and etc.,
Do you have a tips for reading or links where can I get info about how to read datasheets and sample codes of MCU?
I guess experience is the only answer I can give. Just like with programming in general, with time you acquire experience as well as learn buzz words and concepts. With microcontrollers you learn to read datasheets, schematics, etc. Learn about open drain, open collector, weak pull ups, etc. And for serial ports for some reason they are always overcomplicated. The hardest part with microcontrollers and the serial port is usually figuring out what to program to get the right clock divisors, some microcontroller serial ports are straight forward, others are overly complicated, some docs are good some docs are bad, etc.
Another answer is datasheets are always wrong. There are always gaps in the information that you have to hack to figure out. Do not write thousands of lines of code in a vaccuum using only a datasheet, write a small amount of code a few lines to a few dozen, test, and move on, you can get more lines written and debugged in a day when programming from a datasheet than the other path. The datasheets are often not written by the engineers that actually designed the hardware, sometimes it is a junior engineer or a non-engineer. Sometimes the information is simply wrong, sometimes the document is for a different but similar part than the one you have. If they provide software that actually does stuff it is sometimes (not always) more accurate than the datasheet (when I say datasheet assume the users manual, programmers reference manual, whatever the vendor calls the doc with the registers, addressses, and bit definitions for the hardware).
With time and experience you may find, if you take a wide enough view, that some vendors tend to do a better job at providing information to users, others do not, some bury the secrets in libraries, sometimes in binary form and not source. Sometimes the secrets are buried in compilers and other tools they provide (well that is back to apis and libraries). I tend to blacklist such companies, but sometimes you cant always. ARM for example does a very good job of providing the information. the problem is they have so many cores with a number of options each, that are very similar in nature (support the same instruction sets) that it can be difficult to sort through what the one processor you are using that moment does and does not from the docs. Atmel, something about atmel that is hard to put a finger on, the docs are generally well above par, but more than that something about atmel makes them popular with the customers. You will never see an arduino like following, culture, pick a word, with a microchip pic for example. There are a lot of pic followers but it is not like the atmel world (which was there well before the arduino thing happened).
Another note, you might not understand with a single example program and single datasheet the history of a product, there might be code that has been used for a number of chip generations, and there might for example be a bit that is required by an older chip or newer chip and to share the same code that bit is manipulated. that bit might make sense looking at one datasheet and no sense looking at another. this is where hacking comes, in try it without, see what happens. maybe study other parts in the family that this code is said to support it might make more sense.
google is your friend or whatever favorite search engine, find as much open source code and other items for the particular device or whatever. At this level hacking is required, I dont use that term in the bad sense, hacking in the sense that you have to try some of the bits documented in the datasheet, see if that actually works, if not then see what it does if possible, look at other source code and see from that if you can figure it out. Just like there is no perfect car that gets infinite miles per gallon, completely safe, lasts forever, and is inexpensive, there is no perfect chip with the perfect datasheet and sample code. If you want to work at this software/hardware level you have to get your hands dirty, have to not be afraid to let some smoke out of the chips (there is a finite amount of smoke in a chip if you let even a little bit out it wont work), etc.
If the reason you wont ask specifically about the mcu or register you are working with is because it is closed source products or behind an NDA then you probably have access to the company that makes that product and you should be able to get support from them. Usually better support than you would get from a company that you dont have to sign an NDA for. Not that open document, open source companies are bad, just that if the company you buy from is interested in you to the point of showing internally protected information they are interested enough to give you better access to the real engineers that made/know the product. If this is not the case and you are able to talk about it, dont be afraid to just post a question to SO about the register and bits you are wondering about.
Sample code and flow charts in the MCU datasheets are good starting point to initialize a specific peripheral (like RS232).
You just start from there, and track the bit information and what it does, in MCU datasheet.
I have an idea for a business that requires a well designed web application. I'm not a rocket surgeon, but I'm smart enough to know that you get what you pay for and am willing to pay for talent. However, I want the development process to go as smoothly as possible and would like to know how to make that happen.
So, what information do developers need (or want) initially from the owner to avoid having to make assumptions about business (or other) requirements? Do I need to create state transition diagrams or write use cases?
Essentially, how do I take the concept in my head and package it in a way that allows the developer to do what they do best? (assuming that is creating good software. haha)
Any advice is appreciated.
Shawn
You may need to reword your question, as it is too general to get a good answer, so some vague details would be helpful.
But, the better vision you have of what you want the smoother it will be.
I find UML diagrams too confining, when you aren't going to be doing the work, as you may not come up with the best design.
So, if you start with designing out what each page should look like, as you envision it, then you can write up use cases, which are short scenarios.
So, you may write up:
A user needs to be able to log in using OpenID.
This will tell the developer one function that you want, and who you expect to do that action.
But, don't put in technologies, as you may think that a SOAP service is your best bet, but upon talking about it you may find that there is a better solution.
Use cases are good points to show what you are envisioning, and give text to your page designs.
Talk to the developers. Explain what you want and why you want it. Together you make the flow charts and whatnot. Writing requirements is part of the design process, and it's a good idea to have the developers onboard as soon as possible. Start simple and small, then grow and expand while iterating.
In talking over web services before, I have found the best starting point is drawing on a sheet of paper what you think the site will look like, and add in a few arrows from things you want clickable to the pages that should result. Keep it simple, nothing too fancy, and hopefully you and the developer can come to an understanding of what you want pretty quickly.
Use cases might be best for checking off all the points later in the project about how complete your site is; I haven't really found it to be a helpful starting point, but I'm sure others disagree. (They just seem too tedius to read when actually writing code.)
Same with state transition diagrams; they are too tedious and I think most developers will assume you made mistakes in them anyway. :) Everyone else does... Unless your project hinges very tightly on the correctness of a state machine, I wouldn't really bother.
This book contains some good advice on what constitutes a good statement of requirements from a programmers point of view. It also has the useful guideline of not trying to set the form of your requirements too early, and a substantial piece on describing the problem you are trying to solve.
I like UI mockups based on actual program/site flows e.g registering a customer or placing order. Diagrams/pictures of GUIs with structured, consistent data examples are unambiguous.
I agree that UML and use cases are only really useful if everyone speaks UML and the projects are of sufficient complexity (few are).
You may want to read up on Agile/Scrum techniques. These are becoming a sort of standard and when properly managed can save weeks of development time.
I find that words don't do a good job of communicating how a system is supposed to work. Wireframes, white-board drawings/transition diagrams, and low-fidelity prototypes are great ways to communicate a concrete idea. One example of a low-fidelity prototype is a "clickable" paper prototype that allows a user to touch "buttons" on paper to go from one drawing to another. It costs very little time (cheaper), but goes a long way to communicate an idea between two parties.
Stay away from formal documentation, UML diagrams, or class (technical documentation) diagrams that don't speak to you. This is what large, risk-averse companies move toward to be more "mature". These are also byproducts of an idea that is hashed out, and it sounds like you're in the hashing out stage.
We have a device that has an analog camera. We have a card that samples it and digitizes it. This is all done in directx. At this point in time, replacing hardware is not an option, but we need to code such that we can see this video feed real-time regardless of any hardware or underlying operating system changes occur in the future.
Along this line, we've chosen Qt to implement a GUI to view this camera feed. However, if we move to a linux or other embedded platform in the future and change other hardware (including the physical device where the camera/video sampler lives), we will need to change the camera display software as well, and that's going to be a pain because we need to integrate it into our GUI.
What i proposed was migrating to a more abstract model where data is sent over a socket to the GUI and the video is displayed live after being parsed from the socket stream.
First, is this a good idea or a bad idea?
Secondly, how would you implement such a thing? How do the video samplers usually give usable output? How can I push this output over a socket? Once I am on the receiving end parsing the output, how do I know what to do with the output (as in how to get the output to render)? The only thing I can think of would be to write each sample to a file and then to display the contents of the file every time a new sample arrives. This seems like an inefficient solution to me, if it would work at all.
How do you recommend I handle this? Are there any cross-platform libraries available for such a thing?
Thank you.
edit: i am willing to accept suggestions of something different rather than what is listed above.
Have you looked at QVision? It is a Qt based framework for managing video and video processing. You don't need the processing, but I think it will do what you want.
Anything that duplicates the video stream is going to cost you in performance, especially in an embedded space. In most situations for video, I think you're better off trying to use local hardware acceleration to blast the video directly to the screen. With some proper encapsulation, you should be able to use Qt for the GUI surrounding the video, and have a class that is platform specific that you use to control the actual video drawing to the screen (where to draw, and how big, etc.).
Edit:
You may also want to look at the Phonon library. I haven't looked at it much, but it appears to support showing video that may be acquired from a range of different sources.
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
How effective is obfuscation?
Protect ASP.NET Source code
(Why) should I use obfuscation?
Is obfuscation the best answer for protecting our code ?
*Specially in Web Projects when you want to deliver your web projects as libraries of code to your customer ( the person who ordered ) *
Edited
At first my priority is Server-Side Code
and second Client-Side
but the main goal is when you want to deliver a complete web project
and you made every piece of your code as components and dlls now how effective can you protect them and doesn't allow others to make your code back from them .
Edited
The problem is that I want to protect the code that I'm written to a company that they ordered , now all my code are inside some DLLs ,
Now they can reverse engineer that and get my code , I want to prevent them from doing so ,
Is there anyway to do so or not ?
I think that is a unique question , And I didn't ask for what obfuscation is nor for tools of doing this activity , further than that I think this is apart from Client-Server Security
Sorry if my question wasn't clear at first , but if that is really a case to be deleted , no problem for me
Also
Also I wanted to have a comparison look at this problem and the solutions ,
because I think obfuscation wasn't the only possible solution at this , I think we can have maybe some logical sort of workarounds about this problem
Maybe not the best. If you are really ambitious, you can write your own web server (plugin).
But is it worth the effort?
Software is similar to a bike in the Netherlands, there is no known way of protection that is 100% safe. You use either a better protection than the other bikes (thieves are lazy). Or you must obfuscate the bike so they won't take it.
Another way to increase the level of protection is to use custom made ActiveX code to store mission critical algorithms. Of course, they can be reverse engineered, but javascript is easier.
What exactly are you trying to protect your code from?
Does your client-side code contain valuable business logic?
If not: you shouldn't bother obfuscating something that doesn't have much value. Personally I think clientside code theft is a something that people are far too concerned about. 99% of web apps don't really have anything special in terms of implementation on the client side. What you need to worry about more is someone ripping off the idea or visual look, which you obviously can't obfuscate.
If it does: you need to consider refactoring that logic out of the client side, as even with heavy obfuscation, a determined party will always be able to untangle it relatively easily. The code that adds real value to your app should ideally be running on your servers where it's considerably more difficult to get access to.
Even if people stealing your html markup or javascript was a something to worry about (and it probably isn't), obfuscation doesn't really solve the problem. In my opinion it is a waste of effort and money.
Hosting a critical function as a web service is probably the most sure way to protect it. It keeps the code out of the user's hands entirely. But then you're stuck hosting a service, and your users have to be on line to use your functionality.
Obfuscators help by hiding useful names and replacing control flow with weird but logically equivalent alternatives. They might thwart an amateur, but they'll only slow down a skilled reverse engineer for a few minutes, and they won't stop someone who is determined to penetrate your secrets.
I you really want to protect your code, you should write native code using a native code compiler (C++, Delphi). This still does not guarantee that your code is 100% safe because any experience developer can read assembler and essentially disassemble the native code program.
A determined hacker will always find a way to get to what they want.
The best we can do is to make it hard or painful for the would-be hacker to get at our code and the following options can help us:
Customize the CLR engine
Run an obfuscation tool over your code and use name and control flow obfuscation and string encryption
Make the application a Web-based application where all your proprietary code sits on a server somewhere
Watermark your code using your own custom techniques to "throw off" the would-be hacker
Implement techniques to prevent debugging (this is a very advanced topic!)
I really like a comment made by one of the head developers of the .NET framework where he said that he does not feel it's really the fact that others can get at our code that should be a concern to us, but rather, we should concern ourselves with the level of support we provide with our products.
So if we provide a good support base, it does not matter what the hackers do with our code, because the clients will trust us and our ability to support them using our product and not some cheap hacker-hacked program.
NO, obfuscation is not the best way to protect your code.
The tool you need to use is "copyright".
There is no (technological) way you can protect you code from someone determined enough (provided they have access to the binaries / scripts).
What you can do is prevent them from legally modifying/distributing your code.
The normal server-side code in Web projects should under no circumstances be visible to the outside world. So there is no point in obfuscating the code.
Besides that two minior points:
Javascript code is visible to the user and can be obfuscated. Minimizing javascript to save bandwidth is recommended anyway. Minimizing js also obfuscates the code.
Also important is that on production system the configuration setting customErrors should be set to RemoteOnly or On to avoid showing a stacktrace with to much code details.
If your client side code has any broad value to others, it will get reverse engineered regardless of any obfuscation.
The reality is that it's likely not going to be broadly useful to many and there is a lot of other code out there to look at so probably not worth doing more than minifying the code which is plenty of obfuscation and if your code is large, it will improve download speed.
Have you considered the alternative? That it's a good thing to give somethings back to the community? I'm sure you've looked at the code of more than one site, no?