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.
Related
I've currently developed a BLDC motor controller and it generally works fine. During some events however the microcontroller locks up (e.g. stopping the motor or fast changes of duty cycle). Because of this, I want to isolate the microcontroller from the power side (i.e. isolated supply and optocoupled signals) the issue however is I'm using sensorless control and am wondering what the best way of relaying the phase values back to the microcontroller would be?
I currently detect the zero crossing in software and use this to commutate my phases (as per the Microchip AN970 amongst others). I'd rather not use comparators on the power side and optocouplers to send back a digitized version of the phase voltages as I want to have the ability to change the trigger point.
I've looked at isolation amplifiers but they seem pretty expensive and I was wondering if there were any potentially cheaper solutions.
Thanks
Maybe have a look at this document:
https://www.silabs.com/documents/public/application-notes/AN614.pdf.
We use this design, but in a total different application. I dont' really know much about BLDC motors but maybe it helps.
kind regards
so basically I've been online trying to research this the whole day and I seem to only be able to come across specific setups that people have for their own specific needs rather than a generic list of hardware needed.
What I want to do firstly using my raspberry pi 2 running raspbian, and secondly a laptop running kali, is to be able to do penetration testing along with some extras.
What I Am looking for is a list of hardware that I need (other than the rpi2 for the first case and laptop for the second) that will enable me to sniff out WiFi signals, and attempt to get onto the network. I believe the general name for this is wardriving.
I know that I need a portable power supply for the rpi2, and a screen or some sort (I want a small screen that I can see the rpi gui desktop from. Not just terminal), so any suggestions of examples of those would be appreciated.
Where I get confused is about the WiFi antenna that I need. From what I understand is that it needs to be one that can monitor as well as connect to a WiFi, but I don't really know of any examples or of what the actual difference is between it and a normal usb WiFi stick.
I'm also not sure what else I need to have beyond that to successfully accomplish my stated goal.
Any further help would be greatly appreciated, and I think beneficial to anyone else who's looking to get started doing the same thing.
Any extra information would be good too what I mean is when I was doing my research I saw some people mentioning radio attachments, gps attachments, etc. But I'm not really sure if they're necessary to start or things that can be added further down the road with experience.
Thanks.
Ok so I seem to have found a good article that answers at least the general part of my question. It can be found here.
http://lewiscomputerhowto.blogspot.ca/2014/06/how-to-hack-wpawpa2-wi-fi-with-kali.html?m=1
It also gives tips on the process of pen testing.
My project is to create an interactive program using the Micro:bit microprocessor I'm building a game which uses a drill motor as a controller of sorts reading the rotation direction and speed as inputs for control
but my mentor also said it would be cool to power the board at the same time as the game is running so now I hit the situation where once I stop turning to change direction or my speed goes below transmitting 3.3 volts to power it then the game restarts and I lose all progress
I had the Idea of using a second micro:bit as a sort of storage place being powered by my computer and the two continuously communicating sending back player position and other objects on the LED's
but i can't figure out how to get the two Micro:bit's to talk to each other
If someone could just point me in the right direction or even set up some sort of communication to nudge me in the right direction as I start moving forward
i'm a high school student who doesn't know as much as I pretend to so I'll probably need a lot of help (i am more advanced then most in my class at this sort of thing so think of me as a tech gifted teenager thrown in with college students losing my undeserved ego day by day LOL) please help me somehow I'm currently completely lost
You won't be able to use Bluetooth for the reasons indicated in the documentation (not enough memory): http://microbit-micropython.readthedocs.io/en/latest/ble.html
However, there is an incoming implementation of the lighter radio module, which would allow you to send simple data: https://github.com/bbcmicrobit/micropython/pull/283
The proposed documentation can be found in: https://github.com/bbcmicrobit/micropython/pull/305
As you can see in GitHub, at the time of writing it has not yet been merged into micropython. So if you'd like to try it you would have to clone the repository, apply the patch and build it from source. Keep in mind there is risk for the API to change, as there are still discussions about it.
Alternatively, as Sean has mentioned, you can use the C++ DAL implementation of the radio module to get something running on the meantime. Or if you prefer, the blocks and touch develop languages also offer radio functionality.
I don't think there is a way to do this in micropython (or at least simply), but the microbit runtime docs describe that, as well as supporting bluetooth, the 2.4 GHz radio:
However, it can also be placed into a much simpler mode of operation based that allows simple, direct micro:bit to micro:bit communication
In order to use this, you might need to write in c++ using the mbed environment (or offline) - but I hope this at least gives you a pointer to start from.
Here's a blog post describing how to do data logging using two microbits in exactly the configuration you describe.
http://www.suppertime.co.uk/blogmywiki/2016/06/microbit-logger
How to get the two micro:bits to talk to each other
As of 2016, you can! First check micropython has the radio module
import radio
If you get the error "No module named 'radio'", use https://codewith.mu/
Then follow the radio tutorial https://microbit-micropython.readthedocs.io/en/latest/tutorials/radio.html
The API is
https://microbit-micropython.readthedocs.io/en/latest/radio.html
I've ripped open an old Pentium desktop. The main board is a Zida 5svx. I got to know from the manual (which i downloaded from the internet) the location of the ROM chip on the board, and took it out. It was mentioned in the manual that the chip was a Flash EEPROM.
Now, what I am interested in is this: Is there a way to erase the ROM and flash it with, say a C program to blink an LED (i know this might put you into a fit of laughter, but read on all the same), or control a motor?
I also want to know if I can construct a mega-sized micro-controller with the left-over Pentium, some MBs of RAM, and this ROM.
Any suggestions?
P.S: I know that such a uC will require appropriate power supply setup and things.
The key is in getting and deeply studying the manufacturer's datasheets for each device you remove and wish to reuse. I am supposing that since you asked the question that you did that you are not a professional electrical engineer - that's OK, but you will need to do hours, days, or weeks of study to truly understand the datasheets well enough to successfully reuse your motherboard chips because they are written for professional engineers with years of experience, and unfortunately they were not written to be understood by hobbyists. If you can succeed in acquiring and thoroughly understanding all of the datasheets (and the related user's guides as well for the more complex chips) then you have made it to the point where you might be able to start a custom design based on your recovered parts, on paper at least. In order to test your design and insure that each part of it is working will require at least an oscilloscope and volt meter - and the knowledge of how to use them. An understanding of basic electronics is essential, you will not succeed without it. Very good soldering/rework/assembly skills will be required as well if you hope to have your design truly work - you can do everything else right and it can still fail if your skills in this area are lacking. There is simply not enough time for me to advise you on everything you will need to know - but if you are motivated, dedicated, and you don't give up when setbacks and roadblocks occur (and trust me, they occur all too frequently for even the best engineers and best designs) - meaning that you are not easily frustrated when things don't work - then you have a chance at success. I wish you all the best, and try to have fun while doing it (important in case fun is all you ever get out of your project). :)
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.